Closed Koenkk closed 4 years ago
Thanks for this! I'm having one issue, when I call zigbee2mqtt/bedroom_lights/set, I get the following error:
Failed to find device with ieeAddr: 'bedroom_lights'
I used zigbee2mqtt/group/bedroom_lights/set instead and it works! Awesome job!
@dcshoes23 please update to the latest dev branch, zigbee2mqtt/group/bedroom_lights/set
is the "old" api (I've changed it a few hours ago).
@Koenkk Just pulled the latest-dev now and it works with zigbee2mqtt/bedroom_lights/set
, thanks!
This new fw, does it reduce the number of devices the coordinator can hold ?
@subzero79 the CC2531 firmware released together with zigbee2mqtt 1.0.0 had a limit of 20, the new firmware has a limit of 15 (because the stack has to be increased for stability reasons).
In case you only have battery powered devices (aka don't have any routers) you can use the max devices firmware which has a limit of 44 devices.
@Koenkk zigbee2mqtt/bridge/groups/[GROUP_FRIENDLY_NAME]/add
worked with the old version and now it doesn't do anything. There is nothing shown in the logs
@dcshoes23 it's zigbee2mqtt/bridge/group/[GROUP_FRIENDLY_NAME]/add
(group without s) now.
EDIT: fixed the docs.
@Koenkk that worked, thanks!
looks awesome! setting about 15 GU10 spots so groups are welcome!
How likely is the fw to be changed again in the future?
For example to be able to poll an attribute from a device on demand (like xiaomi plugs power, waiting for that feature) when is implemented do you think it will need fw rebuild?
Having to repair all devices is not something I look forward to.
How likely is the fw to be changed again in the future? For example to be able to poll an attribute from a device on demand (like xiaomi plugs power, waiting for that feature) when is implemented do you think it will need fw rebuild? Having to repair all devices is not something I look forward to.
agree on that. currently only have 4 devices, but think on upgrading soon, but upgrading the firmware without some kind of export / import seems unworkable with 30+ device.s
@subzero79 polling attributes doesn't require a firmware update.
How does this integrate in best way with Hass?
@trekker25 the OP contains a link on how to do this
Sorry how could I miss that. In 6 weeks my new kitchen is ready and then can work with it. Group of 4, another group of 4 and a group of 9 gu10 spots. Curious how this will work out as I only work with wireless switches and sensors and not adding physical switches.
Hello, Can i flash the .hex file (extracted from the zip in https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/CC2531/bin/) with the alternative flashing method? (Via Arduino, described here: https://koenkk.github.io/zigbee2mqtt/information/alternative_flashing_methods.html) Thanks in advance!
@stcraft If I remember correctly, no
@Koenkk
I've done a bit of research and testing.
It seems removing this line near the bottom of the .hex file:
:0400000500002DD0FA
will do the trick to get the file to flash. (otherwise, the script will spit an error out mentioning something about 05
)
I found this out after diff-ing the two hex files (one modded and the other not, Located here: https://github.com/kirovilya/files) This was the only change being made.
I still haven't flashed the group fw, i have 4 plugs in the attic, overall 24 devices. How does the group works if you want to change brightness or color temp? or it can just control on/off?
Also is it possible to add a group to another group? or can one device be in more than one group?
@subzero79 its the same as controlling a single device, meaning that color and color temperature can also be changed via a group.
A device can be in multiple groups.
Is it just me or does switching on/off a group not refresh the status of the light bulbs in Home Assistant? If I switch on group "Living Room" the four lights "Living1" - "Living4" still say that they are switched off. When I try to use the switch in Home Assistant on a light in the group then I get these lines from time to time:
2019-1-9 01:12:55 - info: Zigbee publish to device '0x7cb03eaa00a1184a', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null 2019-1-9 01:12:58 - error: Zigbee publish to device '0x7cb03eaa00a1184a', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: request timeout
In the other cases it just changes the switch to the now correct setting (ON) and I can switch the light off after the extra step.
@dreimer1986 this is indeed not updated, added this as a todo to the OP.
Thx for fixing it in advance ^^Did not test if color values etc are synced, but I guess not.
unfortunately it wont work for me. After stopping zigbee2mqtt need to unplug CC2531 and press reset button to start it again. even with that it can start only with clear config without devices. With clean config (without devices) i managed to add 3 xiaomi enddevices. but after restart wont start again.
log below
zigbee2mqtt@1.0.1 start /opt/zigbee2mqtt-dev node index.js
zigbee2mqtt:info 2019-1-16 20:19:52 Logging to directory: 'data/log/2019-01-16.20-19-52' zigbee2mqtt:debug 2019-1-16 20:19:52 Removing old log directory 'data/log/2019-01-16.20-08-26' zigbee2mqtt:debug 2019-1-16 20:19:53 Using zigbee-shepherd with settings: '{"net":{"panId":6754,"channelList":[11],"precfgkey":[1,3,5,7,9,11,13,15,0,2,4,6,8,10,12,13]},"dbPath":"/opt/zigbee2mqtt-dev/data/database.db","sp":{"baudRate":115200,"rtscts":true}}' zigbee2mqtt:debug 2019-1-16 20:19:53 Loaded state from file /opt/zigbee2mqtt-dev/data/state.json zigbee2mqtt:info 2019-1-16 20:19:53 Starting zigbee2mqtt version 1.0.1 (commit #28e3288) zigbee2mqtt:info 2019-1-16 20:19:53 Starting zigbee-shepherd zigbee2mqtt:info 2019-1-16 20:19:54 zigbee-shepherd started zigbee2mqtt:info 2019-1-16 20:19:54 Coordinator firmware version: '20181224' zigbee2mqtt:debug 2019-1-16 20:19:54 zigbee-shepherd info: {"enabled":true,"net":{"state":"Coordinator","channel":11,"panId":"0x1a62","extPanId":"0xdddddddddddddddd","ieeeAddr":"0x00124b0018ecde53","nwkAddr":0},"firmware":{"transportrev":2,"product":0,"version":"2.6.3","revision":20181224},"startTime":1547669994,"joinTimeLeft":0} zigbee2mqtt:info 2019-1-16 20:19:54 Currently 3 devices are joined: zigbee2mqtt:info 2019-1-16 20:19:54 0x00158d000274fe84 (0x00158d000274fe84): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) /opt/zigbee2mqtt-dev/node_modules/q/q.js:155 throw e; ^
TypeError: Cannot read property 'replace' of undefined
at Object.findByZigbeeModel (/opt/zigbee2mqtt-dev/node_modules/zigbee-shepherd-converters/index.js:20:46)
at Controller.getDeviceStartupLogMessage (/opt/zigbee2mqtt-dev/lib/controller.js:193:54)
at devices.forEach (/opt/zigbee2mqtt-dev/lib/controller.js:82:30)
at Array.forEach (node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the zigbee2mqtt@1.0.1 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-01-16T20_19_54_639Z-debug.log
is it something with dongle ? or with fw or edge version ?
Thanks
After updating to the dev branch, did you do a rm -rf node_modules && npm install
?
what i did:
and after all these steps it starts working again.
i see 2 issues:
linux kernel somehow stuck with module, didnt check if it was loaded before reboot.
incorrectly and fully switch dev and prod for zigbee2mqtt
So I'm running the latest dev branch (as of 21:00 1/22) using the standard cc2531 firmware, and I started noticing some strange behavior with groups.
On an ungrouped light, I can toggle the light on/off as fast as humanly possible and zigbee2mqtt + cc2531 will chug along happily. However, if I take the same light and add it to a 1 device group, i can barely toggle the light 4 times before the cc2531's buffer will fill up (Keeps throwing rsp error: 17) and stop taking any more requests. It'll flush itself out over the next 3-5 seconds, but the rate at which I can steadily toggle on/off without overflowing the buffer is maybe once every 1-2 seconds vs 5+ times a second for a normal light.
Anybody else hitting this and/or any ideas on how to improve this?
zigbee2mqtt | 2019-01-23T02:05:54.965Z serialport:bindings read [153/83079]
zigbee2mqtt | 2019-01-23T02:05:54.966Z serialport:unixRead Starting read
zigbee2mqtt | Wed, 23 Jan 2019 02:05:54 GMT cc-znp:SRSP <-- AF:dataRequestExt, { status: 17 }
zigbee2mqtt | 2019-01-23T02:05:54.967Z zigbee-shepherd:request RSP <-- AF:dataRequestExt, status: 17
zigbee2mqtt | zigbee2mqtt:error 2019-1-23 02:05:54 Zigbee publish to group '2', genOnOff - off - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: rsp error: 17
zigbee2mqtt | 2019-01-23T02:05:54.973Z serialport:unixRead waiting for readable because of code: EAGAIN
zigbee2mqtt | 2019-01-23T02:05:54.973Z serialport:poller Polling for "readable"
zigbee2mqtt | zigbee2mqtt:debug 2019-1-23 02:05:55 Received MQTT message on 'zigbee2mqtt/office_lights/set' with data '{"state": "ON"}'
zigbee2mqtt | zigbee2mqtt:info 2019-1-23 02:05:55 Zigbee publish to group '2', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null
zigbee2mqtt | 2019-01-23T02:05:55.110Z zigbee-shepherd:request REQ --> AF:dataRequestExt, transId: 186
zigbee2mqtt | Wed, 23 Jan 2019 02:05:55 GMT cc-znp:SREQ --> AF:dataRequestExt, { dstaddrmode: 1, dstaddr: '0x0000000000000002', destendpoint: 255, dstpanid: 0, srcendpoint: 1, clusterid: 6, transid: 186, options: 32, radius: 30, len: 3, data: <Buffer 01 b9 01> }
zigbee2mqtt | 2019-01-23T02:05:55.115Z serialport:main _write 28 bytes of data
zigbee2mqtt | 2019-01-23T02:05:55.115Z serialport:bindings write 28 bytes
zigbee2mqtt | 2019-01-23T02:05:55.117Z serialport:unixWrite Starting write 28 bytes offset 0 bytesToWrite 28
zigbee2mqtt | 2019-01-23T02:05:55.118Z serialport:unixWrite write returned null 28
zigbee2mqtt | 2019-01-23T02:05:55.119Z serialport:unixWrite wrote 28 bytes
zigbee2mqtt | 2019-01-23T02:05:55.120Z serialport:unixWrite Finished writing 28 bytes
zigbee2mqtt | 2019-01-23T02:05:55.122Z serialport:main binding.write write finished
zigbee2mqtt | 2019-01-23T02:05:55.124Z serialport:poller received "readable"
zigbee2mqtt | 2019-01-23T02:05:55.124Z serialport:bindings read
zigbee2mqtt | 2019-01-23T02:05:55.125Z serialport:unixRead Starting read
zigbee2mqtt | 2019-01-23T02:05:55.125Z serialport:unixRead Finished read 6 bytes
zigbee2mqtt | 2019-01-23T02:05:55.126Z serialport:main binding.read finished
zigbee2mqtt | Wed, 23 Jan 2019 02:05:55 GMT cc-znp { sof: 254,
zigbee2mqtt | len: 1,
zigbee2mqtt | type: 'SRSP',
zigbee2mqtt | subsys: 'AF',
zigbee2mqtt | cmd: 'dataRequestExt',
zigbee2mqtt | payload: { status: 17 },
zigbee2mqtt | fcs: 118,
zigbee2mqtt | csum: 118 }
zigbee2mqtt | 2019-01-23T02:05:55.131Z serialport:main _read reading
zigbee2mqtt | 2019-01-23T02:05:55.131Z serialport:bindings read
zigbee2mqtt | 2019-01-23T02:05:55.132Z serialport:unixRead Starting read
zigbee2mqtt | Wed, 23 Jan 2019 02:05:55 GMT cc-znp:SRSP <-- AF:dataRequestExt, { status: 17 }
zigbee2mqtt | 2019-01-23T02:05:55.135Z zigbee-shepherd:request RSP <-- AF:dataRequestExt, status: 17
zigbee2mqtt | zigbee2mqtt:error 2019-1-23 02:05:55 Zigbee publish to group '2', genOnOff - on - {} - {"manufSpec":0,"disDefaultRsp":0} - null failed with error Error: rsp error: 17
zigbee2mqtt | 2019-01-23T02:05:55.142Z serialport:unixRead waiting for readable because of code: EAGAIN
zigbee2mqtt | 2019-01-23T02:05:55.144Z serialport:poller Polling for "readable"
zigbee2mqtt | zigbee2mqtt:debug 2019-1-23 02:05:56 Check online 0x00158d000237dd9b 0x00158d000237dd9b
zigbee2mqtt | zigbee2mqtt:debug 2019-1-23 02:05:56 Check online 0x00158d000237dc1a 0x00158d000237dc1a
zigbee2mqtt | zigbee2mqtt:debug 2019-1-23 02:05:56 Check online 0x00158d000237ddb6 0x00158d000237ddb6
zigbee2mqtt | zigbee2mqtt:debug 2019-1-23 02:05:56 Check online 0x00158d000237dc52 0x00158d000237dc52
zigbee2mqtt | 2019-01-23T02:05:56.466Z zigbee-shepherd:request REQ --> ZDO:nodeDescReq
zigbee2mqtt | Wed, 23 Jan 2019 02:05:56 GMT cc-znp:SREQ --> ZDO:nodeDescReq, { dstaddr: 9722, nwkaddrofinterest: 9722 }
zigbee2mqtt | 2019-01-23T02:05:56.470Z serialport:main _write 9 bytes of data
zigbee2mqtt | 2019-01-23T02:05:56.470Z serialport:bindings write 9 bytes
zigbee2mqtt | 2019-01-23T02:05:56.471Z zigbee-shepherd:request REQ --> ZDO:nodeDescReq
zigbee2mqtt | 2019-01-23T02:05:56.472Z zigbee-shepherd:request REQ --> ZDO:nodeDescReq
zigbee2mqtt | 2019-01-23T02:05:56.473Z zigbee-shepherd:request REQ --> ZDO:nodeDescReq
zigbee2mqtt | 2019-01-23T02:05:56.475Z serialport:unixWrite Starting write 9 bytes offset 0 bytesToWrite 9
zigbee2mqtt | 2019-01-23T02:05:56.475Z serialport:unixWrite write returned null 9
Has anyone tested the work of groups with OSRAM devices (lamps and plugs)? we can't get them to work through groups. https://github.com/ioBroker/ioBroker.zigbee/issues/153
I have 4 osram gu10 paired and grouped by zigbee2mqtt.
@subzero79 and you can control these lamps through zigbee2mqtt groups?
just added two Osram Smart Plugs to my hallway group and both are working (controlled through mqtt hallway group)
@kirovilya yes I can control them No problem. On/off and brightness.
I can confirm that groups are working on cc2530. I have few pros/cons, so I will report them here.
Facts:
dev
branch of zigbee2mqtt
dev
branch of home-assistant
CC2530
flashed with CC2530ZNP-Prod_20181224.hex
1 x coordinator cc2530
, 6 x LED1545G12
bulbs (they are acting like routers!) (5 in one group, 6th standalone), Philips Hue dimmer/switch
Pros:
Cons:
rsp error: 17
(same as @glentakahashi ) and communications seems blocked for specific action like turning off bulbs
. I'm able to dim them and turn off faster then just turn off. It's weird.switch/mqtt
configuration. Looks like those params:
color_temp: true
brightness: true
rgb: true
are ignored.
zigbee2mqtt:info 1/24/2019, 3:10:37 AM Starting zigbee-shepherd
zigbee2mqtt:info 1/24/2019, 3:10:40 AM Error while starting zigbee-shepherd, attemping to fix... (takes 60 seconds)
/home/hass/zigbee2mqtt/node_modules/q/q.js:155
throw e;
^
TypeError: Cannot read property 'close' of undefined
at shepherd.start (/home/hass/zigbee2mqtt/lib/zigbee.js:45:47)
at /home/hass/zigbee2mqtt/node_modules/q/q.js:2059:17
at runSingle (/home/hass/zigbee2mqtt/node_modules/q/q.js:137:13)
at flush (/home/hass/zigbee2mqtt/node_modules/q/q.js:125:13)
at process._tickCallback (internal/process/next_tick.js:61:11)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! zigbee2mqtt@1.0.1 start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the zigbee2mqtt@1.0.1 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in: npm ERR! /home/hass/.npm/_logs/2019-01-24T02_10_40_606Z-debug.log
I have tried disconnecting and connecting it back, but looks like it's not only factor to get things working. After n-th try I got it connected - so for now... I won't touch it anymore. Frankly speaking, it's not stable at all.
Some questions:
- Is this possible to change default behavior of bulbs after getting powered on (physically) so they will stay with brightness set to 0?
- As I saw, 15 devices is limit for cc2530. Is there a way to compile `max_devices` fw like cc2531 have? if so, has anyone tried running it? I have over 30 devices in plans (on small area) so I was thinking about using one device for all of them.
@lenisko i'm hitting the rsp: 17 errors a lot as well. I spent a few hours sniffing zigbee traffic to see what was up, but honestly I'm not sure what might be causing the hang ups. out of curiosity, how many routers do you have in your network? One thing I noticed is that when you send a command to a group, all the routers in the network repeat the broadcast as well. I'm not sure how broadcasts+groups+coordinators work, but one thing I'm wondering is if the coordinator gets overflowed with requests from each of the routers as well.
@glentakahashi updated my message facts and added questions at the end. Currently it's one coordinator on cc2530. I don't have sniffer device yet so checks on my side have to wait a bit. I will answer in few hours :-)
@lenisko yea you should definitely be able to, if you basically repeat the steps at https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator/CC2531/alternatives/max_devices but do it for CC2530, you should be able to recompile with more devices.
FIRMWARE_CC2530_MAX_DEVICES
doesn't exist, so you'll have to create it, but it should be fairly easy. Copy the FIRMWARE_CC2530_DEFAULT
and change add #define MAX_NEIGHBOR_ENTRIES 1
(or 0 if you have literally no routers) and then keep bumping up #define NWK_MAX_DEVICE_LIST 15
until it stops building, and then go back to the last successful one.
And interesting, so even without any other routers in your network, you're still seeing the same issues. There must be something about the size or timeout of group broadcasts vs normal commands.
After reading http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42687-ZigBee-Broadcast-Message-Handling-and-Implementation-in-BitCloud-SDK_AT14615_ApplicationNote.pdf, I wonder if this has to do with the size of the Broadcast Transaction Table filling up the buffer very quickly.
Also in reading the z-stack code and http://www.deyisupport.com/cfs-file.ashx/__key/communityserver-discussions-components-files/104/5468.Application_2D00_Level-Tuning-of-Z_2D00_Stack.pdf, it seems that BCAST_DELIVERY_TIME
is how long (in 100ms increments - ZDNwkMgr.h:92) a broadcast should be stored in the table. The default in ZGlobals.h
is 30, which means that it's keeping around these broadcasts for 3 seconds each. MAX_BCAST
(number of entries stored) is also by default set to 4, so this means that you can only have 4 active broadcasts at a given time it seems.
Maybe tomorrow (or this weekend) I'm going to retry building a firmware that increases MAX_BCAST
to say, 16, and see if I can send out more group commands at a faster rate without hitting rsp: 17 error. I'm still not even sure rsp:17 would be thrown if MAX_BCAST
is full, but I'll find out.
The obvious downside here is that the network could start getting congested if you're sending out lots of broadcasts, which is why i presume they have such conservative defaults, but I'll see from my testing if I experience any more flakiness.
@subzero79 @sehraf Thanks for the info, we found a problem - we didnāt update the coordinatorās firmware :(
Donāt worry not the only one. on my first attempt I didnāt realize the fw was on the dev branch. I repaired 23 devices including 4 plugs in the attic (40 degrees in there) to realize after that I flashed the wrong fw.
@glentakahashi sorry for misinformation. Like @Koenkk pointed out I HAVE already 6 routers in my network (IKEA LED bubls). I wish you luck with new firmware :-) keep us informed.
Freeze and lack of ability to "restart" zigbee2mqtt
Steps:
I had same problem before, so it's not one time
log/debug https://hastebin.com/malipusole / https://pastebin.com/raw/MzfT6FtC
EDIT
Looks like soft_reset_timeout: 120
is bad idea on this setup, device crashed overnight without any reason.
https://pastebin.com/raw/9fZzQjKn
Currently my configuration looks like that
homeassistant: true
permit_join: false
mqtt:
base_topic: zigbee2mqtt
server: 'mqtt://192.168.1.1'
serial:
port: /dev/zigbee
advanced:
rtscts: false
channel: 11
baudrate: 115200
log_level: debug
log_directory: data/log/
cache_state: true
soft_reset_timeout: 0
network_key: [secret]
groups:
'1':
friendly_name: salon_light
devices:
...
one coordinator standard firmware. 3 groups... one with 4 (gu10)one with 3(gu10) and other with 2(e26) all seems to work fine.
the big issue is pairing devices I still have few xiaomi sensors refusing to pair and 4 ikea lights.
@alinelena keep those sensors close to router/coordinator that helped me for most xiaomi aqara devices with one exception (one of two door sensor is not pairing at all)
@lenisko of course i keep them close. i paired 5 door/window sensors... unfortunately one of them is stuck in 1/26/2019, 8:57:14 PM - info: door_kitchen (0x00158d0002333401): unkown - undefined unknown (EndDevice) funny bit is xiaomi sensors in past where easy like a breeze... only a motion sensors gave me a hard time
empirically i noticed i can get the first 10 sensors, bulbs ikea/xioami without any issues. 10-20 you need to swat a little bit after 20 seems to be a pain. My thought is: we may need to look on more reliable hw for larger networks.
a picture of the network is here.
is there any need for a specific router firmware... i see the one in branch dev is sep 2018.
Yes you need 20181224
see first post
* At least firmware version `20181224` is required! (available [here](https://github.com/Koenkk/Z-Stack-firmware/tree/dev/coordinator))
That's for coordinator @BudBundi. Router isn't mentioned in there
@lenisko @BudBundi seems both master and dev have the same for router.. flashed that one... and at least connects. groups seem to work reliable I am more worried of latency not that network grew... would be nice if groups can be highlighted somehow in the map.
ok so indeed it seems this firmware is somehow troublesome.
pros: when it works groups work fine and everything is brilliant cons: both yesterday and today things stopped working... yesterday was enough to restart and everything re-paired... today things did not work seems nothing re-pairs.
for group support in Hass i need to define it as a light?
like this: light:
correct?
This issue is used to gather feedback on the group support feature (#15).
Todo:
Notes:
20181224
is required! (available here)