Thanks for the instructions!
Just to be sure - in the core.device_registry there is this one line with those 4 F-letters without any “group ending”. I suppose these F-letters needs to be removed also?
No don’t, only entries ending with /goup/N need to be updated
OK - Thanks!
Even if the “id” is identical with the rest ending with “groups” …
Something that annoys me with phoscon is that there is no button to add a new sensor in mobile mode. Why!?
Is this only required if you have auto-generated groups in phoscon, or all groups?
And apologies for the remedial questions but I assume you shutdown home assistant using Configuration -> Server Control -> STOP (under Server Management), and you would still have access to the .storage files using Samba?
How then do you update home assistant before finally restarting? Running standard HASSIO
David. I have noticed that it is only the groups in Phoscon that actually have lights below them that gets imported into Home Assistant. I have many auto generated groups in Phoscon that get created when you add remote controls. I guess the idea is that you can then easily add lights to the new remote. I never used this feature. Instead if manually created groups and added lights to them and I do all control from Home Assistant. The only reason I create Deconz groups is to enable smooth increase and decrease like I have descibed here
So I had one group for every room in my house - total of 7 or 8 that I had to fix.
With Robban’s work around you can now…
If you did not already upgrade to 0.104 - then simply follow Robban’s JSON file hack. It is much less steps and less risk of messing up
If you did the upgrade and have a recent snapshot - then roll back to the snapshot - do the file hack with Home Assistant stopped - then restart Home Assistant and do a normal upgrade
If you do not have a recent backup and you upgraded then you have to do all my steps. Or remove the deconz integration completely and start over again. That may be much harder because you probably did some renaming and tweaks you have forgotten about.
Wow. Never have i had the thought to move the mobile to horizontal to check if it works. That’s much better. But still weird it doesn’t work in portrait.
There is a new bug someone raised and it is worse than you may think.
When home assistant triggers a deconz.device_refresh ALL my automations that have a deconz device as trigger are triggered.
My alarm system starts. My TV and amplifier turns on. My toilet flushes (yes I have automated my toilet with an IKEA button) and light turns on and off and end up in some random state depending on which automation ran first. This is really bad. Especially if this device refresh gets triggered duing startup or any other time. I can see in my log that 650 automation start and stop events were triggered. The whole house becomes a madhouse when I run the command
EDIT: I have added more info to the bug report. What happens is that the device_refresh triggers false events for every sensor you have and that triggers all the automations that have these events as triggers. See bug report.
2 Likes
Sorry to hear how 0.104.1 has caused you deconz grief but when everything is ultimately resolved, please take a moment to create a new topic explaining how you implemented ‘remote-control flushing’. I don’t think I’ll do it but I am curious to know what you used to achieve it.
Good luck with the deconz issue.
1 Like
My single lights are working as it should, but all the groups are unavailable…
Edit: thank @KennethLavrsen, that worked
I am working for several weeks with my RaspBee unable to find any switches with the search and I am getting now a slight suspicion that the RaspBee is not found by my Rpi.
I am using Hassos on a RPI4.
These are my devices:
serial:
* /dev/ttyAMA0
* /dev/ttyS0
input:
disk:
* /dev/mmcblk0p7
* /dev/mmcblk0p2
* /dev/mmcblk0p5
* /dev/mmcblk0p6
* /dev/mmcblk0
* /dev/mmcblk0p3
* /dev/mmcblk0p4
* /dev/mmcblk0p1
* /dev/mmcblk0p8
gpio:
* gpiochip504
* gpiochip0
* gpiochip100
audio:
* 0:
* name: bcm2835_alsa - bcm2835 ALSA
* type: ALSA
* devices:
* [object Object]
* [object Object]
* [object Object]
That is my clean and simple config
{
"device": "/dev/ttyAMA0",
"vnc_password": ""
}
This is what I am getting in the log,…
17:17:20:282 GW firmware version: 0x00c80000
17:17:23:244 try to reconnect to network try=2
17:17:28:245 try to reconnect to network try=3
17:17:30:276 dev /dev/ttyAMA0
17:17:30:276 GW firmware version: 0x00c80000
17:17:33:244 try to reconnect to network try=4
17:17:38:245 try to reconnect to network try=5
17:17:40:271 dev /dev/ttyAMA0
And this is my lovely Phoscon UI
I’ve just removed the integration before updating HA to 0.104.x and then, put back the integration and everything was fine.
Yes that works just as well 
I’ve been having this issue before 104.1 though i did have the beta’s as well.
I dont do any hacking.
I just remove the stale integration click on it and click the trash can then i click on configure on the newly discovered one.
Only issue i have with names is my hue motion sensor
Has 3 sensor and sometime the temp or the lux fight it out as to which get the _2.
This somewhat worked for me. Did all this, it still created _2 for the groups… but the regular group kept working. Removed all the _2 groups (were unavailable anyway), got it to work now. Thanks!
Seems to be fixed in 0.104.2
I’ve pushed fixes for both reported issues. Both are part of 0.104.2
3 Likes
Just upgraded straight to 0.104.2. Haven’t had the problem with duplicated groups.
Does it matter that the groups from the deconz integration still have the four "F"s in device-registry file after the upgrade?
Thanks for providing such a quick fix!
The fix keeps the old base for group unique id which will then have those four F