core: Rainbird: Entity no longer being provided by the rainbird integration
The problem
After upgrade to 2023.10.0 rainbird entities are no longer available and all of the entities are in “no longer being provided by the rainbird integration” state. No errors in the log. Attached is the debug log.
What version of Home Assistant Core has the issue?
core-2023.10.0
What was the last working version of Home Assistant Core?
core-2023.9.3
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Rainbird
Link to integration documentation on our website
https://www.home-assistant.io/integrations/rainbird/
Diagnostics information
There is no option to download diagnostic data for rainbird integration.
Example YAML snippet
N/A
Anything in the logs that might be useful for us?
2023-10-05 14:24:29.978 DEBUG (MainThread) [pyrainbird.async_client] Request (ModelAndVersionRequest): 02
2023-10-05 14:24:29.978 DEBUG (MainThread) [pyrainbird.async_client] Request: {"id": 1696508669.9787104, "jsonrpc": "2.0", "method": "tunnelSip", "params": {"data": "02", "length": 1}}
2023-10-05 14:24:31.153 DEBUG (MainThread) [pyrainbird.async_client] Response: {"jsonrpc": "2.0", "result":{"length":5, "data":"8200060100"}, "id": 0}
2023-10-05 14:24:31.153 DEBUG (MainThread) [pyrainbird.async_client] Response from line: 8200060100
2023-10-05 14:24:31.153 DEBUG (MainThread) [pyrainbird.async_client] Response: {'type': 'ModelAndVersionResponse', 'modelID': 6, 'protocolRevisionMajor': 1, 'protocolRevisionMinor': 0}
2023-10-05 14:24:31.153 DEBUG (MainThread) [pyrainbird.async_client] Request (AvailableStationsRequest): 0300
2023-10-05 14:24:31.153 DEBUG (MainThread) [pyrainbird.async_client] Request: {"id": 1696508671.1536999, "jsonrpc": "2.0", "method": "tunnelSip", "params": {"data": "0300", "length": 2}}
2023-10-05 14:24:31.814 DEBUG (MainThread) [pyrainbird.async_client] Response: {"jsonrpc": "2.0", "result":{"length":6, "data":"8300FF000000"}, "id": 0}
2023-10-05 14:24:31.814 DEBUG (MainThread) [pyrainbird.async_client] Response from line: 8300FF000000
2023-10-05 14:24:31.814 DEBUG (MainThread) [pyrainbird.async_client] Response: {'type': 'AvailableStationsResponse', 'pageNumber': 0, 'setStations': 4278190080}
2023-10-05 14:24:31.814 DEBUG (MainThread) [pyrainbird.async_client] Request (CurrentStationsActiveRequest): 3F00
2023-10-05 14:24:31.814 DEBUG (MainThread) [pyrainbird.async_client] Request: {"id": 1696508671.8145082, "jsonrpc": "2.0", "method": "tunnelSip", "params": {"data": "3F00", "length": 2}}
2023-10-05 14:24:32.204 DEBUG (MainThread) [pyrainbird.async_client] Response: {"jsonrpc": "2.0", "result":{"length":6, "data":"BF0000000000"}, "id": 0}
2023-10-05 14:24:32.204 DEBUG (MainThread) [pyrainbird.async_client] Response from line: BF0000000000
2023-10-05 14:24:32.204 DEBUG (MainThread) [pyrainbird.async_client] Response: {'type': 'CurrentStationsActiveResponse', 'pageNumber': 0, 'activeStations': 0}
2023-10-05 14:24:32.204 DEBUG (MainThread) [pyrainbird.async_client] Request (CurrentRainSensorStateRequest): 3E
2023-10-05 14:24:32.204 DEBUG (MainThread) [pyrainbird.async_client] Request: {"id": 1696508672.204303, "jsonrpc": "2.0", "method": "tunnelSip", "params": {"data": "3E", "length": 1}}
2023-10-05 14:24:32.599 DEBUG (MainThread) [pyrainbird.async_client] Response: {"jsonrpc": "2.0", "result":{"length":2, "data":"BE00"}, "id": 0}
2023-10-05 14:24:32.599 DEBUG (MainThread) [pyrainbird.async_client] Response from line: BE00
2023-10-05 14:24:32.599 DEBUG (MainThread) [pyrainbird.async_client] Response: {'type': 'CurrentRainSensorStateResponse', 'sensorState': 0}
2023-10-05 14:24:32.599 DEBUG (MainThread) [pyrainbird.async_client] Request (RainDelayGetRequest): 36
2023-10-05 14:24:32.599 DEBUG (MainThread) [pyrainbird.async_client] Request: {"id": 1696508672.5997853, "jsonrpc": "2.0", "method": "tunnelSip", "params": {"data": "36", "length": 1}}
2023-10-05 14:24:33.049 DEBUG (MainThread) [pyrainbird.async_client] Response: {"jsonrpc": "2.0", "result":{"length":3, "data":"B60000"}, "id": 0}
2023-10-05 14:24:33.049 DEBUG (MainThread) [pyrainbird.async_client] Response from line: B60000
2023-10-05 14:24:33.049 DEBUG (MainThread) [pyrainbird.async_client] Response: {'type': 'RainDelaySettingResponse', 'delaySetting': 0}
Additional information
Works ok again after downgrading HA to 2023.9.3
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Comments: 47 (21 by maintainers)
Also, i’m making progress on the mac address fix so we’ll have a permanent solution.
Regarding (3) above, if folks want to help me understand what’s possible for your devices I’ve created an issue where we can discuss it further as we need to learn more about what is capable of your device: https://github.com/allenporter/pyrainbird/issues/270
(For example, it doesn’t support serial numbers… so what else doesn’t it support?) Join me there and we can figure something out.
OK thank you – This was not intentional and I have #101470 to fix. The problem is the devices have a “0” serial number which is not a valid unique id, but I’ll send a fix to keep ti working for the existing entities for folks that already have it setup.
Thanks. We’ll get it working connected through the UI to the integration entires in a follow up.
Just installed the 2023.10.2 and I can confirm that it works as expected now. Many thanks!
@ThomasBergholdWieser my intent is that you should not need to change anything, and home assistant fixes will get you back into the state they were before. In general, we want users to get repaired with no action on their part.
If you didn’t change anything, the
.1patch was not complete and I expect it to be fixed in.2. If you did delete the integration and re-add then2023.11will get it working again as before.(1) Restoring old behavior for existing configurations The intent is the patch makes it work like it used to where entities are created with the original but incorrect unique id using “0” as the unique id from the serial number. If you are saying it didn’t restore original behavior, that isn’t the intent, so I’ve re-opened the issue to look closer.
(2) New integration behavior If you delete the integration and re-add it then the patch will not help you. New setup of the integration has a new behavior that can’t allow edits from the UI because the old approach of determining the unique ID is not valid, determined while investigating #99240. (BTW, this is the old behavior of the integration before it was rewritten in the last year to support unique ids). I do not recommend deleting the integration if you want the old behavior in (1).
(3) Paths forward for unique id As I said above “There may be other ways to give these devices a unique id be using another identifier likesc address but it may require cloud rpcs which are not used today.” – but “likesc” should have been “mac address” sorry bad autocomplete. There are specific rules for config entry unique ids and entities. Many of the ideas proposed would technically work are but not at all valid uses of unique ids – like “0”. Not sure I need help here unless you are already a developer familiar with the rules and the APIs provided by rainbird (which are few), but as I mentioned already have an idea there.
Yeah, unfortunatly this fix doesn’t seem to adress all the issues. Should this bug then be reopened?