Test before release 0.9.0

[kirovilya]

Hi guys. @Apollon77 @arteck @allofmex @modmax You are the advanced users of this adapter. Before the release of version 0.9.0, I am very concerned about the stability of the adapter. I do not have so many devices to test its operation, therefore, check on your test systems. Also, the last of our changes mixed up and now it’s difficult for me to make sure that what you made was not lost among other changes.

Please see the current dev-branch. If critical problems are not revealed until Monday, we will be released. Thank you!

[allofmex]

Device Info tab and Developer Tab currently not working, https://github.com/ioBroker/ioBroker.zigbee/pull/154 should fix it. Groups looks nice. Thanks.

[kirovilya]

@allofmex merged

[modmax]

Just installed it and the Zigbee devices still works as expected. I will watch this from now on.

Remarks: 1.) The label "Groups" is not translated; neither in the overview, nor if you edit a device. 2.) Firfox-Browser: The network map is not displayed full size, if you open it; just a part of it is shown. See attachment. If you refresh the network map with the button in the right lower corner, then the network map is displayed. In Chrome its okay. 3.) Internet Explorer is completly out of scope; no devices and no network map is shown. Okay; it's not my favorite browser; just to be complete. Also no tested with Opera or Safaru Browser.

[Apollon77]

Sorry I will be out beginning tomorrow morning till Sunday. I can not promise much testing time :-( will try Sunday evening.

[Apollon77]

BTW: I saw that group support is added now? How I can bring threee hue lamps together and define one group? Is this described somewhere?

[allofmex]

@Apollon77 Groups is simple. Click Edit on device card and you will see. Is self explaining.

[kirovilya]

@Apollon77 https://www.youtube.com/watch?v=Jdioavy2ppQ Groups preview

[kirovilya]

@modmax Thank you for test.

1. Fixed by @allofmex
2. Fixed
3. I think iob not work with ie/edge :(

[modmax]

Next tests with groups, but at the moment I just have an OSRAM plug.

1.) Create and Delete a group Creation works; but on delete the group is not deleted in objects.

2.) Create Group and assign to a device without storage I create a Group "Test" with ID 1 on the group tab, but didn't store this via store button on buttom of adapter settings page. Then I added the group "Test" to the plug; activated it and stored the device. The device has now group "Test". But then I did not save the adapter settings. I close the zigbe adapter page; a confirmation pops up to discard changed and I choosed OK. The result is, that the group is not created, but the device has a group; you can see it in the objects view, that the plug has group 1, but it's not displayed on the device page. Also the group is not stored in iobroker objects.

3.) Created Group Test2 with id 2, stored the adapter adapter and the instance will be restated. Then I set group of plug to 2 "Test2" and stored the device. Group is present in object and also device has group with id 2. Then I changed "state" of group_2 to "true"; but the plug didn't switch. No error in logs Or do groups only work for lamps?

4.) Now deleted group 2 (named "Test2" again). Now group is still present in objects view; also group is still present in objects view of plug. So I deleted the group_2 in objects view. Also I have to go to the device info page of plug; edit the plug and stored it without change. Then the groups was emptied and in objects view for groups is now an empty array (--> []) and not undefined or unset.

At least I can see 2 errors: a.) If a group is created, then i's not enough just to store the group. You also must press the button on the bottom of the adapter page to really store the added groups. b.) Groups are just deleted from adapter page; but not in iobroker objects (group and devices which have this group).

Best regards Markus

[modmax]

Additionaly: All zigbee devices now have a "groups" entry (objects view). I think groups make only sense for Router devices and no end devices.

So end devices should not become such an object property; also the assignment of groups during editing of a device (where you can change the name) should not be possible. Also some router device shouldn't have a groups property or the ability to set a group for; like a lumi router or perhaps OSRAM plug ... :-)

[modmax]

Last test for this evening; after deletimng all groups and association zo devices, 5.) Create a group named "Test" with ID 1; save it and the complete adapter settings. Then create a new group and name it "Schalter" and set the same ID 1 for that group. Then the group will be renamed in the groupos view. Also the device has now the ne group name. But in the objects view the group_1 sill has the name "Test".

[kirovilya]

@modmax I wanted to be able to change the groups and device names without restarting the adapter - so they change without saving the settings. I can do so that a set of groups is also formed without confirming and restarting the adapter. then everything will well :)

I'm not sure yet, but for now the groups are supported only by lamps, but it seems to me that plugs/switches should also support them (I can't check). Yes, it is necessary to make groups available only for routers (they can accept commands)

[allofmex]

