mention CORS, spelling

docs/Configuring.md

@@ -68,6 +68,16 @@ This next section describes some of key application settings that can be configu
   - **Log Level** sets the maximum log level for reported messages. The highest level is DEBUG which will send a lot of log data so use with caution.
   - **Mark Interval** will send out a special `mark` message to the SysLog. This is useful for timing events.
 
+## Setting up the Network
+
+The Network page allows you to connect EMS-ESP to your home network. You can choose between WiFi or Ethernet. EMS-ESP will auto-detect which and set the settings accordingly. Anything in the Board Profile will override these settings.
+
+### CORS (Cross-Origin Resource Sharing)
+
+CORS, when enabled adds new HTTP headers to each Web request to allow the Web API to make `fetch` and `XMLHttpRequest` requests across different domains. It disables the pre-flight check which follows the same-origin policy by default. See <https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS> for more details. There is also a "CORS unblock" browser addon that works the same way.
+
+Enable this function when running in VPNs or you have other servers (like Grafana) running on other domains that are making calls to EMS-ESP's API.
+
 ## Setting up MQTT
 
 Most are self-explanatory and the settings that are specific to EMS-ESP are:

docs/EMS-bus.md

@@ -53,10 +53,10 @@ Following a write request, the `[dest]` doesn't have the 8th bit set and after t
 
 ### Fetching EMS telegrams
 
-Not all telegrams are broadcasted frequently, a lot of setting telegrams are only broadcasted partial if there is a change. To get all values from a telegram ems-esp has send a read request to the device and the device reply's the telegram only to emsesp, this we call "fetching a telegram".
+Not all telegrams are broadcasted frequently, a lot of setting telegrams are only broadcasted partial if there is a change. To get all values from a telegram EMS-ESP has send a read request to the device and the device reply's the telegram only to emsesp, this we call "fetching a telegram".
 
 In `system/info` the devices listed with the handlers (type-ids that are processed):
 
 - `handlers received`: Telegrams that are frequently broadcasted by device to all: _"Boiler(0x08) -> All(0x00)..."_
-- `handlers fetched`: Telegrams that are not broadcasted and requested by ems-esp once a minute: _"Me(0x0B) <- Boiler(0x08) .. Boiler(0x08) -> Me(0x0B)..."_
+- `handlers fetched`: Telegrams that are not broadcasted and requested by EMS-ESP once a minute: _"Me(0x0B) <- Boiler(0x08) .. Boiler(0x08) -> Me(0x0B)..."_
 - `handlers pending`: Telegrams not received yet or empty on fetch. Example: ems-boilers uses telegram 0x18 to monitor actual values, ems+ boilers uses telegram 0xE4 for the same information. If you find 0x18 on the received list, you have a ems boiler and 0xE4 is pending.

docs/Troubleshooting.md

@@ -83,10 +83,11 @@ See this article on [Decoding EMS Telegrams](FAQ.md?id=decoding-ems-telegrams) f
 
 ### Many Rx errors
 
-It is quite usual to see a few warnings in the log about incomplete telegrams. This could be due to interference on the line. The warnings are usually harmless as EMS-ESP will either wait for the next broadcast or keep trying to fetch the telegram. If you're seeing an Rx or Tx quality less than 80% then try:
+It is quite usual to see a few warnings in the log about incomplete telegrams. This could be due to interference on the line, inadequate power or a wrong Tx Mode. The warnings are usually harmless as EMS-ESP will either wait for the next broadcast or keep trying to fetch the telegram. If you're seeing an Rx quality less than 80% then try:
 
-- powering: try to power ems-esp by USB or service-jack. We've seen examples where a noisy or failing DC supply can cause RX Fail or incomplete telegrams and trying USB power (check how to switch to USB powering in the [wiki](https://bbqkees-electronics.nl/wiki/)) can help track this down.
-- disruptions on the bus (emc, reflections, etc): try to connect ems-esp to another device on the bus. In general a previously unconnected bus-out on a devices like MM100 is better than a split connection on an already used connector.
+- a different Tx Mode, for example switch between EMS+ and EMS.
+- powering the EMS-ESP by USB or service-jack. We've seen examples where a noisy or failing DC supply can cause RX Fail or incomplete telegrams and trying USB power (check how to switch to USB powering in the [BBQKees wiki](https://bbqkees-electronics.nl/wiki/)) can help track this down.
+- removing disruptions on the bus line from emc, reflections, other units. Connect the EMS-ESP to another device on the bus. In general a previously unconnected bus-out on a devices like MM100 is better than a split connection on an already used connector.
 
 ### Bus is not connecting