Closed stefanh12 closed 1 year ago
Do you also get many protocol retry failures logged?
Copying this here. I believe I'm seeing a similar problem. I had poor signal strength which I think is resolved mentioned as mentioned in #58.
No protocol errors have been logged for almost 4 days, yet my radio sensor has been stuck at 1% since almost a minute after the last protocol error. However the last_ping sensor is still updating every minute and is current. Other entities are current/updating, just not the radio sensor.
Last protocol/retry error logged:
2022-05-28 22:28:29 ERROR (MainThread) [geckolib.async_spa] Cannot get file, protocol retry count exceeded
sensor.my_spa_radio
changed to 1% (down from 30%) at 2022-05-28 22:29:25. That was the last time it updated.
The ping sensor did show a 13.5 minute gap where connectivity was broken starting around 22:15, but after 22:29:25 pings were succeeding.
Do you also get many protocol retry failures logged?
Sorry for late reply, I've only seen this twice and not after I reported the issue. I dont have the logs but will save them if I can reproduce it.
Interesting! The radio sensor is only updated during the initial connection cycle so it will only ever show the value that it was when last successfully connected. I think this needs to be updated periodically as it hadn’t occurred to me that it might change so drastically during normal operation.
The behaviour experienced can be explained because every time the RF is degraded, the ping cycle and periodic full pack requests may fail leading to an attempt to reconnect to the spa, and if by chance that is successful during this degraded RF time, then that will be the last RF signal strength that is logged.
Why is it done this way? Basically I copied the pattern that the Gecko app uses, and it makes sense because another way you can loose RF is if you power down your spa. At this point, anything can happen - you could upgrade the spa pack, or even move the RF unit to another tub completely, so there is no option but to reload the spa pack structure after an RF outage, and during that operation, the channel and RF signal sensor is updated.
My radio sensor did finally update because we had a power interruption. The HA server, and the ethernet side gecko module didn't lose power because they were on UPS. As you described the sensor updated when the spa was powered back up and responding again.
I think this needs to be updated periodically as it hadn’t occurred to me that it might change so drastically during normal operation.
Yes, the RF environment can change for a variety of reasons. If there is going to be a radio sensor, I think a user would be reasonable in expecting to see it update, particularly if they were trying to move the sensor around to get a better signal.
Is it a separate request to get the RF info?
It probably doesn't need to update too frequently.
Thanks.
Thanks.
I had no idea that it was just read at initial connection, interesting though. Having the value read more often would help to debug issues with connection I think. My issues seems to be more or less gone once I moved from my lan to my iot network instead. Im guessing the broadcast messages on my lan where giving the gecko device a hard time
[Thought I sent this reply two weeks ago, but doesn't look like it got posted. Apologies if this shows up twice.]
My radio sensor did finally update because we had a power interruption. The HA server, and the Ethernet-side gecko module didn't lose power because they were on UPS. As you described, the sensor updated when the spa was powered back up and responding again.
I think this needs to be updated periodically as it hadn’t occurred to me that it might change so drastically during normal operation.
Yes, the RF environment can change for a variety of reasons. If there is going to be a radio sensor, I think a user would be reasonable in expecting to see it update, particularly if they were trying to move the sensor around to get a better signal.
Is it a separate request to get the RF info?
It probably doesn't need to update very frequently.
Thanks.
Fixed in v0.1.9
Version of the custom_component
v0.1.8 inYT 380 v3.0 by Gecko Alliance Firmware: SpaPack:v33.00 Config:61 Log:61
Describe the bug
The radio quality is 100% when the integration starts or when the reconnect is pressed. The radio quality will after a while go to 1% and stay there until the integration is restarted or reconnect is pressed.