57k
commented
5 years ago Hi all, I have the same problem. Would be interested in any advice how to proceed. Thanks.
Closed kaelsaes closed 5 years ago
57k
commented
5 years ago Hi all, I have the same problem. Would be interested in any advice how to proceed. Thanks.
AnhDuc85
commented
5 years ago Hi, crazy, just had this problem the first time. Never had a connection/not reporting problem with WSDCGQ01LM. Just yesterday, my WSDCGQ11LM stopped working. I'm using this sensor outside but rain-covered. So i pressed the button for 1 second to manually report the values but that didn't work. Then, I took the sensor inside, close to my coordinator and long pressed the button (without removing the device before), now the sensor work again.
kaelsaes
commented
5 years ago When I pair the device a second time following message appears: spinlock: false device already in network
ciotlosm
commented
5 years ago I found this to be usually a signal problem. Usually triggering a device wakeup (like blow hot hair in it) will send new reports, but I had to adjust position sometimes for better signal. If nothing works you can try adding routers to get around this.
basmeerman
commented
5 years ago I've the same issue; I think.
The device wasn't sending messages anymore.
Please advice what to try next (,not looking for reflashing the cc2531 since It would let me re-pair 30+ devices).
Thanks.
lolorc
commented
5 years ago the pairing process is such an hassle with zigbee2mqtt, It tooks me all afternoon yesterday to try to repair 30ish devices. And I still have some I can't pair for no reason... There must be something very wrong with the hardware/firmware/software/dunno, cause the pairing works like a charm with another zigbee coordinator (JN5168) even with the device is far from the coordinator.
tricks used to manage to pair:
basmeerman
commented
5 years ago Update: It seemed the pairing was incomplete and the network address (int) of the device changed on re-pairing (due to that I removed it before).
I edited the database.db file and made the following changes:
device information updated to fix the incomplete binding. Example: the field model was not set. I copied the values from another sensor on a different line in the file.
To have messages processed by zigbee2mqtt/zigbee sheppard I changed the nwkaddr field of the sensor (based on id) to the srcaddr that showed up in the Zigbee Sheppard logging (messages received where not recognized, transformed, and dispatched).
This all took me about 4/5 hours of analyzing logs, code, and debug info. Finally fixed it within 5 minutes argggg. The great part is I gained a lot of insight into the internal workings of it all.
@lolorc question: with regards to your zigbee coordinator (JN5168) does this work with Xiaomi/Aqara sensors (I have about 30 sensors installed and I'm looking to extend this to about 60, but are hesitant with regards to the pairing difficulties)? Why did you switch zigbee coordinator? Thanks.
FYI: I have 1 coordinator and 3 routers running CC2531 currenlty.
lolorc
commented
5 years ago @basmeerman funny we both end up changinfg database.db by hand :-)
jn5168 is the chipset used by the zigate gateway (french project, zigate.fr) There's very useful information about devices on the website. yes it does work with xiaomi/aqara.
I moved from zigate/jn5168 to zigbee2mqtt/cc253x for several reasons:
What I don't like at all with zigbee2mqtt/cc253x is the pairing process, again I really think there's something very wrong somewhere. I really hope the upgrade to z stack 3 will fix all this weirds issues. (too many zigbee2mqtt weird github issues as well)
basmeerman
commented
5 years ago @lolorc
ad pairing issues) From what I've read and experienced is the pairing a real headache, but once paired devices seem to be running stable.
ad z stack 3) From what I understand this would only work for new sensors that support z stack 3.0. This support could come either by buying new sensors (With build in support) or somehow having a firmware upgrade on all devices (which I hope for, but deem unlikely). Furthermore from what I've read is that the amount of sensors/devices supported by CC2531 is limited due to memory limits on the cc2531. So unless a new stack would mean either efficiency or 'sourcing' more work from the chip to the software bridge (I haven't read the z stack 3.0 specs) I wouldn't ge my hopes up. But then again I've been mistaken before :-)
Thanks sofar.
ryanbeaton
commented
5 years ago @basmeerman I can’t find it now but I’m sure someone knowledgeable said in one issue here that on 3.0 the ‘limit’ is removed as it can be done in software. I thought I would find it in https://github.com/Koenkk/zigbee2mqtt/issues/211 but it’s not in there.
Sent with GitHawk
blakeblackshear
commented
5 years ago @basmeerman what did you use to edit the database by hand?
lolorc
commented
5 years ago on my side I did use vim :-) I also used a script like this:
a=$(date +"%Y%m%d%H%M%S")
cp data/database.db data/database.db-$a
grep -i -v -e 0xieeeAddr1 -e 0xieeeAddr2 -e 0xieeeAddr3 -e 0xieeeAddr4 data/database.db-$a > data/database.dbto remove the devices I couldn't pair
blakeblackshear
commented
5 years ago Thanks. I didn't realize it was plain text.
basmeerman
commented
5 years ago @basmeerman I can’t find it now but I’m sure someone knowledgeable said in one issue here that on 3.0 the ‘limit’ is removed as it can be done in software. I thought I would find it in #211 but it’s not in there.
Sent with GitHawk
Thanks, If you find it let me know.
And for what you mentioned it's about the only possible explanation (offloading of the chip) for Z stack 3.0 to fullfill the aforementioned expectation on the same hardware. Or the current firmware is heavily inefficient (what I would not expect since a lot of knowledgeable people worked on it).
Hope to read more about it soon :-)
ryanbeaton
commented
5 years ago Found it, it's in https://github.com/Koenkk/zigbee2mqtt/issues/134
Read the link from @kirovilya : https://github.com/Tropicao/zigbridge/blob/master/doc/firmware_instructions.md
That guy is using Z-Stack 3.0.1
lolorc
commented
5 years ago https://github.com/HalleyAssist/zigbee-shepherd is also using Z-Stack 3. their forks (zigbee-shepertd/cc-znp/zcl*) are getting a lot updates. But I don't know what do they use them with. (the software using their zigbeer forks)
ryanbeaton
commented
5 years ago Yeah @splitice and his crew are doing some cool things https://halleyassist.com HalleyAssist supports safe, independent and healthy living in the home.
lolorc
commented
5 years ago yep looks like it's not something I could try at home to see if all the pairing issues and weird behaviors go away with Z-Stack 3 :-)
basmeerman
commented
5 years ago Could anyone please help me work item a quick breakdown to test this with zigbee2mqtt... (optimistic_mode=on; maybe I find some time next couple of weeks to work this out in between things)
Few steps to take: 1) flash new firmware to cc2531 (firmware is located on hallyassist git repo? or do I need to build it? and why?) 2) run latest version of stack @ halleyassist/zigbee-shepherd // demo should at least recognize messages received. Try to bind a bunch of sensors >20 to the newly flashed cc2531 (see if it overcomes the max device boundry - hypotheses is with Zstack3 this would be solved outside the firmware ). 3) workout diff between koenk/zigbee-shepherd and halleyassist/zigbee-shepherd to see if any API breaks, fix these. 4) run and test the new stack.
Am I missing important details? Thanks.
ryanbeaton
commented
5 years ago @basmeerman that is very close to what @kirovilya did in https://github.com/Koenkk/zigbee2mqtt/issues/211 . Maybe comment in there and work together.
lolorc
commented
5 years ago hi there,
What I've been getting a lot as well are "Recieved zigbee message of type 'devStatus' with data '"online"' of device 'undefined' (0x)"
Oct 02 08:05:30 cc-znp:SREQ --> ZDO:simpleDescReq, { dstaddr: 0, nwkaddrofinterest: 0, endpoint: 6 } +1ms
Oct 02 08:05:30 cc-znp { sof: 254,
Oct 02 08:05:30 cc-znp len: 1,
Oct 02 08:05:30 cc-znp type: 'SRSP',
Oct 02 08:05:30 cc-znp subsys: 'ZDO',
Oct 02 08:05:30 cc-znp cmd: 'simpleDescReq',
Oct 02 08:05:30 cc-znp payload: { status: 0 },
Oct 02 08:05:30 cc-znp fcs: 96,
Oct 02 08:05:30 cc-znp csum: 96 } +13ms
Oct 02 08:05:30 cc-znp:SRSP <-- ZDO:simpleDescReq, { status: 0 } +2ms
Oct 02 08:05:30 cc-znp { sof: 254,
Oct 02 08:05:30 cc-znp len: 14,
Oct 02 08:05:30 cc-znp type: 'AREQ',
Oct 02 08:05:30 cc-znp subsys: 'ZDO',
Oct 02 08:05:30 cc-znp cmd: 'simpleDescRsp',
Oct 02 08:05:30 cc-znp payload: Oct 02 08:05:30 cc-znp { srcaddr: 0,
Oct 02 08:05:30 cc-znp status: 0,
Oct 02 08:05:30 cc-znp nwkaddr: 0,
Oct 02 08:05:30 cc-znp len: 8,
Oct 02 08:05:30 cc-znp endpoint: 6,
Oct 02 08:05:30 cc-znp profileid: 265,
Oct 02 08:05:30 cc-znp deviceid: 5,
Oct 02 08:05:30 cc-znp deviceversion: 0,
Oct 02 08:05:30 cc-znp numinclusters: 0,
Oct 02 08:05:30 cc-znp inclusterlist: <Buffer >,
Oct 02 08:05:30 cc-znp numoutclusters: 0,
Oct 02 08:05:30 cc-znp outclusterlist: <Buffer > },
Oct 02 08:05:30 cc-znp fcs: 204,
Oct 02 08:05:30 cc-znp csum: 204 } +7ms
Oct 02 08:05:30 cc-znp:AREQ <-- ZDO:simpleDescRsp, { srcaddr: 0, status: 0, nwkaddr: 0, len: 8, endpoint: 6, profileid: 265, deviceid: 5, deviceversion: 0, numinclusters: 0, inclusterlist: <Buffer >, numoutclus
ters: 0, outclusterlist: <Buffer > } +3ms
Oct 02 08:05:30 zigbee-shepherd:msgHdlr IND <-- ZDO:simpleDescRsp +1ms
Oct 02 08:05:30 zigbee-shepherd Device: 0xcc2531_1 join the network. +13ms
Oct 02 08:05:30 zigbee2mqtt:debug 2018-10-2 08:05:30 Recieved zigbee message of type 'devIncoming' with data '"0xcc2531_1"' of device 'undefined' (0xcc2531_1)
Oct 02 08:05:30 zigbee2mqtt:info 2018-10-2 08:05:30 Device incoming...
Oct 02 08:05:30 zigbee2mqtt:info 2018-10-2 08:05:30 MQTT publish, topic: 'zigbee2mqtt/bridge/log', payload: '{"type":"pairing","message":"device incoming"}'
Oct 02 08:05:30 zigbee2mqtt:debug 2018-10-2 08:05:30 Recieved zigbee message of type 'devStatus' with data '"online"' of device 'undefined' (0xcc2531_2)
bbrendon
commented
5 years ago So what was the answer to the original issue? I have a sensor that disconnects and never reconnects unless i fiddle with it.
zen2
commented
5 years ago So what was the answer to the original issue? I have a sensor that disconnects and never reconnects unless i fiddle with it.
I don't know if that can help you but I got actually 12 routers and 12 end devices here and I lost connection with one sensor EndDevice after I have switch off (main power) the bulb router in the same room and to have move in the room this sensor EndDevice. Before I realize the bulb was not powered at all, I've tried to pair again the sensor but with the unknown device result.
Then I realize the bulb was switched off and I switch on it then I retry to pair the sensor again with the same procedure and the sensor pairs perfectly this time.
In my case I suppose the sensor was using the nearby bulb as router to send its data and so coudn't do it anymore since the bulb was switched off at main power level so moving a EndDevice can bring a disconnect if It can reach his affected router anymore. I don't know actually how really cached routes are refreshed
re-pairing procedure:
service zigbee2mqtt stop
cp database.db database.db.bak
grep -v '0x00158d000272112a' database.db.bak > database.db
service zigbee2mqtt start
# reset device sensor to apair it
Hi,
sometimes a Xiaomi device (temp sensor) doesn't send values anymore although it worked for many days without a problem.
How can i reconnect this device? Do i have to bind it again? With coordinator or router?
Thanks.