Rainbird: Entity no longer being provided by the rainbird integration #101470
Comments
|
Hey there @konikvranik, @allenporter, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) rainbird documentation |
|
Hi @adorobis appreciate filing the separate broken out issue. Can you help me by finding a little more detail in the logs from rainbird? This subset shows Rainbird requests to the device that appear to be working fine. Perhaps with debug mode on reloading the integration may give us a little more insight to what is happening at integration start that is not registering the entities. |
|
The main change in this release is related to the devices with no serial number and assignment of unique ids. |
|
I have the same issue (also after upgrading to 2023.10.0 from 2023.9.3) |
Here it is with debug logging and reload of the integration. More or less the same as in the previous ones. Seems it is getting data correctly from rainbird controller but somewhere in HA it is lost. Btw, this is example from a different instance running 2023.10.0 where the rainbird integration was not existing before. Entities were not created at all. |
|
And here on an instance where rainbird was there on 2023.9.3 and upgraded to 2023.10.0: |
|
Very odd. In #101489 the user reports that the entities are disabled. Perhaps you can look for that? Do any of the entities appear in developer tools? In my instance when running with logging turned up i see these: Do any of those show up earlier in the log? I suspect the calendar one will not because that device has no programs. |
|
For me, after upgrade and fixing the pydantic issue, rainbird didn't reconnect to existing entities. So I tried to remove the reinbird integration and setup it again, but now it doesn't detect any of sprinklers neither sensor and I guess neither controller. I thing it should be also separate entity under the integration: |
|
@konikvranik Does it show up if you search for any of the entities from |
|
@allenporter: You're right. There are new entities not connected to the integration and saying the it has not unique ID: |
|
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. |
|
@allenporter Great, thanks! Let us know when we could test it, I have additional HA instances for testing purposes. |
Many thanks Allen, In addition, for the time being, the new entities which are not linked to the integration are nevertheless working (eg: switch.rain_bird_sprinkler_1) but they have no unique Id, so I cannot manage them in the UI to match the old_name before updating so that my configuration still works) Great integration otherwise, save my day ;-) |
I have just reverted to 2023.9.3 while waiting for the fix to come :) Super easy if you are on a Docker installation. |
|
Also super easy in regular HA, as the update that broke it creates a backup before, you can just revert to that, skip the impending update and wait for the fix. Thats what i am doing as well. Thanks for the fast response and fix. My issue is the exact same as @adorobis, not the cython/python issue that was mentioned. |
|
I wasn't capable of reverting to working HA, even by completely removing the venv and recreating a new one with 2023.9.3. Pydantic was failing there again regardless of whether it was 1.10.12 or 1.10.13 or 1.10.11. The only possible fix is to enforce pydantic 2.4.* which fixes the crucible integrations, but at least disables Google calls integration. |
As far as i understand. these are different issues |
|
I was just replying to your comment regarding rollback. |
|
@allenporter |
|
BTW, one additional observation. After applying the fix to the instance where Rainbird was already set up I could see now new entities created, working ok, but not linked to the integration. Here is how it looks like. Those in the red status are the ones linked to the integration but not working: |
|
Hi, I hit the same issue. My previous devices and entites are still linked to the integration, but they are no longer provided so they don't work. I got new entities (but no devices) created by the integration that work just fine, but are not linked to the integration or any device:
Also, new entities do not have a unique ID, so they can't be configured from the UI (icon, name, etc.). Will the fix take back old entities or will keep the new ones? Thanks! |
|
Yeah, unfortunatly this fix doesn't seem to adress all the issues. Should this bug then be reopened? |
|
Rainbird devices with a zero serial number dont have a unique id so they will not be able to work from the UI going forward. The entities are all there but not UI editable. (Like it used to be). This needed to be fixed do that users could add multiple devices (another issue reported by users). The fix I submitted will make it keep working if you did have it editable. If you delete the integration and re add it then they won't be editable from the UI anymore and the fix won't apply anymore. 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. I will look closer at the details you reported here. |
|
@allenporter Do i understand that correct that right now, this leaves existing users with an inoperable setup or they need to stay on the previous HA version? As i understand it, there is no way to make it work like it used to, even with this patch, correct? |
|
Oh, now I get it. Maybe as the easiest way we could simply take the IP address of the controller (or better MAC address if possible)? And anyway even if we can't have the unique IDs would be good to keep existing entity_ids for controllers that are already integrated with HA. |
|
Why don't generate the unique id for these devices? There would be several ways:
Cheers! |
(1) Restoring old behavior for existing configurations (2) New integration behavior (3) Paths forward for unique id |
|
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: (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, clear now. Indeed I'd like to restore the old behaviour for my existing integration. At the moment the patch did not help. |
|
With version 2023.10.1 the sprinkelers are working again but the rainsensor is still unavailable.
|
|
@tieskuh if its showing on the device then I believe that means the unique id is back, and the entities are now associated properly. Perhaps you can file another issue report to track down why its unavailable? with fill issue template, error logs, etc. @adorobis Now that you deleted the integration, it will have new behavior in Others, curious if 2023.10.1 restores the old behavior (assuming you did not delete the integration!) |
|
@allenporter For the sprinkelers the old behaviour is back. I didn't delete the integration and waited for your update. After updating the sprinklers came back again. For the rain sensor it seems the problem isn't fixed yet. There is a second sensor created that is not associated with the device
I can create a new issue for that, but it seems that it is related, right? |
|
@tieskuh yes, looks related. I believe the confusion on my part is from |
|
In my case (i got new entities without unique id that worked and didn't delete the old ones), old sprinklers are back too. I think those devices have been re-created as they have no registry at all. My Thanks for solving it so fast! |
|
OK thanks, i see the bug with the binary sensor rainsensor, it was omitted from my previous PR. |
|
Also, i'm making progress on the mac address fix so we'll have a permanent solution. |
|
Thanks folks for your patience on this. The mac address fixes will likely land in a future release like |
Hmm, I have not deleted the integration, I've just upgraded one of my instances from 2023.9.3 to 2023.10.1 and the entities linked to the rainbird integration are all unavailable and duplicate ones have been created: I can easily replicate the behaviour: on 2023.9.3 I added the rainbird integration - all works as expected, entities are working and are linked to the integration and respective devices. Then I upgraded to 2023.10.1 and those old entities are all unavailable and duplicated ones, not linked to the integration are created (and working ok) - as per the image above. So not sure if the 2023.10.1 fixes anything (not from my perspective at least). |
|
@allenporter So when i apply the coming patch, will my setup work without any additional changes needed? i have a very complex setup with custom schedules and automations aso, and id rather wait for 2023.11 to be honest, If applying this new patch (which i assume would be 2023.10.2, not 2023.10.1) means redoing my setup. Anyway, thanks for all the fast fixes and keeping us up to date! |
|
Correct, from #101470 (comment) I realized what was missing and this is fixed in #101599 scheduled for a follow up patch. I've sent #101603 which will use a mac address for existing cases that had a "zero" serial, but i'm targeting 2023.11 for that. |
|
@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 |
@adorobis this was exactly my case and everything is back once updated :) |
|
Same for me. The fix did not fix 😉 |
|
Correct, please see above. #101470 (comment) |
|
Just installed the 2023.10.2 and I can confirm that it works as expected now. Many thanks! |
|
Same here, entities are properly populated, though |
|
Thanks. We'll get it working connected through the UI to the integration entires in a follow up. |
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/AAnything 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
The text was updated successfully, but these errors were encountered: