-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Succesful installation, but webgui is displayed but does not respond #17
Comments
What happens if you try one of the pre-build binaries ? ( https://github.com/Victor-Mo/IRT-ESP/releases ) |
Using a pre-built binary, ofc. I won't see any compilation errors or -warnings :) I wish to start with a compliment for the effort you did to implement the iRT protocol! I received the modified interface board and had to increase the 1M resistor to 1.5M because the iRT bus was not detected at first. Now I see valid datagrams coming in with hardly any crc errors. However, I do not get a lot of data on the screen, so I had a look at the actual data coming in. That shows that there are many Also the I am now collecting raw loggings and will look for relationships between the payload values and the actual behaviour of the heater. If I find something that makes sense I will post it here. |
After collecting raw logs in a number of different situations, it shows that my UBA4000 is sending these messages: 0x82: Byte 4 represents the status of the burner and the 3-way valve (flags) as implemented in the software 0x83: Byte 4 If the burner is "on", the value seems to represent the actual burner power, but if the burner is "off", the value is always 0xA0 0xA3: Byte 4 represents the service code (flags) as implemented in the software 0xFC: Byte 4 seems to be a copy of the burner power as requested by the thermostat (0x07[1]), possibly an indication that the UBA has accepted the request? My Moduline thermostat is sending: 0x07: Byte 1 represents the requested burrner power, 0x29 (16 decimal) means "off". The minimum value for "on" is 0x4D (30). if the room temperature is around its target the value toggles between these two values. Only if much burner power is needed (eg in the morning when first heating up), the value will go above that. 0x73 and 0x78: Always the same three values, possibly related to the Moduline model and version? So I skipped the 0x73 and 0x78. In fact only 0x83[4] seemed to contain useful new information. Because I thought that this might represent the actual burner power, I added curBurnPow to the program code, so now the mqtt messages also contain that value. Then I left it running overnight, recording the values from the mqtt messages to a file and from that created a line graph for selBurnPow and curBurnPow, to see how these are correlating. In order to get a linear x-axis with values for every second, I duplicated the values for the periods between the mqtt messages. On the left we see a constant value of 16 for selBurnPow (red line). This indicates that the central heating doesn't need any burner power. When the value jumps to 30, the burner goes on (dark blue line) at a very low level (curBurnPow = 2). When selBurnPow rises above 30, curBurnPow is gradually rising accordingly. In the middle you can see that happen when the central heating is starting up in the morning. The "square wave" next to it is the behaviour when the room has reached its target temperature and the burner is switched on (at a very low level) and off regularly in order to keep that temperature. On the far right you can see the behaviour when the burner is heating the hot tap water. At that moment the burner power was on for central heating (curBurnPow = 2), but the burner immediately jumped to it's maximum power and after about one minute started to decrease gradually. Right after that, curBurnPow peaked above 60 for central heating, probably to compensate for the heating it missed while the burner was heating the hot tap water. So it seems that 0x83[4] indeed is representing the actual burner power. Where 0x07[1] is only relevant for central heating, 0x83[4] is relevant for hot tap water too. |
Niek, nice to see that you're also using the IRT-ESP software. I'm having the same kind of problems trying to compile the code myself. It seems that you got it to work. Would it be possible for you to point me in the right direction? |
Hello erhapp, For me, it was sufficient to do what was said here: issue #7:
After that the compilation succeeded, with a couple of warnings, but these don't do any harm (at least in my case). |
NiekD, In my case VSCode complains about a missing file: src/MyESP.h:54:10: fatal error: webh/glyphicons-halflings-regular.woff.gz.h: No such file or directory This directory is empty in the repo. What am I missing? |
It looks like it needs to build the 'web' files first.
Then try to compile again. |
I managed to install on my Wemos D1 mini with the help of the "trick" referenced below.
Then I can connect to the WiFi AP, and open the web interface, but it does not respond to any setting I try to change.
The reason seems to be this error:
myesp.js:formatted:420 WebSocket connection to 'ws://192.168.4.1/ws' failed: Could not decode a text frame as UTF-8.
I also see this error, but I think that this is less important:
GET http://192.168.4.1/fonts/glyphicons-halflings-regular.woff2 net::ERR_ABORTED 404 (Not Found)
EDIT:
I managed to change the WiFi settings (one by one) using Telnet. After that my device did connect successfully with my WiFi AP. After this the web interface works!!! Only the
glyphicons-halflings-regular.woff2
error still exists, but doesn't seem to do any harm. So as far as I'm concerned it is OK.Now waiting for the modified interface board I ordered to arrive.
In addition:
When installing with the verbose option I see this:
Platform incompatible library C:\Users\Niek\.platformio\penv\Scripts\.pio\libdeps\release\AsyncTCP More details about "Library Compatibility Mode": https://docs.platformio.org/page/librarymanager/ldf.html#ldf-compat-mode
Found 48 compatible libraries
Scanning dependencies...
Warning: Ignored
AsyncTCPdependency for
ESP Async WebServerlibrary
Warning: Ignored
AsyncTCPdependency for
AsyncMqttClientlibrary
Quote:
The web builder has been upgraded to use Gulp 4. Remove tools/webfilesbuilder/node_modules and re-install the libraries using npm ci from within the tools/webfilesbuilder folderFound it!
tools/webfilesbuilder/node_modules
and re-install the libraries usingnpm ci
from within thetools/webfilesbuilder
folderOriginally posted by @jperquin in #9 (comment)
The text was updated successfully, but these errors were encountered: