Although it works, there seems to be many misreads of the registers in the Airlab.
I configured extremely defensive values for message_wait_milliseconds (500) and delay between register reads (1s) and still see these weird values?
The worst aspect of these misreads is that is seems the Airlab returns valid responses, but the values are wrong and allways the same (6.5 °C for temp e.g.) so it’s hard(er) to create automations on (low) values. I could filter 6.5°C, but then I would mis real 6.5°C measurements.
Is my Airlab broken? Can this behaviour be fixed in other ways?
This looks like some bad data on the serial bus. I would set up a data capture on the rs485 network and see what’s actually going on there. We use a serial port monitor like docklight for debugging problems like this.
That doesn’t make sense, a capture on wireshark would reveil 6.5°C because that’s what HA is registering? For all the missing values HA reports unavailable which I have no doubt would be the result of missing replies? I suggest you create a HA test instance and monitor Airlab registers (one-by-one) over modbus for a while and see if you can reproduce?
Please give me some time, I will do some tests and send some feedback shortly. If you could make sure you have the latest firmware running on the Airlab that will be a good first step.
Please update rev13.9, we did duplicate this issue in the older version when we used wifi.
T3000->Help->Check for Updates->download firmware and update
Chelsea will continue with you on this first thing next week. In the mean time please give the polling a try with MBPolll. Wifi is pretty slow so you will need to tweak the polling to match the speed of the module. Allow plenty of time between requests. Use the block read & write operations whenever possible.
I already posted an mbpoll example above, which had poll rate 1s. I increased it to 5s and still, the first request succeeds while any consecutive read reproducably fails, as you can see:
I used mbpoll rev1.5 and was able to reproduce your phenomenon. I found that the root cause of this problem is the Wifi module itself, it is occasionally, around 5% of the time, inserting an extra ‘A’ character, decimal 65 at the end of the packet. This is a bug inside the wifi firmware itself which we have no control over. Modbus Poll and other tools we tried here manage to deal with the extra char but other tools like HA and your modbus tool cannot.
This only affects Rev13.9 where we tried a workaround, inserting an extra char on all our packets but evidently its not helping. You should revert to 13.8 for now.
We’re researching this extra ‘A’ char issue with the wifi module manufacturer and will update here when we have a fix.
I only use mbpoll to demonstrate the problem, but please be aware that Home Assistant doesn’t get one single reading (after the first) as well! So maybe you have some software that behaves well, but all I have at the moment is one reading on 13.9. Thx for looking at this. Will revert back to 13.8 for now.
