search

Koenkk / zigbee2mqtt

Zigbee šŸ to MQTT bridge šŸŒ‰, get rid of your proprietary Zigbee bridges šŸ”Ø
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.31k stars 1.61k forks source link

Testing: group support #764

Closed Koenkk closed 4 years ago

Koenkk commented 5 years ago

This issue is used to gather feedback on the group support feature (#15).

Todo:

Notes:

dcshoes23 commented 5 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'

dcshoes23 commented 5 years ago

I used zigbee2mqtt/group/bedroom_lights/set instead and it works! Awesome job!

Koenkk commented 5 years ago

@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).

dcshoes23 commented 5 years ago

@Koenkk Just pulled the latest-dev now and it works with zigbee2mqtt/bedroom_lights/set, thanks!

subzero79 commented 5 years ago

This new fw, does it reduce the number of devices the coordinator can hold ?

Koenkk commented 5 years ago

@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.

dcshoes23 commented 5 years ago

@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

Koenkk commented 5 years ago

@dcshoes23 it's zigbee2mqtt/bridge/group/[GROUP_FRIENDLY_NAME]/add (group without s) now.

EDIT: fixed the docs.

dcshoes23 commented 5 years ago

@Koenkk that worked, thanks!

trekker25 commented 5 years ago

looks awesome! setting about 15 GU10 spots so groups are welcome!

subzero79 commented 5 years ago

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.

trekker25 commented 5 years ago

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

Koenkk commented 5 years ago

@subzero79 polling attributes doesn't require a firmware update.

trekker25 commented 5 years ago

How does this integrate in best way with Hass?

Koenkk commented 5 years ago

@trekker25 the OP contains a link on how to do this

trekker25 commented 5 years ago

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.

EquinoxTheGryph commented 5 years ago

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!

Koenkk commented 5 years ago

@stcraft If I remember correctly, no

EquinoxTheGryph commented 5 years ago

@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.

subzero79 commented 5 years ago

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?

Koenkk commented 5 years ago

@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.

dreimer1986 commented 5 years ago

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.

Koenkk commented 5 years ago

@dreimer1986 this is indeed not updated, added this as a todo to the OP.

dreimer1986 commented 5 years ago

Thx for fixing it in advance ^^Did not test if color values etc are synced, but I guess not.

timota commented 5 years ago

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 () at Controller.onZigbeeStarted (/opt/zigbee2mqtt-dev/lib/controller.js:81:17) at zigbee.start (/opt/zigbee2mqtt-dev/lib/controller.js:149:26) at shepherd.start (/opt/zigbee2mqtt-dev/lib/zigbee.js:64:17) at /opt/zigbee2mqtt-dev/node_modules/q/q.js:2055:17 at runSingle (/opt/zigbee2mqtt-dev/node_modules/q/q.js:137:13) at flush (/opt/zigbee2mqtt-dev/node_modules/q/q.js:125:13) 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! /root/.npm/_logs/2019-01-16T20_19_54_639Z-debug.log

is it something with dongle ? or with fw or edge version ?

Thanks

Koenkk commented 5 years ago

After updating to the dev branch, did you do a rm -rf node_modules && npm install?

timota commented 5 years ago

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

glentakahashi commented 5 years ago

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
kirovilya commented 5 years ago

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

subzero79 commented 5 years ago

I have 4 osram gu10 paired and grouped by zigbee2mqtt.

kirovilya commented 5 years ago

@subzero79 and you can control these lamps through zigbee2mqtt groups?

sehraf commented 5 years ago

just added two Osram Smart Plugs to my hallway group and both are working (controlled through mqtt hallway group)

subzero79 commented 5 years ago

@kirovilya yes I can control them No problem. On/off and brightness.

lenisko commented 5 years ago

I can confirm that groups are working on cc2530. I have few pros/cons, so I will report them here.

Facts:

Pros:

Cons:

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.
glentakahashi commented 5 years ago

@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.

lenisko commented 5 years ago

@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 :-)

glentakahashi commented 5 years ago

@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.

kirovilya commented 5 years ago

@subzero79 @sehraf Thanks for the info, we found a problem - we didnā€™t update the coordinatorā€™s firmware :(

subzero79 commented 5 years ago

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.

lenisko commented 5 years ago

@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.

lenisko commented 5 years ago

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:
  ...
alinelena commented 5 years ago

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.

lenisko commented 5 years ago

@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)

alinelena commented 5 years ago

@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. sensors

alinelena commented 5 years ago

is there any need for a specific router firmware... i see the one in branch dev is sep 2018.

BudBundi commented 5 years ago

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))
lenisko commented 5 years ago

That's for coordinator @BudBundi. Router isn't mentioned in there

alinelena commented 5 years ago

@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.

sensors

alinelena commented 5 years ago

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.

trekker25 commented 5 years ago

for group support in Hass i need to define it as a light?

like this: light:

correct?