IKEA Parasoll sensors going offline #22579
Comments
|
I have two of them. One is working fine (for weeks/months), the other is going offline after a few hours (also after repairing). |
|
I humbled across this issue and I just wanted to share my experience with the Parasoll Sensor - due to the same reasons with the new IKEA sensors I put in 1,2V batteries (IKEA Ladda and another brand) as well and my sensor dropped off after few minutes.. ironically I then put in cheap 1,5V discounter batteries (Tronic by Lidl) and my sensor is now running fine since 4 days. Until today I only had this one Parasoll sensor, but I bought two additional Parasoll, where I put in same brand 1,5V as well - in case this experience changes with the other sensors I'll let you know. I also have a similar setup: Adapter Setup |
|
Same issue here, with a large number of Parasoll sensors and a mix of Ikea Ladda and another brand rechargeables. I went through all of them yesterday and they were working, now (~16 hours later) found a few already which aren't updating anymore. I have found a few sub-cases while doing that:
The issue is quite universal, regardless of whether the sensors are connected to the coordinator or one of the routers in the network. There doesn't seem to be any relation to signal strength, location, frequency of usage or anything that I can think of. Other Zigbee devices in my network (including various other Ikea products) seem to be working fine. I tried this with both drivers (ember and ezsp), and a few successive versions of Z2M, and of dongle firmware - same behaviour. I didn't test yet with a different software, but some reports online suggest that the issue only occurs with Z2M (they seem to work fine in ZHA), which would indicate an issue specific to Z2M. I am not a Z2M expert, so not sure what logs are relevant and what not. Last time I enabled debug logging, I ended up with a machine freeze after a few hours, so I am a little cautious about doing that again. Happy to help with debugging, if someone can point me in the right direction. |
|
After upgrading the firmware of my Sonoff Zigbee USB Dongle Plus (P) coordinator to 20230507, both of my PARASOLL sensors are online and reporting fine, for a few weeks now. Also using the LADDA rechargables. |
|
I see a similiar issue with the PARASOLL sensors using LADDA rechargables. They get unavailable after approx. 2 weeks. Running Sonoff ZBDongle-E with MultiPAN RCP firmware 4.3.1. |
|
Dongle-E as well myself, various versions of the NCP firmware. I gave up for now, unless someone has some ideas for troubleshooting. |
|
I switched to NCP 7.4.2.0 FW and the ember driver. Let's see if this helps. @9shearer Do you use the ezsp or ember driver? |
|
@meiser79 I am facing the same issue on ember and on ezsp (both NCP). |
|
@Koenkk Hi, may we ask for some advice how we could troubleshoot this issue? Thanks a lot! |
|
To add to the user reports: I am in the same situation of @JBS5 from the beginning of the addition of the 4 Parasoll sensors to my Zigbee network, and I haven't had any connectivity issues ever since (3 months at the time of writing). I use a Sonoff ZB-Dongle-P with firmware |
Yes. Tested with both EZSP and Ember on 7.4.2.0 (and a couple of prior versions on EZSP), no change.
Not in my case. I have a bunch of Parasoll sensors running with a mix of power sources (Ikea Ladda and other generic brand rechargeables, generic one-time batteries). The behavior is always the same:
|
|
Any suggestion regarding targeted logging, @Koenkk ? Setting a global debug and then excluding devices one by one isn't very effective in my case, as I have a lot of devices. |
|
This is probably not going to do anything, but it's worth a shot. If you can run de dev/edge release, try binding the manuSpecificIkeaUnknown cluster to the coordinator. |
|
@sjorge I get below error when trying to bind manuSpecificIkeaUnknown to the cluster. BTW, the LADDA battery lasts for one week in the PARASALL sensor. |
|
|
|
The PARASOLL sensor was at least shown as available. And I opened the window once to somehow wake it up. |
|
Ive had the same issues and just been replacing the battery thinking it was dead (despite it reporting 100% in Z2M) and after changing the battery is back online. But again about 2 weeks or so and it doesn't show as unavailable or offline, just doesn't update to open or close |
|
• 3 IKEA Parasoll Sensors running There's obviously something draining the batteries. The device which failed had a battery state of 83%. My two others currently have a battery state of 83% and 86%. I'm giving them two more weeks before failing. Is this an IKEA firmware bug, IKEA hardware bug, or a Zigbee2MQTT thing where it's somehow polling on and on and destroying the battery life? |
Are you thinking something like this issue? #14157 |
Tried the solution described there (disabling the PowerCfg report) - no effect.
|
|
Here's the funny behaviour I noticed for Sensor C mentioned above, while pulling the states for this. In the Devices list, it was showing as "last seen" 'just now' or very recently. Once the "last_seen" stopped updating, the state tab remained fixed at The "contact" didn't update at all throughout the changes (it stayed 'true', i.e. door/window closed), even if I opened it multiple times and watched the State tab in Z2M in real time - no change whatsoever with regard to the contact tab, but the displayed JSON fluctuated between the two formats above (basically update... -1 and update... idle), and the last_seen value did get updated. I went to repeat the experiment once more (same sensor, same approach) and now I am even more puzzled. The sensor continued the behaviour described above, but this time the "contact" in Z2M got updated once to "false" (i.e. door/window open) and it stayed like that. No matter if I opened it several times more, it still displayed "false". I am really confused how this can happen:
My coordinator is a ZB-Dongle-E, with firmware 7.4.2.0 (flashed with the web flasher from darkxst), on Z2M 1.39.0, driver Ember. I have tens of other devices in the same network which seem to be working just fine. |
|
OK a bit more info. I decided to watch the other sensor that was still working (Sensor D), and it now behaves the same as Sensor C. The battery level of Sensor D went from 97% to 86% in approximately 45 minutes. |
|
Further experimentation - Sensor A was offline for several hours, LED blinking when door/window was opened/closed, but no updates at all in Z2M (neither contact, neither last_seen, marked as "offline" in the device list). Pressing the reset button once - no change. Removing and reinserting the battery - sensor back to normal. Contact state is updated and reflected in Z2M, last_seen is current, no rapid updates of last_seen, battery level is 90% (same as it was when it had gone off the network). Sensors C and D - which had gone into the "rapid update every ~17 seconds, but no state changes" mode: just noticed their LED had become permanently 'on'. The same "rapid updates" were still happening, but this time the LED wasn't blinking anymore when opening/closing the door/window. Removing and reinserting the battery brought them back to normal behaviour (no rapid last_seen updates, proper reporting of the state in Z2M). My empiric guess of the state changes is:
@Koenkk or anyone else, any ideas? Happy to do any specific troubleshooting / logging with a bit of guidance. |
|
@9shearer could you provide the debug logging of a "everything works situation" till step 3? |
|
@Koenkk gladly. Is there a way to enable debug logging for only one / a few devices? I have tens of Zigbee devices (most of them working fine) and enabling debug logging globally doesn't work (tried once and it killed the machine where Z2M is installed). Conversely, excluding devices one by one (I believe that's what's described in the docs) is pretty cumbersome - might go down that path if there is no other way. |
|
I gave it a shot and enabled debug logging globally last night. I think we might be on to something, as despite the log files not catching the whole interval, I think they did manage to catch the interval when one of the sensors went from "all good" into "rapid fire updates every 17 seconds" behavior (so basically the transition from steps 1 to 2 (or 2 to 3). Check this out (output of "grep 0x..." from the log file directory with the address of the problem_sensor_C). Good behaviour (presumably): While I am wondering about the timing (it seems to check in randomly), I would be happy with it working. Bad behaviour ("updates" every 17 seconds, but nothing seen in the frontend): |
|
@Koenkk I hope the above helps. |
|
Did a little research in the meanwhile and the issue seems superficially similar to 22611.
And the same calls to ezspTrustCenterJoinHandler() for the misbehaving device, although it does seem that in the other thread, this is a permanent rather than temporary situation (the devices there don't work at all, while my Ikea Parasolls work for some time, until they don't). |
I had the same and did not find a way to update (no ikea hub available anymore) so I brought it back to the shop and got a new one with the working firmware |
Is there a way in the store to recognize which firmware is installed on the Parasoll sensor (whether it is the build 20230406 or 20230516)? |
Confirmed. Mine not working has also build 20230406. |
|
I have three devices, all with firmware version |
|
What do you think? Is there be any chance that Z2M 2.0.0 will fix this issue? I have two of them, both firmware 20230516. One of them is working for months without any issues, the other one gets offline every few days.
Coordinator: SONOFF Zigbee 3.0 USB Dongle Plus-P |
Unlikely, this is not thought to be a Z2M problem.
I'd suspect the LED2003G10 router, perhaps combined with running a Ti-based coordinator, is what is causing the problem in your case. |
Why could be the IKEA LED2003G10 an issue and the IKEA LED1934G3 not? |
Because different devices have different firmware that control their routing behavior. SOME Ikea router devices are notorious for causing problems when used outside of the Ikea hub ecosystem. E1746 is a well known one. You could search to see if there are any other reports of people having problems with LED2003G10, it was just a guess on my part. Plenty of people, myself included, have many Parasolls running perfectly fine. In my case, ALL of my router devices are Philips Hue devices. We're trying to narrow down what is causing problems with these devices on certain people's networks. If you do any testing, such as swapping those 2 bulbs and seeing if your good Parasoll becomes bad and the bad one good, please report back with the results. |
|
@tholland15 I have repaired the problematic PARASOLL to a https://www.zigbee2mqtt.io/devices/LED1650R5.html#ikea-led1650r5 instead of a LED2003G10, let's see what happens in the upcoming days. Still a Tradfri, but I will try a Hue as well if the PARASOLL drops again. |
|
@JBS5 what do you mean repaired? Forced to connect to it to the network using LED2003G10 as router? I just got a parasoll with the infamous firmware 20230406 and trying to find a soluion. |
|
@tholland15 for me both of them are with the May (said to be ‚good’) firmware, still one of them works normally, the other drops constantly - they are located in different rooms. |
I have deleted the PARASOLL from Z2M and repaired it via a specific device (LED1650R5): https://www.zigbee2mqtt.io/guide/usage/pairing_devices.html#pairing-via-a-specific-device |
Correct, mains powered devices cannot be set as end devices in Zigbee, only routers. Powering routers on and off destroys parts of your Zigbee network. Some devices handle that destruction and recover better than others. Some recover quickly, some recover slowly, some can never seem to recover on their own. You should never turn off power to a Zigbee router on your network (sometimes of course, it is unavoidable). When you do, you should go around and check the health of all devices on your network. I do this after power outages. I think once you finish replacing your switches, you will find your Zigbee network to be far more stable. Keep us updated! |
|
I can confirm that. In the past I had issues with the Parasoll as well. The LQI in that setup was below 40. I rebuild the setup now, the sensors now have a LQI of 90 or better. They are all running stable. Except for one, this one still has a LQI of 25. So it seems to me that parasoll can't handle weak connections. |
|
Same issue as above: all buggy sensors have 20230406. tried to pair via a specific device https://www.zigbee2mqtt.io/guide/usage/pairing_devices.html#frontend with [LED1837R5] and [LED2109G6] but no luck |
|
After many months, my parasoll went offline once again :( |
Offline again. After pairing to a specific Hue bulb, it jumped to another router. Not sure if it is possible to stick it to a specific router and prevent choosing another route after pairing? |
|
I'd personally recommend anyone with a 20230406 firmware Parasoll to buy some new ones, then return the ones that have the 20230406 firmware. Some people still have troubles with the 20230516 firmware apparently, but nothing in comparison to the ones with the 20230406 firmware. |
|
For what it's worth I had significant issues with parasol frequently going offline. I switched from a sonoff USB dongle to a znp Poe device and it seems to have resolved the problems |
|
I have 3 parasoll (20230516 firmware) frequently going offline: ("fermé" means "closed", "nothing" means "offline"):
My coordinator is a SLZB-06. I noticed that the last value is always right. If I open the window, the parasoll goes online et its state changes (from "offline" to "opened"). So, for each parasoll I created a trigger-based sensor storing the last "true" value, and I only used this sensor in my automations: template:
- trigger:
- trigger: state
entity_id:
- binary_sensor.parasoll_contact
to:
- "on"
- "off"
binary_sensor:
- name: "corrected parasoll"
unique_id: xxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
state: "{{ states('binary_sensor.parasoll_contact') }}"
device_class: windowIt works! |
|
I just wanted to chime in with my experiences with the Parasoll (E2013) sensor. I have nine, and while some are experiencing rapid battery drain, others are not. I have a stable Zigbee network with 46 routers, and the lowest LQI of any sensor is 108. My coordinator is a Home Assistant Yellow (Coordinator revision 7.4.4). I never experience any Parasoll (E2013) sensors dropping off the network—only rapid battery drain. Ironically, I bought these because they use an AAA battery, thinking it would last forever. I considered running an IKEA DIRIGERA (a really nice app with Matter bridge support and support for third-party Zigbee devices—fair play, IKEA), but I don’t really want to manage two Zigbee networks and worry about router positioning for both. All of my sensors: Sensors that behave
Sensors that don't behave
I'm currently running the latest converter supplied by @Koenkk and persisting logs to disk now so hopefully I can capture something useful and contribute to finding a fix. |
|
FWIW, my situation is still the same. For curiosity, I reconnected one Parasoll to the z2m network a few days back. It worked fine for ~2.5 days, then it started exhibiting the same behavior as before:
All my other Parasolls have been happily running in ZHA for a few months now (since early October if I remember correctly):
|
|
I've followed this thread for about 2 months now in hopes to find a solution. My issues (location 1):
All parasoll and vallhorn sensors that are connected directly to slzb-06 seem to have no issues. For location 2, almost all ikea devices and 3 aqara sensors. Maybe this is a routing issue..? |
I don't think that's the case, based on my case / data sample:
With this limited data set, common logic would say that if it works in ZHA, but not in Z2M, the issue would be somewhere in Z2M and/or the way it interacts with this particular piece of hardware and its associated firmware. For clarity, I think @Koenkk and the team are doing a fantastic job. Also, to be fair, I think the Parasolls themselves are fine hardware-wise, but we are using them outside the vendor specs. I am fairly certain they work perfectly fine with Ikea's bridge and associated ecosystem (haven't tested, so can't attest to that, but I would expect them to). |
|
You're probably right, i'm just guessing at this point... I think that a good sniff of the communication between this sensor and a dirigera hub is the best bet, or maybe check the differences between how zha and z2m communicate with the sensor? Just throwing out ideas.. |
|
@myk3y55 I also think this is a routing issue based on all the data in this thread. But unfortunately I can't help debug because my Parasolls work completely fine 100% of the time (SLZB-06M, all routers in my network are Philips Hue devices) @9shearer how long did you test with ZHA? Did you move your entire network with all devices in your home over to ZHA for the test? There are lots of reports in this thread and in other places on the internet of people having similar problems in ZHA with Parasolls as others report here with Z2M. This is what makes me think it is a routing issue. I suspect when you tested Parasolls with ZHA you did not move 100% of your devices to ZHA or test long enough and that is why you did not see issues on ZHA. However if I'm wrong in that suspicion it would be helpful to know. |
|
Ok, i paired a parasoll sensor 2 days ago to test and play around hoping that i might get it to not respond and it just happened today. The sensor blinks when opened or closed but does not update status in z2m and ha, fw 20230516, currently connected via a ikea LED1732G11 that is connected via hue 8718699703424 that is connected to the coordinator (checked via map in z2m). The ikea LED1732G11 has other end devices connected to it like an aqara temp sensor, ikea rodret remote and an ikea fyrtur blind that all work without any issue. Logs show nothing on this device when i checked. The only thing that has changed was to bring an ikea E1603/E1702/E1708 plug from another room into the test parasoll room last night and today i took that plug back to it's original room and installed a tetrakt plug into test parasoll room (i don't know if this info helps, but i'm including it). As i'm writing this, the sensor still doesn't update it's status and i won't do anything to it any further, so if anyone has any test idea, i'm all ears :) EDIT: i suspect that these sensors do not play well when connected via routers that are not ikea and this one has a hue router between it and the coordinator |
|
@myk3y55 after you move routers around for testing, I would:
This is because I'm not sure if the Parasoll will ever recover on its own once it gets into a "bad" state without a power cycle. |
|
@tholland15 i'm not sure if that caused it. I usually do as you suggest when one goes "bad". Now i just did deliberately tried and cut power to it's router (after i got it going again) and it immediately connected to another router and worked flawlessly afterwards so it seems to cope well with losing a router.. I will continue to monitor and test various scenarios, hopefully i find something repeatable.. |
I moved all my Parasolls (along with the motion sensors that didn't work on the first shot in Z2M, I didn't want to spend time to troubleshoot those) into a dedicated network under ZHA. All my other Zigbee devices are still under Z2M. They have been working fine for ~4 months now in that setup, with two exceptions:
Until recently, both my coordinators (Z2M and ZHA networks) were Sonoff Dongle-E's (flashed with latest darkxst firmware). In the Z2M network, the routers were a mix of Dongle-E's (with Sonoff's router firmware), various bulbs and plugs, while in the ZHA network, I had Dongle-E's and a handful of plugs as routers. |
and others
What happened?
I've 14 IKEA Parasoll sensors connected to my zigbee network.
The sensors are going offline in Zigbee2MQTT after they should have checked in for the availability check.
My availability settings are set to advanced, 10 min timeout for active devices and 120 mins for passive.
The sensors all have new IKEA LADDA batteries which are the 1.2V type based on other known issues.
The same issue with going offline doesn't appear to happen with ZHA so the issue doesn't appear to be device related
What did you expect to happen?
No response
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.37.0
Adapter firmware version
20221226
Adapter
SONFF Zigbee Dongle-P
Setup
Add-on within Home Assistant within Proxmox VM on Intel NUC
Debug log
log1.log
Example:
[2024-05-10 10:32:54] debug: z2m: Passive device 'Back Bedroom Right Window' was last seen '2.00' hours ago.
[2024-05-10 10:32:54] debug: z2m: MQTT publish: topic 'zigbee2mqtt/Back Bedroom Right Window/availability', payload '{"state":"offline"}'
The text was updated successfully, but these errors were encountered: