So, the misreadings have indeed disappeared but what’s left looks more like a scatterchart than a nice graph. How can we improve these missing/failing reads?
you certain it’s a problem with the airlab?
Try reducing the polling intervals. leave a short delay between packets.
There may be some communications issue with your environment there. A wireshark capture would be helpful.
Maurice
No, I’m not saying it’s the Airlab, I’m trying to find out where the problem is and if the issue can be reproduced or not?
I’m polling once every minute, have an initial delay of 1 second and leave 500ms between every read. How much further do I need to go? The Airlab and server are connected over a professional Wifi Access Point (tp-link omada).
I will try to get a meaningful wireshark trace, but as I said the problem is sporadic so might take a long trace 
I was lucky, here’s the wireshark capture.
At 242.117629 the last succesful query is sent, which gets a response on 242.224672 and a final ACK on 242.224870.
Then, at 242.735365 (500ms later) a new query is sent, but the Airlab never replies, so HA closes the connection 3 seconds later (timeout) at 245.753742 resulting in an empty value in HA.
yes you will need a delay. or take advantage of the block operations. the WiFi module is linked to the main CPU over i2c so it needs time for each packet.
Maurice
I set the delay between queries to 1s. Doesn’t make any difference unless you think the Airlab needs a holiday between reads?
The Airlab wifi is a very slow as I mentioned. The Wifi module is connected to the main CPU over an I2C channel which cannot handle much traffic. Try slowing down your polling to one command every ten seconds or so. The C02 and temperature in the building doesn’t change that quickly, right. Once you get the basics settled down you can test faster polling. Also try the block read functions, this will reduce the overhead on the traffic.
Airlab over RS485, both Modbus and Bacnet is very fast, you can poll many times per second if you need it.
I don’t think you understand the problem.
I do read PM values in block (already mentioned this many times), but I can not read in block for Temp, VOC and C02 because the registers are too far apart (already mentioned this many times). So I poll every minute (slow! Mentioned many times) but then each minute both Temp and CO2 and PM values are read with 5 seconds between queries (also very slow, mentioned many times).
It goes like this:
Read Temp
[wait 5 seconds]
Read CO2
[wait 5 seconds]
Read VOC
[wait 5 seconds]
Read PMx (block)
[wait 1 minute ...]
Read Temp
[wait 5 seconds]
Read CO2
[wait 5 seconds]
Read VOC
[wait 5 seconds]
Read PMx (block)
[wait 1 minute...]
etc...
This is how HA modbus configuration works. I don’t see how I could improve?
How is 5 seconds not long enough for the I2C bus to recover between queries? 5 seconds is like ages for CPU’s? CPU’s don’t get tired and for most queries it just works OK?
Do you have a HA test setup with the Airlab and can you reproduce the issue?
I suspect the Airlab firmware still has occasional wifi connection bug?
OK, all that you mentioned there sounds good.
We don’t have an HA instance here but we can set up similar polling using MBPoll and then we compare notes.
Update: Can you clarify what you mean there, above you showed how you used wireshark to capture some packets succesffuly but then 500ms later you saw another request but no reply. Elsewhere here you say you wait five seconds. Just need a little help understanding what you mean there. Once its clear we can duplicate the exact sequence of packets using MBPoll.
Yes, I keep increasing the delay just to please you. So, my latest config has a 5s delay, but it makes no difference (500ms is already an eternity on the scale of CPU’s). I can keep increasing if you want? I’m just sure it won’t make any difference from here.
And just to show how weird the issue is: this is a graph with 5s delay between register reads (and one minute between bursts). It’s even worse than the one with 500ms or 1s delays?
Fandu has made some progress debugging with your CCC modbus tool. It sends out some packets very quickly during the initial connection steps, this barely give our device time to respond. We will see what we can do to work around this.
I doubt whether that’s the problem. HA python lib makes 1 connection for the lifetime of the HA process (unless something went wrong) and they even have a specific connection-to-first-query delay, which I set to 1 second. That can not be too fast, I think?
modbus:
- name: Airlab
type: tcp
host: 192.168.1.61
port: 502
message_wait_milliseconds: 5000
delay: 1
retry_on_empty: true
retries: 5
Any news on this? It’s still happening although there are also periods of decent performance?
1 Like
We have taken some steps to improve the packet loss rate caused by Wifi communication, but due to wifi signal and other network factors, this Airlab sometimes has a packet loss rate of 2%-5%. It helps if your HA software is able to retry this at timeout. ALso if its an option you can wire over RS485 directly, the packet loss over RS485 is zero.
We do have a solution in the works, the Airlab will soon be sporting a new ESP32 cpu and wifi module over which we will have direct control over the wifi communications. The wifi performance of this new version will be greatly improved.
Thank you!
As mentioned many times, direct RS485 is not an option. I bought the Airlab because it has Wifi capabilities.
As can be seen in the post above I did configure HA to retry (as far as I understand the configuration). It would help if you guys could set up a test HA environment with an Airlab to see if there is room for improvement using the existing config (or even maybe improve the modbus implementation?)
We did a lot of testing and firmware fixes to get this working '8098, and we appreciate all the good feedback and pushing us in a good direction. In our latest tests we have the error rate down to the 2%-5% range and that’s about all the performance we can pull out of the current wifi modules that we’re using. The issue comes down to the flurry of packets which HA ends up sending to establish a wifi connection, our module cannot deal with the storm. Hope you can understand.
And as Fandu mentioned, there is a fix in the works with a new model of the Airlab coming out in a few weeks. If you’d like to arrange a swap when its ready we can do that for you.
1 Like
That would be awesome!
Where are we standing with the new Airlab?
The basic functionality is complete, and we’re about to start small-batch testing
2 Likes