Generic HTTP don't work since ESP_Easy_mega-20200204_dev_ESP8266_4M1M.bin #3054
Comments
|
This is communication between ESPEasy nodes? |
|
What are you trying to send? |
TD-er
added
Category: Controller
|
Its communication between ESPEasy (Wemos D1 Pro) and my SmarthomeNG controller (similar Domotics or FHEM). When I capture the HTTP requests, this is what I can see with the different firmware versions: ESP_Easy_mega-20200204_dev_ESP8266_4M1M.bin shows: |
|
OK, that last part makes it clear it is for sure related to the fix you linked. What is the string you use in the controller to generate this URL? |
|
Under Controller Publish: /shNG/ws/items/%sysname%.%tskname%.%valname%/%value% |
|
Check! |
|
it is incompatibility with older release but SmarthomeNG controller should respect url encoded link, so for me it is more like bug there |
|
Beside the pure url encoding, it looks like there is a specific bug if you precisely compare both outputs. |
|
@sracing try this: shNG/ws/items/%sysname%.%tskname%.%valname%/%value% |
|
I have looked at the code quite intensively and at least in the URL encode functions in ESPEasy, there is nothing wrong so it seems. This is in the log. I will now look at the link @uzi18 posted... |
|
What we're doing is the "method of choice" according to that link. Or at least that's what is being created as can be seen in the logs. |
|
it can be some differents between esp/esp32 |
|
Ah finally found the logs.... So just to be sure it isn't something that may have been fixed in the last few days, I will make a test build of this code. |
|
@sracing: Details here, if of interest. Probably not solving the problem, but a workaround which is more straight than untilizing the more complex http protocol. |
|
have looked into sources of shNG and it supports mqtt, it is far more reliable protocol |
|
@Tom-Bom-badil did you use generic udp protocol? screenshots are unavailable for external users... so hard to guess udp is fast and lightweight plus no blocking :) |
|
Well other protocol options aside, the described issue does seem like an encoding problem with the HTTP controller and since I cannot reproduce it on my node here based on the current code base, I would really like to know if this test build is working as expected or not. If that's working as expected, you can all help into finding the best suitable protocol, as I do agree http is probably not the best one for the job. |
|
Nearly a fix, but .. 1 - the %valname% now seems to be a combination of the device 'Unit Name' (esp_easy) and 'Unit Number' (1) - unless there is another explanation where the '_1' comes from.... Output for issue3054_ESP_Easy_mega_20200505_dev_ESP8266_4M1M.bin is: Output for ESP_Easy_mega-20191208_dev_ESP8266_4M1M.bin was: |
|
That is part of the %sysname%. You can see it is in front of the |
|
Makes a lot of sense, but it somewhat looks that the 'Append Unit Number to hostname:' switch was not considered in %sysname% for firmware 20191208 and older. However, the firmware fix now works fully (I just need to disable that 'Append Unit Number to hostname:' switch after the update). Great work. Thanks for doing this in such short time. |
I am using several Wemos D1 with ESP Easy since quite a while and was doing a firmware update on those ESP Easy devices.
On any of my devices, when using a firmware 'ESP_Easy_mega-20200204_dev_ESP8266_4M1M.bin' (OR NEWER), I am not able to receive data from the ESP Easy 'Generic HTTP' Controller anymore.
With any firmware 'ESP_Easy_mega-20191208_dev_ESP8266_4M1M.bin' (OR OLDER) it works without any issue.
The text was updated successfully, but these errors were encountered: