Yooksmart D10110 shows as "Not Supported" -- Used to work

[keness521]

Upgraded to .12, after updating NodeJS, and three Yooksmart D10110 devices now show as "Not Supported" and their associated Scenes have disappeared.

I suspect this might be a deCONZ issue, because I saw that the deCONZ dependency had bumped up to 2.14.1, so I updated deCONZ as well. I think maybe I should have left it alone.

I did try rolling homebridge-deCONZ back to .11, and it still shows "Not Supported", which also points me to the problem being deCONZ.

Is it as easy to roll-back to the previous version deCONZ as it is for a Homebridge plugin? I suspect it is a bit harder... hah

[ebaauw]

Did they work in Homebridge deCONZ or in Homebridge Hue? What type of device are these?

To downgrade deCONZ, download the .deb package and install that manually:

wget https://deconz.dresden-elektronik.de/raspbian/stable/deconz-2.13.04-qt5.deb
sudo dpkg -i deconz-2.13.04-qt5.deb

[keness521]

They did work in .11. It’s the same window covering devices that I brought up in my other issue (#5) which had the battery service that wasn’t working before. (As you stated, the battery service errors were fixed in .12.)

So unless somehow the battery service functionality is causing HomeKit to not recognize the device correctly anymore, I would assume something has changed with deCONZ.

[keness521]

Here is the section of the log. I might not be reading it correctly, but although I see the battery services, I don't see the actual devices (Named Office Shade 1, Office Shade 2 and Office Shade 3 being added...)

[13/02/2022, 13:32:09] [deCONZ] Loaded homebridge-deconz v0.0.12 child bridge successfully [13/02/2022, 13:32:09] Homebridge v1.4.0 (HAP v0.10.0) (Camera) is running on port 41557. [13/02/2022, 13:32:09] Loaded 6 cached accessories from cachedAccessories.0E178C88673C. [13/02/2022, 13:32:09] [deCONZ] homebridge-deconz v0.0.12, node v16.14.0, homebridge v1.4.0, homebridge-lib v5.2.3 [13/02/2022, 13:32:09] [deCONZ] Phoscon-GW: dresden elektronik deCONZ / ConBee II gateway v2.14.1 [13/02/2022, 13:32:09] [deCONZ] Phoscon-GW: Battery 23: add accessory [13/02/2022, 13:32:09] [deCONZ] Battery 23: yooksmart D10110 v20201120 (1 resources) [13/02/2022, 13:32:09] [deCONZ] Phoscon-GW: Battery 24: add accessory [13/02/2022, 13:32:09] [deCONZ] Battery 24: yooksmart D10110 v20201120 (1 resources) [13/02/2022, 13:32:09] [deCONZ] Phoscon-GW: Battery 25: add accessory [13/02/2022, 13:32:09] [deCONZ] Battery 25: yooksmart D10110 v20201120 (1 resources) [13/02/2022, 13:32:09] [deCONZ] Phoscon-GW: Outside Signage: add accessory [13/02/2022, 13:32:09] [deCONZ] Outside Signage: LUMI lumi.switch.b2naus01 v0x00000019 (2 resources) [13/02/2022, 13:32:10] [deCONZ] Phoscon-GW: Office Lights: add accessory [13/02/2022, 13:32:10] [deCONZ] Office Lights: LUMI lumi.switch.b1naus01 v09-06-2019 (1 resources) [13/02/2022, 13:32:10] Homebridge v1.4.0 (HAP v0.10.0) (deCONZ) is running on port 32416. [13/02/2022, 13:32:10] [deCONZ] hardware: Raspberry Pi 4B 1.2 (4GB) [13/02/2022, 13:32:10] [deCONZ] os: Raspbian GNU/Linux 10 (buster) [13/02/2022, 13:32:10] [deCONZ] restored 6 accessories from cache [13/02/2022, 13:32:11] [deCONZ] 1 gateways [13/02/2022, 13:32:11] [deCONZ] Phoscon-GW: websocket connected to ws://192.168.1.61:4531

[ebaauw]

Just double-checked: my mains-powered lumi.curtain is exposed correctly under deCONZ v2.14.1 and Homebridge deCONZ v0.0.12. My IKEA FYRTUR and Aqara Roller Shade Driver E1 window covering devices are still on deCONZ v2.13.4, awaiting the merge of my PR to support the E1.

I see it restores accessories from cache, maybe something broke in the Homebridge deCONZ update (it's still under development). Could you please un-expose the device, wait for it to disappear from HomeKit, and the re-expose it, just to be sure? Please make sure to run Homebridge in DEBUG mode, and set the gateway Log Level to 2, to capture debug messages while re-exposing it.

[ebaauw]

v0.0.13 contains some bug fixes for Window Covering devices, but nothing related to this issue.

[keness521]

You mentioned it loading the accessories from cache, so I figured I would start simple, and just removed the cached accessories from Homebridge first (Homebridge Settings > Remove Single Cached Accessory) but that didn't work. It did remove the tiles from HomeKit (which had said "Not Supported"). They didn't reappear when I turned Lights Expose to OFF and then back to ON later.

I looked in Phoscon, and they were actually GONE from Phoscon.

Tried to add the accessories back into Phoscon/deCONZ, but was unable.

Used deconz line command tool, and it appears that the lights component of the accessory was in fact completely gone, BUT the battery "portion" of the accessory was still there in sensors.

So I removed the orphaned battery sensors, since they prevent from adding the device back to deCONZ.

Had a hard time adding them back into deCONZ/Phoscon, took many many tries. It would add the battery sensor, but not the main device, for ONE of the shades (there are three) but this is unrelated to the plugin. It is either a deCONZ or device issue.

Once added back into Phoscon, they worked the same as they worked before.

Something went bad either with the deCONZ update or the .12 update. I suspect deCONZ, since the shades disappeared form deCONZ (even though my Aqara LUMI devices did not).

(I have since updated to .13, it is still working fine.)

These Yoolax shades have been very problematic on a number of levels. They "fall out" of deCONZ/Phoscon now and then, often leaving their battery sensor behind (which prevents re-adding them unless you manually delete the battery sensor) and they report their position very poorly. I'm not sure if it is the devices themselves, or if their implementation in deCONZ is not currently robust.

I've found that the only reliable way to "open" and "close" them is to create a scene where they are opened to 99% and to close them, to create a scene where they are closed to 1%. If you just try to OPEN or CLOSE, they don't work correctly at all. And the representation in HomeKit is almost never correct. I think in .13 you made some updated to this in the plugin, but I suspect, for these devices, the root problem is in the device or in deCONZ.

[ebaauw]

Used deconz line command tool, and it appears that the lights component of the accessory was in fact completely gone, BUT the battery "portion" of the accessory was still there in sensors.

That’s weird, afaik, /lights resources can only disappear when deleted through the API, or when the corresponding node is removed from the GUI. I think the GUI now removes all resources for the node. Just to be sure: did you check the database for corruption and if you’re on a Raspberry Pi: the file system on the uSD card?

They "fall out" of deCONZ/Phoscon now and then

Never seen that. I’ve had my fair share of devices going MIA, and even leaving the network, but I’ve never seen resources gone missing.

I've found that the only reliable way to "open" and "close" them is to create a scene where they are opened to 99% and to close them, to create a scene where they are closed to 1%.

Homebridge Hue and Homebridge deCONZ only use lift to set the blind state; it doesn’t use open. Afaik, deCONZ will send a Go to Lift Percentage on setting lift. Unless of course, the Yooksmart uses a non-standard way to expose the window cover function.

And the representation in HomeKit is almost never correct.

It’s based on the lift value reported by deCONZ.

[keness521]

Thanks for the clarity.

I hope I was clear that as far as I can see, the issues with this device are either because it is non-standard, or incomplete/poor deCONZ support, NOT issues with your plugin. I point them out in case I may be wrong, but it doesn’t seem like a plugin issue.

These window shade motors are the only ZigBee devices (and I have hundreds, across three HomeKit homes) that ever ‘disappear’ from Phoscon. And they’ve done it multiple times. And every time, they leave their battery sensor in the sensors list even though the main device in the lights list disappears. I’m pretty sure it is not due to database corruption, because I have started over from a brand new Raspberry Pi image a couple times after it happened, and it would still do it. My Pi’s boot and run from an M.2 SSD, not uSD, so there shouldn’t be file system corruption either.

I think my purchase of these window shade devices was a mistake, especially now that HomeKit native with Thread devices are available, but I am stuck with them now. They are very large and custom sized. I might change the motor to a more reliable ZigBee battery motor when one becomes available.

[keness521]

Devices now working same as before, issues not plugin related.