Zwave2mqtt: [question] Reg. Logic-soft Matrix ZDB5100

[LordMike]

Version 3.0.3

Build/Run method

• [x] Docker

Zwave2Mqtt version: 3.0.3
Openzwave Version: 1.6.1080

Questions
I've just acquired a Logic-soft Matrix ZDB5100, and z2m has discovered a total of 17 devices for it:

• 6 dimmers (type=light), I expected 1 (the device has only one output)
• 6 switches (type=light), I expected 4 buttons?.. Maybe one more for an on/off for the devices output
• 5 scene states (type=sensor)

I've got a few questions.

1. Z2M reports to HASS, that light_rgb_dimmer_6's (the device I've found to be the dimming output of the unit), is having a brightness going from 0..255 (I've seen this in the value reported over MQTT), when it actually goes from 0..100. Is this an OZW config issue?

2. The Matrix has 4 physical buttons with an RGB LED behind it. I've been able to control LED no. 1 using Z2M (a User-value for RGB color), but I can't control LEDs 2..4. Z2M also only seems to discover one parameter named Instance 1: Color (20-51-1-0), but non named f.ex. Instance 2: Color (...).

   • I've not been able to find the Instance 1: Color in the OZW config, so perhaps the product is reporting this and Z2M is missing it?

   • What decides which values are User/Configuration/System values?

3. HASS has an RGB selector that disappears when the light is turned off.. Do you think its possible to report to HASS that the RGB can be controlled despite the light being off ? (as they're in fact two different lights ..)

4. The SW Version is reported to HASS as "Unknown", but Z2M shows it as 1.01.

Mike.

[LordMike]

Also. The product is detected as having 6 dimmers.. where I'd expect 1, as only one output exists on it.. (it can only control one light).. I think the remaining can be used in tandem with other similar products.. so that one product controls the light (the master), and others merely send the master "basic set" commands..

Maybe the slaves need the concept of a dimmer for this to work.

[robertsLando]

Z2M reports to HASS, that light_rgb_dimmer_6's (the device I've found to be the dimming output of the unit), is having a brightness going from 0..255 (I've seen this in the value reported over MQTT), when it actually goes from 0..100. Is this an OZW config issue?

Check the hass configuration and fix the value template if needed, unfortunally not every device works in the same way

The Matrix has 4 physical buttons with an RGB LED behind it. I've been able to control LED no. 1 using Z2M (a User-value for RGB color), but I can't control LEDs 2..4. Z2M also only seems to discover one parameter named Instance 1: Color (20-51-1-0), but non named f.ex. Instance 2: Color (...).

This question is too generic, you should provide the valueid of each one and show a debug log when you try to set a value

I've not been able to find the Instance 1: Color in the OZW config, so perhaps the product is reporting this and Z2M is missing it?

Could be a configuration issue in XML file. Try to open this issue on OZW repo and check

What decides which values are User/Configuration/System values?

It's a parameter of the value, it comes from OZW https://github.com/OpenZWave/node-openzwave-shared/blob/master/src/utils.cc#L336

HASS has an RGB selector that disappears when the light is turned off.. Do you think its possible to report to HASS that the RGB can be controlled despite the light being off ? (as they're in fact two different lights ..)

I'm not an HASS user, can't help with this but I would be happy to help you with a PR for that if you find a way

The SW Version is reported to HASS as "Unknown", but Z2M shows it as 1.01.

That's coming from: https://github.com/OpenZWave/Zwave2Mqtt/blob/master/lib/Gateway.js#L437

The node version comes from command class 0x86 https://github.com/OpenZWave/Zwave2Mqtt/blob/master/lib/ZwaveClient.js#L418

Maybe the version you told me comes from another command class, it could be another version (hardware version?)

[LordMike]

The version is actually class 0x86..

.. so that's odd.

[LordMike]

Brightness control 0..100

I've played a bit with the brightness / states / RGB and so on..

I've found that HASS has a brightness_scale property, which defines that brightness max value. It defaults to 255. If you set this to 100, then HASS properly scales between 0..100. Doing that could actually remove the workaround (?) Z2M makes, which is: "brightness_value_template": "{{ (value_json.value / 99 * 255) | round(0) }}",.

Edit: This actually needs to be 0..99

[LordMike]

States, ON, OFF etc.

I've also found that Z2M defines the state and brightness topics as the same. So what HASS will do, is send both "ON", "OFF" and numerical values (0..100) to Z2M. I think this confuses the wall switch. I bypassed the state topic by temporarily placing it elsewhere, and then HASS started "working properly".

I've found that if I set zwave2mqtt/switch_2/38/6/0/set (brightness topic for my dimmer) to:

• 0..100 - the light goes from 0..100% brightess
• OFF - the light turns off
• ON - the light does NOT turn on; but it will turn the light OFF if it was on.

UPDATE: Just discovered on_command_type and brightness in that.. Will test.

So that worked. I can now turn on the light, HASS doesn't send "ON", but rather "99".

[LordMike]

Thanks for the tips btw.. :)

[LordMike]

I refreshed the node, and copied out the section of the OZW_Log that relates to this device (it's long .. 2100 lines)..

Regarding version, I see that the device apparently reports 3 instances of COMMAND_CLASS_VERSION .... nvm.. that's expected I see..

OZW_Log.txt

[LordMike]

I kicked off Zensys Tools and checked out my wall switch. It correctly detects 5 endpoints, where 4 of them are switches and the last is the output from the product. The 4 switches all have a 0x33 - SWITCH COLOR command class (51) .. so something must be off with OZW as it only detects one of them? ..

I can't figure out how to invoke the Color Set though.. could be cool to test if it actually worked and set colors.

[LordMike]

I've made an issue with OZW

[robertsLando]

I will check this out on Monday Mike! About the version, as you see that one is using 134 that is application version

_{Sent with GitHawk}

[robertsLando]

By double checking the code I saw that I only check the command class for version, I should also check the index (0=lib version, 1=protocol version, 2=application version)

I've found that HASS has a brightness_scale property

I saw that but I had some hass users having problems when using that property. Does it works for you? If so I will wubmit a fix as you suggested (or ifo you want to make a PR this is the code to edit: https://github.com/OpenZWave/Zwave2Mqtt/blob/master/hass/configurations.js#L156-L185

I can't figure out how to invoke the Color Set though.. could be cool to test if it actually worked and set colors.

Unfortunally I'm not an hass users and I haven't so much zwave devices to play around so I can't tests all them, also hass mqtt autodiscovery doesn't support all kind of devices, about the color I have made just a support for rgb lights, I don't know if hass has an mqtt device that only accepts color inputs. Do you know?

[LordMike]

Reg. brightness_scale. The value template converts from 0..255 to 0..99, right? In that case, changing the scale will let HASS do that conversion.

Reg. RGB. I managed to change the lights on the other switches, using a different controller.. Only, I reverted back to OZW before I turned them off, so now they're permanently set .. :D

HASS does not have an RGB-only thing, but light is the proper class for this.

For my specific product, I think I'll split the brightness control and the RGB control into separate devices. They are two different things, with two different states, and shouldn't be mixed. Z2M does nothing wrong here, as it _normally_ will be both the light and the color of the light, that is controlled in one go. When I figure out how to control the intensity of the RGB lights, then it'll be worse, as now "brightness" can mean both RGB light and the output of the dimmer... :P

I also checked with HASS, and they had a long discussion on being able to set RGB colors independently of brightness, but came to the conclusion that one mustn't.

[LordMike]

Is there an issue I could read on previous brightness_scale attempts?

[LordMike]

Sidequestion: Would it be possible to display devices with their multiple endpoints, like Zensys does it?

I find it really convenient to know that that there are 5 endpoints, 4 of them named the same, etc.. I don't know if all the details are there, in the Z-wave data, or if Zensys has a magic matchup elsewhere..

[robertsLando]

@LordMike With endpoints you mean groups? If so you will be able to see them in groups tabs. COuld you show me what Zensys does with endpoints?

The value template converts from 0..255 to 0..99, right? In that case, changing the scale will let HASS do that conversion.

In theory, yes. But hass is strange sometimes (I know that there were also problems when sending 100/255 as values)

I cannot find the issue, it could have been a conversation in slack channel too, I only remember that a user was helping me with that and maybe could tell you more about this: @jshridha.

Anyway, the edit to make the test is really simple (just check the link to the code I sent you and edit it there), if it works let me know and I will add it to next release asap :)

[LordMike]

Groups would be having one ZW device communicate "directly" with another, right? That's not it.

In my Zensys screenshot, the "endpoints" (I still don't know if this is the name for it), are shown up top. The node, 20, is split into 5 sub-thingies, where each of the 5 (20.1 through 20.5) have a set of command classes associated to just them.

With my device (the wall switch), there are _so many_ classes and values, that identifying which values belong to which of the 5 endpoints becomes a pain.

I can grab a few more screenshots from Zensys in an hour or so. I have to disconnect the Z-wave stick from my HASS server when I do :P

EDIT: I googled and came to this doc. Silabs refers to "Multichannel endpoints" as what I think I'm seeing in Zensys.

Within a network, a Z-Wave node is identified by its NodeID. The NodeID essentially represents the plastic box and the radio. Multi-resource devices are organized as Multi Channel Endpoints. Each application resource is identified by its own unique End Point. The plastic box itself is referred to as the Root Device.

There are some further examples and explanations in the document.

EDIT 2: I see now that "Groups" has a reference to "Multi instance".. I think the following is true:

• Z2M's "Groups" might be a misnomer of Z-Waves "associations"
• Z2M's "instance" might be Z-waves "endpoint"

[robertsLando]

EDIT 2: I see now that "Groups" has a reference to "Multi instance".. I think the following is true:
Z2M's "Groups" might be a misnomer of Z-Waves "associations"
Z2M's "instance" might be Z-waves "endpoint"

Yes that's it :)

[robertsLando]

@LordMike Could we close this in favor of the new feat request?

[LordMike]

Outstanding stuff not related to #417:

• Should brightness_scale be 99 by default?
• Should on_command_type be brightness by default? -- I don't think so, is overriding by stored discovery doc the way to go?
• Why did Z2M identify 6 dimmers? -- I'll check up on this.

[jshridha]

@robertsLando I think you're talking about pull request #135. The reason for sending 255 by default for an "on" operation is that all of the Jasco, GE, and zooz dimmers (and probably others also) will return to their previous brightness if they receive 255 command. If they receive anything from 0-99, they will go to that specified brightness %.

@LordMike I believe I tested setting the max scale in home assistant, but that prevented home assistant to be able to send 255 for an "on" command. That is why you have the weird looking work around that does the 0-99 scaling within the value template.

[LordMike]

Aha!.. That makes sense then. I've found that for the ZDB5100, if I send .. I think .. a COMMAND_CLASS_SWITCH_BINARY with ON, it goes to its previous brightness.. so perhaps it's a matter of instructing HASS to send to different CC's?

In any case, devices will be different in the end.. Am I meant to resolve it on my end by configuring the discovery document for the devices that differ?

[robertsLando]

@LordMike I let @jshridha Answer for you as I don't own this devices and I'm not able to make tests

[jshridha]

@LordMike that's probably the easiest way to go. You may just need to make a custom mqtt device in home assistant since I'm not sure that zwave2mqtt has build in the ability for hass devices created from one command class to send instructions to a different command class.

[robertsLando]

I'm not sure that zwave2mqtt has build in the ability for hass devices created from one command class to send instructions to a different command class.

It depends on the configuration used in the command topic, if the command topic should use a different valueid just need to use that valueid in the configuration

[LordMike]

That would be the thinking, yes, have it communicate with a different topic.

TBF, I'll probably end up making the entities myself, in HASS, as they'll probably be unmaintainable in Z2M.

[robertsLando]

TBF, I'll probably end up making the entities myself, in HASS, as they'll probably be unmaintainable in Z2M.

@LordMike That is my suggestion at all, for simple things everything should work but unfortunally mqtt autodiscovery is not so friendly and also doesn't support all features (and also could easily break things after hass updates like it has happen with locks) so that would be the best way to integrate your devices for sure.

This could be a useful tutorial for this: https://selfhostedhome.com/migrating-to-zwave2mqtt-for-home-assistant/

[LordMike]

In that case, I don't think there's any remainder in this issue.

The current defaults have their merit, so I'll let this be a discovery of available options :).. Unfotunately, I can hardly point at any HASS docs for discovery, as that documentation is non-existent or scattered in many places :/.

[jshridha]

@LordMike Yes, the hass docs for discovery can be tedious / difficult to go through. I just went through it for a different project. But for your use case, you may just want to try out specifying the mqtt yaml and skipping the auto-discovery phase.

[robertsLando]

I have followed this docs and I don't know if there are others: https://www.home-assistant.io/docs/mqtt/discovery/

[LordMike]

@robertsLando is there a way to prevent Z2M from pushing discovery documents for specific nodes?

[robertsLando]

@LordMike for this nodes, set an empty discovery payload on each entity

[LordMike]

Slightly cumbersome. But ok. They won't be recreated at any point?

[robertsLando]

I havent’t found a friendly way for this yet, do you have any suggestions? Anyway with an empty payload the discovey will fail so there will be no entities on hass, but mqtt values will still be availables. What I could do is to add a field to nodes to disable discovery on some of them, or would you prefer to select single entities to esclude for each node?

---

Daniel - Software Engineer

Support me at:
Github sponsors

On 11 May 2020, at 15:45, Michael Bisbjerg [e-mail] wrote:


Slightly cumbersome. But ok. They won't be recreated at any point?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[LordMike]

Ooh.. I kinda hoped to use the same topics to publish entities myself. I found the HASS config to be a pain, especially as I'll have to make ~6-8 entities per device, so I made a templating program that pushes to topics in MQTT.

I'll just have to name something differently.

One way is a property next to the discovery_payload, f.ex. discovery: false. (It'll default to true).

For convenience, add a button next to "Rediscover node" that says "disable all discovery".. What it should do, is set this boolean on all devices. Then I can pick and choose, if need be, and quickly disable all discovery, if need be.

When publishing discovery stuff, check this boolean.

[robertsLando]

One way is a property next to the discovery_payload, f.ex. discovery: false. (It'll default to true).

That could be done yes

[robertsLando]

@LordMike Just submitted a PR based on this. CHeck it out :)

[LordMike]

Cool. Is there a docker image with this in it ?

From the code, I gather this is per node - which is awesome :)

Minor thing. Configurable ignoreDiscovery default, for new nodes?...

[robertsLando]

Configurable ignoreDiscovery default, for new nodes

This would break existing instances. I should create an option on gateway settings Manual discovery that if is true will set ignoreDIscovery to true by default in all nodes

[LordMike]

You need, like, a tri-bool.. :P

Keep the current code that sets ignoreDescovery to false, if it wasn't truthy (to add the property to existing docs).. But add some code in the method that creates new nodes, where you copy in the specified default value - since the default isn't checked with existing nodes, only new ones, it shouldn't affect existing setups.

[robertsLando]

But add some code in the method that creates new nodes, where you copy in the specified default value

This is what manual discovery would be for in my original idea

[LordMike]

Hmm. You could also do migrations :)

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label

[LordMike]

@robertsLando I have no need for this issue to stay open, so you can close it if you want :).

I've ended up taking complete control of the entities. I let Z2M send to a different discovery topic prefix, and then I copy those I need over to the actual discovery topic prefix.

[robertsLando]

@LordMike Ok perfect, thanks :)