Groups should be available for all end devices, because non-router may have writable attributes too. Example: Someone may want to set the timeouts on all motion sensors to a shorter value between midnight and 6am than for the rest of the day.

[Apollon77]

Are groups realized via res zigbee groups or are they handled by the adapter and control the devices then sequential? I ask because i still saw delay in your group demo video. I was hoping that with real zigbee groups they are controlled more synchronously ;-)

[kirovilya]

@Apollon77 Groups are implemented using a zigbee, not an adapter. One command is sent to the group! The fact that the lamps in the video light up is not synchronous, I blame the lamp manufacturers :) - they are all different.

[Apollon77]

Ok Great. This is exactly what I wanted to hear ;-)) great job. Will try to test 0.9 tonight (>22pm) and give feedback

[modmax]

@kirovilya I mentioned, that the newly created groups are just stored, if the adapter settings are stored and not independent.

@allofmex I'm not inside the internals of Zigbee; but I think that groups make only sense for routers; cause that is where you can group (i.e. lamps) together. Groups are implemented by using Zigbee groups, and is not a self made implementation by sending the same value to several devices (one write request for each device), where groups for end devices maybe make sense. Have you tested grouping for end devices? I just have just Xiaomi sensors (weather, door, buttons) where I even cannot read any values with your developer tab, cause they are in sleep modus and just wakeup for sending.

[allofmex]

@modmax You are right, I didn't fully understood the groups.

If I try to read group info from hue motion sensor, I get unsupClusterCmd response. Could not manage to read group info from my router devices, but at least they respond with notFound {"msg":{"status":139,"groupid":0,"groupname":""}}

@kirovilya Plugs/switches should work out-of-the-box in current dev branch if they support groups right? I tested a osram plug, but it does not respond to changes on groups state object. It works for my bulbs.

How must the raw zigbee request look like to, for example, read the group id from a device? {"cid": "genGroups", "cmd": "view", "cmdType": "functional", ??? groupid ???}

[modmax]

@kirovilya Tested now with latest changes.

1.) It seems that OSRAM lamps are not supporting this, even if this are Zigbee standards. Perhaps they only support it with ZLL. Create a new group 1 and added a a lamp to the group 1. Then the states occur in the group_1 section. But no command works and no errors in logs. It's just a group with one device; perhaps a groups must consist of 2 devices or more? Who knows ...

2.) OSRAM plug is still not working with group requests.

3.) Creating a group leads now to an immediate creating of the group. That's fixed.

4.) When deleting the group (in my example 1), then it will be delete on the adapter settings page. BUT the group ist still in the iobroker objects (zigbee.0.group_1 object still exists). Also the "groups" of the lamp still contains the id 1 of the group.

5.) What I saw, was also that creating a group, changing name of a device or using the developer tab (now called Analyse) leads to a marker to the adapter to store changes. Even if all changes are done immediatly. Perhaps there is something missing to tell the adapter that everything is fine and nothing has to be save, cause it has already been saved.

Best regards Markus

[modmax]

@allofmex For reading values the request must always be "foundation". Functional is for writing values. If you choose foundation in your developer tab then you can choose the read attribute for your purposes.

[allofmex]

But cluster genGroups has only one foundation attribute NameSupport (0 or 1, indicates whether names are supported or not). There is nothing else to read... Functional has commands view and getMembership. Sounds like reading!? Similar for cluster genScenes

[arteck]

Hi guys.... had no time this weekend...i check this tonight..

[allofmex]

Ok, found the solution. Had to fix something in developer tabs routines. (inlcuded in next PR)

{"devId": x,
    "ep": y,
    "cid": "4", // genGroups
    "cmd": "1", // view
    "cmdType": "functional",
    "zclData": {
        "groupid": "2",
        "groupname": ""
    }}

I added device to group No 2 and tested view command with "groupid": 1-3:

notFound {"msg":{"status":139,"groupid":1,"groupname":""}}
success {"msg":{"status":0,"groupid":2,"groupname":""}}
notFound {"msg":{"status":139,"groupid":3,"groupname":""}}

Command = 0 //add, "groupid": 3 success {"msg":{"status":0,"groupid":3,"groupname":""}} If I write to a groups object, the device that was manually added/removed to/from group responds. Very simple.

Tested the same on a OSRAM plug, group add/remove works. The Hue motion sensor says unsupClusterCmd, so seems you where right, groups only on router (incl. plugs)

[kirovilya]

@allofmex I do not understand ... I do not correctly add the device to the group? Something needs to be corrected in the code for managing devices and groups?

[allofmex]

No, all fine. These were just tests to find out what device types support groups at all. Sorry, went a bit off-topic.

[arteck]

