From 8b354491423c7e28c49c33c4cee81b1ce388517d Mon Sep 17 00:00:00 2001 From: proddy <paul@derbyshire.nl> Date: Wed, 31 Jul 2024 13:07:28 +0200 Subject: [PATCH] mention CORS, spelling --- docs/Configuring.md | 10 ++++++++++ docs/EMS-bus.md | 4 ++-- docs/Troubleshooting.md | 7 ++++--- 3 files changed, 16 insertions(+), 5 deletions(-) diff --git a/docs/Configuring.md b/docs/Configuring.md index 2a45e74d..979f1631 100644 --- a/docs/Configuring.md +++ b/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: diff --git a/docs/EMS-bus.md b/docs/EMS-bus.md index ec8505fc..6d91ef1d 100644 --- a/docs/EMS-bus.md +++ b/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. diff --git a/docs/Troubleshooting.md b/docs/Troubleshooting.md index 8ed1f7b5..09019919 100644 --- a/docs/Troubleshooting.md +++ b/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