Hi
I succeeded in pairing 12 Ikea Paraoll sensors. However when pairing number 13 the phoscon app only gives:
Fabrikant IKEA of Sweden
Product PARASOLL Door/Window Sensor
Versie unknown
Open/closed seems not to be detected.
I have removed the sensor and pairing again at least 10 times. No success. Another battery, unplugging the ConBee III etc. didn’t help.
Anybody an Idea what to do to solve this?
Thanks
Hello, how many routers have you ?
I have 2 routers as router and 1 router as hub configurated in use. The routers have different networksegments.
Everything with the ConBeeIII is on 1 networksegement.
Turning off the hub makes no difference.
Does it give you an Idea what the problem can be?
Thanks
IDK what is a “networksegement”, but you need zigbee routers, if you have 12 end devices without routers on the same coordinator can be an issue.
Hi Smanar
Unfortunately I didn’t understand your question and my answer was about my ethernet routers.
Yes I have indeed Zigbee routers. I have 2 FDTEK plugs which have a router function as far as I can see. (1 device is out of reach of the ConBeeIII stick and with the plug between it works.)
Most of the sensors should use the FDTEK plug and I try to pair thru the ConBee stick directly. However via a FDTEK plug has the same result.
Removing the power of 1 of my sensors doesn’t help.
At the moment I have 17 working Zigbee devices.
I will remove the batteries from 1 FireAlarm and try to pair in a few hours. But I doubt this will help.
Any more suggestions what can be wrong?
So there is no reasons.
Do you have acces to the GUI ? to catch logs during inclusion ? with “error” *2 “info” *2 at least.
You have only 13 sensors ? perhaps the problem is on the 13 th device ?
lol, and after reflexion 13 is realy a bad number for lot of people ^^
Is your conbee on the latest firmware?
If not you can update it with a chrome based browser (like Google Chrome, Edge or Opera) using our new Web-Based updater
Thanks for your suggestion.
I just updated to the firmware of 14-5-2025. The result with pairing was identical.
Hmm. I think we are have this sensor, but our company is closed till Monday. I will try to reconstruct your issue when I get my hands on the sensor.
Sorry for the inconvenience, there is nothing preventing it from working with the ConBee 3. I will get back to you
Do you have acces to the GUI ? to catch logs during inclusion ? with “error” *2 “info” *2 at least.
No, no GUI except phoscon app for pairing. I don’t see a log there.
However I looked in the logging of deconz with:
/usr/bin/deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 | tee debug.txt
I don’t see any pairing entries.
But in the logging I see a lot of errors:
11:17:22:047 DEV found DDF for 0xD44867FFFEB39501, path: /usr/share/deCONZ/devices/ikea/parasoll_open_close_sensor.json, result: 1
11:17:22:051 SQL exec failed: SELECT attr FROM sensors WHERE uniqueid = ‘a4:c1:38:0a:6e:24:9c:58-01-0500’ AND deletedState = ‘normal’, error: no such column: attr (1)
11:17:22:052 DEV found DDF for 0xA4C1380A6E249C58, path: /usr/share/deCONZ/devices/tuya/_TZ3210_up3pngle_TS0205_smoke_sensor.json, result: 1
11:17:22:058 DEV found DDF for 0xD44867FFFEB41370, path: /usr/share/deCONZ/devices/ikea/parasoll_open_close_sensor.json, result: 1
11:17:22:066 DEV found DDF for 0xA4C1383F2C372D69, path: /usr/share/deCONZ/devices/aubess/aubess_multi_sensor_TZ3000_bguser20.json, result: 1
11:17:22:070 DEV found DDF for 0xD44867FFFED34F1D, path: /usr/share/deCONZ/devices/ikea/parasoll_open_close_sensor.json, result: 1
11:17:22:074 SQL exec failed: SELECT attr FROM sensors WHERE uniqueid = ‘d4:48:67:ff:fe:b4:4b:e0-02-0500’ AND deletedState = ‘normal’, error: no such column: attr (1)
11:17:22:075 SQL exec failed: SELECT config FROM sensors WHERE uniqueid = ‘d4:48:67:ff:fe:b4:4b:e0-02-0500’ AND deletedState = ‘normal’, error: query aborted (4)
11:17:22:076 SQL exec failed: SELECT state FROM sensors WHERE uniqueid = ‘d4:48:67:ff:fe:b4:4b:e0-02-0500’ AND deletedState = ‘normal’, error: query aborted (4)
11:17:22:076 SQL exec failed: SELECT state FROM sensors WHERE uniqueid = ‘d4:48:67:ff:fe:b4:4b:e0-02-0500’ AND deletedState = ‘normal’, error: query aborted (4)
11:17:22:076 SQL exec failed: SELECT state FROM sensors WHERE uniqueid = ‘d4:48:67:ff:fe:b4:4b:e0-02-0500’ AND deletedState = ‘normal’, error: query aborted (4)
Is this normal?
When I look in the database I see:
41|PARASOLL Door/Window Sensor (12)|ZHAOpenClose|PARASOLL Door/Window Sensor|58:3b:c2:ff:fe:01:9d:70-02-0500|1.0.19|{“lastupdated”:“2025-05-29T09:04:45.186”,“lowbattery”:false,“open”:false}
43|PARASOLL Door/Window Sensor (13)|ZHAOpenClose|PARASOLL Door/Window Sensor|d4:48:67:ff:fe:b4:4b:e0-02-0500||{“lastupdated”:null,“lowbattery”:null,“open”:null}
8|PARASOLL Door/Window Sensor (2)|ZHAOpenClose|PARASOLL Door/Window Sensor|d4:48:67:ff:fe:b4:13:70-02-0500|1.0.19|{“lastupdated”:“2025-05-29T00:32:28.133”,“lowbattery”:false,“open”:false}
So it is clear the software version etc. is no inserted in the database.
It might be indeed just a defect sensor. I am not aware there is a limit of 12 or so. But it is inserted in the database so I don’t think that is the problem.
And indeed. The number 13… 
@ Haerteleric
there is nothing preventing it from working with the ConBee 3
Ok, that reduces the possibility of errors a lot.
If I can provide you with more info to tackle the problem let me know.
At the moment I suspect a defect sensor and thinking of swapping it for another one by Ikea.
Especially because 12 identical sensors working fine and 1 gives consistent the same problem.
Are they all paired to the same Router? Routers have a limit on how many sleepy end devices they can support, maybe adding another router in the area could allrdy solve your problem.
You could also try to enable “source routing” in the deconz GUI.
I don’t think you have a 802.15.4 sniffer at hand (like a conbee2)?
@ Haerteleric
I have 1, at the moment 2, powerplugs/routers in use. But during pairing, they are paired on the ConBeeIII itself. I hope they changed routing dynamically.
I use deconz/ConBeeIII without GUI on a raspberry as server.
I don’t have a hardware sniffer, but offcourse I have a ConBeeIII
I could easily build a new installation with deconz-gui and plug the conbeeIII in that installation for testing if that would help.
But for that I need instructions how/what to do with/during the sniffing.
Btw if there are somewhere instructions in german that is ok for me.
Sleepy End Devices (like your sensor) don’t perform routing. Instead, they search for a permanently powered parent device and, once connected, communicate exclusively with that parent. The parent buffers all communication to the End Device until it detects that the device is in a receive state (they sleep about 99% of the time to preserve battery). At that point, it forwards any buffered messages.
This design limits how many End Devices a parent (router or coordinator) can support, since it has to individually buffer messages for each one. While End Devices can technically switch parents, doing so often causes issues in practice. For example, the ConBee coordinator can handle up to 32 (possibly 64—I need to double-check) End Devices, but other devices may support far fewer; I’ve seen limits as low as 4.
As a general guideline, I recommend having at least one router for every 8 Sleepy End Devices. Also, always try to pair End Devices at the location where they will actually be used. This helps ensure they connect to the most suitable parent in their environment, reducing the risk of communication problems later on.
Just search for “e27 zigbee” on Amazon or eBay-kleinanzeigen if you’re looking for some cheap Zigbee Routers to strengthen your mesh.
Hi
I installed deconz on a testmachine and plugged the ConBeeIII in. Played around with the database, stopped the deamon etc. At last the 13th sensor was added and functioned correct. Don’t ask me what the reason is why it works now.
I guess the suggestions of Haerteleric and Smanar maybe the reason. It is clear I changed the mesh routing when I placed the conbee on another place in house. That it finally worked supports the theories about the routers.
I will buy an additional plug from Ikea and place the plugs on strategical places.
Thanks Haerteleric and Smanar for your help.
Another question, in the logging I see the errors below. The ‘sensors’ table has indeed no column ‘attr’ . I can’s see why the first select crashes. Should I fix the zll.db somehow? Or is this ’ normal’ and no reason for concern?
21:24:10:616 SQL exec failed: SELECT groups FROM nodes WHERE mac = ‘a4:c1:38:52:1f:0b:21:5b-01’, error: query aborted (4)
21:24:10:620 SQL exec failed: SELECT attr FROM sensors WHERE uniqueid = ‘a4:c1:38:52:1f:0b:21:5b-01-0702’ AND deletedState = ‘normal’, error: no such column: attr (1)
21:24:10:623 SQL exec failed: SELECT attr FROM sensors WHERE uniqueid = ‘a4:c1:38:52:1f:0b:21:5b-01-0b04’ AND deletedState = ‘normal’, error: no such column: attr (1)
For me thoses errors are not important.
There is lot of SQL error on logs, some of them disapear after a time (the database is updated regulary)
This one just mean deconz have made a search in the database to find in the sensor table data with searching with uniqueID, and this search have failed.
And according to the uniqueID, it was a plug, so nothing to see with your sensors.