update works..nice but after restart the adapter i see in log new dev's.. why ???

here same problem

1. OSRAM plug is still not working with group requests.

the state in group dont work

group delete but not in devices

the map is ok but the link quality is strange coordinator -> gu10.farbe.kino is 1 in object is it 31

or coordinator -> stripe.kino is 1 in objects is it 65

[Apollon77]

So, installed, works well ... and synchronous on/off ... a dream :-)

[Apollon77]

I noted one thing. I enabled a lamp group by setting brightness. this also turns the device on. In the group the brightness value is updated, but state stays "false" ... same for other stuff ... so group is not in sync. is this by intent?

[kirovilya]

@arteck I added routers polling - now they will be polled every minute (so they won't fall asleep). This was necessary mainly for xiaomi plug - they behaved badly. Therefore, sometimes there is a re-pairing of routers at restart. I still have nothing to say about OSRAM - I do not know what is wrong with them. The map displays the numbers obtained during the request of the map, and in the states of the objects numbers when receiving a signal from the device. They may differ, but should not be so drastically. Try to rebuild the map or wait until some signal comes.

[kirovilya]

@Apollon77 Yes, this is a problem that devices do not communicate their attributes when managing them through groups. Here you either need to force to request them, or learn how to configure them to send a report.

[Apollon77]

K, but should go into documentation for groups

[kirovilya]

So, there were questions: 1) what will we do with OSRAM devices 2) reading device attributes when managing through groups

[modmax]

@kirovilya 1.) At the moment I would say, that it's under inspection, when OSRAM lamps in groups are not working. If OSRAM plugs are not working it's also an issue, but I think that's no real problem and can be solved individually without groups. Further investigations are needed for that.

2,) Reading of devices values could be done. For #157 i've implemented a simple mechanism to read the response for a read request, when no event is emitted from the lamp; included in PR #162. That could be used perhaps. But this has to be done for every device in the group. Also this should only be done if queuing is activated.

OffTopic: Also I woul be glad if someone could explain me, how to merge changes in the iobroker.zigbee repo back into my repository. Until now I create pull request from iobroker.zigbee to me repository; but I think that there may be a better way ... :-)

[modmax]

Also tested changes with latest release. Groups are now not in end devices and end device cannot be in a group. OK. But I think some routers should also not have a groups states; like the LUMI.ROUTER ... could be perhaps set via a "groups: false" property in the device section of the LUMI.router in devstates.js. Could also be used for OSRAM plugs ... :-)

[modmax]

@kirovilya I've experimented a litte bit. And I've investigated, that the groupId is a string??? You can see it in the groups state of a lamps: ["1"] I would expect, that the groupId is an integer value... but it's really a string. Right now the adding of an OSRAM device to a group fails with "NO ACK"; but if i use an integer for the group id, then adding such devices to a group works. But i've not manage to switch a group on or off; perhaps I missed something to change, so that the groupId is an integer in additional/removal/querying and in the group object itself.

Maybe that hue bulbs can also handle string values for the groups, but OSRAM definitly not. So the chance to handle OSRAM devices within groups may be to ensure, that the groupId is always an integer.

[kirovilya]

@modmax Is your last experiment with the band really not working with OSRAM? I thought that the parameters themselves are converted to the desired type when sending. If this is not the case, then here you can add a transformation to the whole and that's it. https://github.com/ioBroker/ioBroker.zigbee/blob/dev/lib/zigbeecontroller.js#L555

[kirovilya]

LUMI.ROUTER ... could be perhaps set via a "groups: false" property in the device section of the LUMI.router in devstates.js.

The correct way is to analyze the clusters of the device and looking at them to understand whether it supports groups or not :) But perhaps lumi.router is based on Samplelight firmware and it means it has the same clusters as a light bulb :))) So even if he has the possibility of groups, he still will not be able to process the on / off command.

[kirovilya]

Also I woul be glad if someone could explain me, how to merge changes in the iobroker.zigbee repo back into my repository. Until now I create pull request from iobroker.zigbee to me repository; but I think that there may be a better way ... :-)

https://help.github.com/articles/syncing-a-fork/

[Apollon77]

Re Offtopic syncing a fork: I'm more the rebase fan ;-) https://de.atlassian.com/git/articles/git-team-workflows-merge-or-rebase In fact comparable:

                git fetch upstream
                git rebase upstream/master
                git push

[arteck]

from here is also allright OK. but i tested the groups only on dev system.. osram problem is known.. acceptable to me.. I write it in the forum that makes OSRAM problems.. so no problem here

hmm..maybe we'll wait until the weekend.. with release

[kirovilya]

