Succesful installation, but webgui is displayed but does not respond

[NiekD]

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 forESP Async WebServer library
Warning: Ignored AsyncTCPdependency forAsyncMqttClient library

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!

• 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 folder

Originally posted by @jperquin in #9 (comment)

[Victor-Mo]

What happens if you try one of the pre-build binaries ? ( https://github.com/Victor-Mo/IRT-ESP/releases )

[NiekD]

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 0x83 messages sent by the UBA, but not handled by the program. The last byte of these seem to idicate if the burner is on and for what purpose (central heating or hot water).

Also the 0x05 messages coming in (only when the hot water boiler is being heated), have a payload of 5 bytes (so are from the UBA), while in the code they are handled as 4 bytes (as if they are expected to come from the thermostat).

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.

[NiekD]

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.
Because 0x83[4] always has a value of 0xA0 when the burner is off, I only set curBurnPow to the value of 0x83[4] (converted to a decimal value between 0 and 100) when the burner is on, else I set it to 0 (zero).

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.

[erhapp]

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?
(I myself would like to build an "alternate" version allowing me to switch between a thermostat and using the board in active mode using a relay to connect/disconnect the thermostat.)

[NiekD]

Hello erhapp,

For me, it was sufficient to do what was said here: issue #7:

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 folder

After that the compilation succeeded, with a couple of warnings, but these don't do any harm (at least in my case).

[erhapp]

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?

[Victor-Mo]

It looks like it needs to build the 'web' files first.

• goto the directory ./tools/webfilesbuilder/
• run the command 'npm ci' that should install all node modules
• from the same directory run: 'node node_modules/gulp/bin/gulp.js' that should build all the web files

Then try to compile again.