Yes, we will wait

[arteck]

double goups works also.. 3 bulbs 2 groups all 3 bulbs are in grp1 2 are in grp2 works..perfect..tested with hue

but here a example with 3 hue bulbs the state is not synch.. brightness also

[allofmex]

Am updating the developer tab to support groups too. Here one suggest: Shouldn't the groupList be more organized like deviceList since the usage of groups is very similar to a device? (only difference is publish to 0x0000000000000005 (=groupId) instead of 0x90fd9ffffeda1234 (deviceId))

Currently: Groups: {"4":"Bath","5":"test-light"}

Devices:

[ {
    "type": "device",
    "_id": "zigbee.0.90fd9ffffeda1234",
    "info": {      "ieeeAddr": "0x90fd9ffffeda1234"    },
    "groups": [      "5"    ],
    "groupNames": "test-light"
  },
  {
    "type": "device",
    "_id": "zigbee.0.7cb03eaa00b21234",
    "info": {      "ieeeAddr": "0x7cb03eaa00b21234"    },
    "groups": [      "3"    ],
    "groupNames": ""
  } ]

I suggest that adapters groups object should look more like this:

[ {
    "type": "group",
    "groupid":"4",
    "groupName:"Bath",
},
{
   "type": "group",
   "groupid":"5",
   "groupName:"test-light",
} ]

[modmax]

@kirovilya Tested around with OSRAM plugs and bulbs; but those devices are not working with groups ... :-( Even with changes that the groupId will be parsed as integer on every request, where a groupId is contained, changed nothing. Ther must be a solution ... somewhere ... but right now I don't find it. Perhaps if @allofmex has built in the groups in the developer tab ... bu that may take a while ...

So in my opinion the V0.9 may start at the weekend; with the restriction to OSRAM devices (and perhaps other devices also) are not working together with groups ... The groups, the developer tab, a more stable adapter are reasons enough for the next version ... and I think that arteck also has several enhancements to new devices if the dev branch has been merged to the master branch.

[kirovilya]

@modmax Can you chat with a user who has working groups with OSRAM? https://github.com/Koenkk/zigbee2mqtt/issues/764#issuecomment-456809689

[allofmex]

Regarding OSRAM bulbs:

I did some tests with developer tab. The bulbs seem to support groups because they accept the group commands, add/remove/view works as expected. But they don't respond if commands are send to group. It's working for my other bulbs (ikea, hue)

cid genGroups, expert mode cmd: getMembership zclData: {"groupcount": 10, "grouplist": "6,7,8"} {"msg":{"capacity":8,"groupcount":0,"grouplist":[]}}

add {"groupid": "7", "groupname": ""} success {"msg":{"status":0,"groupid":7}}

getMembership {"groupcount": 10, "grouplist": "6,7,8"} {"msg":{"capacity":7,"groupcount":1,"grouplist":[7]}} add "groupid": "7", "groupname": "" duplicateExists {"msg":{"status":138,"groupid":7}}

add {"groupid": 8, "groupname": ""} getMembership {"groupcount": 10, "grouplist": "6,7,8"} {"msg":{"capacity":6,"groupcount":2,"grouplist":[7,8]}}

removeAll {"msg":{"capacity":8,"groupcount":0,"grouplist":[]}}

Maybe an issue with addressing? https://github.com/noctarius/lightify-binary-protocol#zone-address (mentions "packet type of 0x02")

[modmax]

Perhaps my error: I think I have flashed the wrong firmware to my cc2530+cc2591 coordinator ... that was the one from ZStack master and not ZStack dev ... omg ... I will reflash the coordinator now with the version vom 27.12.2018, do pairing ... again .. and see what happens ....

[kirovilya]

@modmax I think nothing will change :)

[Michaelnorge]

How to get v.0.9.0 ?

[modmax]

@kirovilya You we're completly wrong ... :-) OSRAM bulbs (must still test plugs) are working with groups. 2 changes had to be done:

1.) parse the group id as integer; otherwise some OSRAM devices didn't recognize it correctly and answer with a "NO ACK". That's solved with PR #166.

2.) The big part is: The coordinator must be flashed with the latest DEV-version of the ZStack firmware from Koenkk: https://github.com/Koenkk/Z-Stack-firmware/tree/dev

And it's really time wasting to flash the coordinator, cause this also means that you have to pair each device again. Also now you cannot delete router devices from the coordinator, cause they will be readded immediatly due changes according to the xiaomi plug; so I had to reset the bulbs and plugs manually via an ioBroker skript and a Sonoff S20. So if someone want's to use groups with OSRAM lamps, then there seems to be no other way right now.