[bug] Scene notification not published to MQTT

[bdbogjoe]

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0
zwavejs version: 6.1.0

Describe the bug

Using Node 54 (Fibargroup | Dimmer 2 | FGD212) the scene is not published anymore to MQTT, was working fine in 1.0.0, but using current version or even 1.0.1 it does not work anymore

here the logs when working fine :
1.0.0.zip

zwave2mqtt | 2021-02-05 18:43:52.541 DEBUG MQTT: Publishing to zwave/maison/escalier/lumiere-rampe/43/0/sceneId: 14 with options { qos: 1, retain: false }
zwave2mqtt | 2021-02-05 18:43:52.542 INFO ZWAVE: Node 54: value notification: 43-0-sceneId 14
zwave2mqtt | 2021-02-05 18:43:52.545 DEBUG MQTT: Publishing to zwave/maison/escalier/lumiere-rampe/43/0/dimmingDuration: Duration { unit: 'seconds', _value: 0, [value]: [Getter/Setter] } with options { qos: 1, retain: true }
zwave2mqtt | 2021-02-05 18:43:52.547 INFO ZWAVE: Node 54: value updated: 43-0-dimmingDuration undefined => [Duration: 0seconds]
zwave2mqtt | 2021-02-05 18:43:52.554 DEBUG MQTT: Publishing to zwave/maison/escalier/lumiere-rampe/43/0/sceneId: undefined with options { qos: 1, retain: true }
zwave2mqtt | 2021-02-05 18:43:52.555 INFO ZWAVE: Node 54: value updated: 43-0-sceneId undefined => undefined

and the logs when is does not work, i attached the logs for version 1.0.2
1.0.2.zip

2021-02-05 16:44:41.680 INFO ZWAVE: Node 54: value notification: 43-0-sceneId 14
2021-02-05 16:44:41.691 DEBUG MQTT: Publishing to zwave/maison/escalier/lumiere-rampe/43/0/dimmingDuration: Duration { unit: 'seconds', _value: 0, [value]: [Getter/Setter] } with options { qos: 1, retain: true }
2021-02-05 16:44:41.686 INFO ZWAVE: Node 54: value added: 43-0-dimmingDuration => [Duration: 0seconds]
2021-02-05 16:44:41.688 INFO ZWAVE: Node 54: value added 54-43-0-dimmingDuration => [Duration: 0seconds]

[robertsLando]

@billiaz is this the same issue of the other one? Maybe something about stateless values?

[varet80]

I am interested to also see what driver sends... do we have a mixed log, or driver is not involved in this?

[bdbogjoe]

i attached all logs, open the zip

[mbrrg]

I have the same problem using Fibaro Dimmer 2. Scene activation event shows in the Zwave log, no MQTT message published.

[varet80]

I have not yet been able to reproduce it with fibaro. @mbrrg can you give more details?

[varet80]

@bdbogjoe i jave a dimmer2, how can i reproduce this? Is it notifying on physocal button press or other to reproduce this

[varet80]

@bdbogjoe @mbrrg @robertsLando I can confirm bug exists, with my dimmer 2 too.
I cannot test further as it is my Mail bedroom! and baby is there still.

If the logs do not contain "silly" level logs from driver, we need to have at least this to get also the payload output.
I suspect dimming duration, works in "mistirious ways" compared to other notifications, and we need to pinpoint the flow issue causing this.

All in all. I noticed only one notification topic pushed, at end of dimming, without value.

[varet80]

I have checked the logs of @bdbogjoe I see no issues on 1.0.0
I see a bit different behaviour between 1.0.0 and my 1.0.4

On 1.0.0 I see scene MQTT changes from undefined to object { 'value':0, 'unit': 'seconds'} back to undefinied.

on 1.0.4 (my device) I see MQTT receive the same message whenever I press and hold the button. It does not retain it, which is the right thing to do.

As the scene part is a configuration setting. can be

1. a retained topic without Value is not stored
2. Works really nicely with just posting the message/event when happens and no second message afterwards

for point 2, example on my mqtt history:

So my previous post is not really valid.

[mbrrg]

2021-02-07 21:54:47.811 INFO ZWAVE: Node 46: value notification: 43-0-sceneId 26
2021-02-07 21:54:47.817 INFO ZWAVE: Node 46: value updated: 43-0-dimmingDuration [Duration: 0seconds] => [Duration: 0seconds]
21:54:47.831 CNTRLR « [Node 046] TODO: no handler for application command
2021-02-07 21:54:48.795 INFO ZWAVE: Node 46: value updated: 38-2-currentValue 0 => 99

There is no longer any message posted to xxx/yyy/zzz/43/0/sceneId, only to xxx/yyy/zzz/43/0/dimmingDuration.

[varet80]

@mbrrg I will check it soon too! as this is strange

[bdbogjoe]

let me know if you need anything else, i'm available for testing any fix, thanks

[user34756361233]

I think I have the same problem.
I have a number of FDG211 and FDG212 and have recently migrated to zwavejs2mqtt.

I see in the zwave log "[Node15] TODO ....."

10:14:32.662 CNTRLR » [Node 015] querying parameter #16 value...
10:14:33.978 CNTRLR « [Node 015] parameter #16 has value: 1
10:14:33.979 CNTRLR » [Node 015] querying parameter #17 value...
10:14:34.112 CNTRLR « [Node 015] TODO: no handler for application command
10:14:35.488 CNTRLR « [Node 015] TODO: no handler for application command
10:14:35.638 CNTRLR « [Node 015] parameter #17 has value: 0
10:14:35.639 CNTRLR » [Node 015] querying parameter #18 value...

When I press the button that is connected to the second input, but nothing more.
Previously this would trigger a scene but with Zwavejs2mqtt I do not have anything in MQTT to trigger the scene. I guess the same behaviour as decribed above.
node_15.txt

[bdbogjoe]

i just tested with latest (1.2.2), we have still same issue

for info using FGS223 (double switch) scene is published, but not with FGD212 (dimmer)

[robertsLando]

@AlCalzone any clue what could be wrong here? Seems like the valueId isn't created for that, but it was on old version, maybe a regression?

[AlCalzone]

I need to see a zwave-js log of a re-interview of the affected devices.

[robertsLando]

@bdbogjoe Could you provide it?

[user34756361233]

This is a zwave-js log of a re-interview of Node 15 which in my case is a FDG211. Hope I cathed what you wanted. I put it in "silly" mode. Devices 13,14,20,21 and 22 are dead nodes that have to be replaced.
zwavejs_1.log

[AlCalzone]

12:37:43.327 CNTRLR « [Node 015] node info received
                      supported CCs:
                      · Manufacturer Specific
                      · Version
                      · Configuration
                      · Association
                      · Multi Channel Association
                      · Multilevel Switch
                      · Firmware Update Meta Data
                      · All Switch
                      · Powerlevel
                      controlled CCs:
                      · Multilevel Switch
                      · Scene Activation

Scene Activation CC is not listed as supported, so we don't automatically create values for it.
So our only option is to react dynamically once the scene is triggered once.

[user34756361233]

So our only option is to react dynamically once the scene is triggered once.

Is this something I have to do?

[bdbogjoe]

strange why was ok with 1.0.0 ? do you need anything else from my side ?

[AlCalzone]

Could be due to zwave-js/node-zwave-js#1207 maybe.
I don't know which zjs2m version includes that.

In most cases this behavior was not correct and displayed unsupported values.
For your device, you could probably force the creation of the value by marking Scene Activation as supported: https://zwave-js.github.io/node-zwave-js/#/development/config-files?id=commandclassesadd

[bdbogjoe]

hum don't know how to do this, how to get the command hex code ? where to put this file ?

[AlCalzone]

I can do it, which firmware version does your device have?

[bdbogjoe]

node_54.json.txt

as i can see from UI firmware is 3.5

[user34756361233]

Could be due to zwave-js/node-zwave-js#1207 maybe.

I use on/off switches also as dimmers, there is a difference between the physical world and how the inputs are being used. Usecase, a FGS212 (on/off) is used to dim a light attached to a FGD211 ...

[robertsLando]

The scene is now well published to MQTT, but it goes back to undefined just after, is it normal ?

If it is stateless (as I think) set it to undefined is made innternally by z2m to clear the state so you can detect the change

[AlCalzone]

Maybe the value should not be writable

That's a current limitation => zwave-js/node-zwave-js#528

[user34756361233]

So if I understand correctly, this update will correct problems for FDG212.
Does this have an effect on the FDG211 as well, or is it necessary to go down the "commandclassadd" way?

tia

[AlCalzone]

If the problem with FGD211 was that it also just controls the CC, the PR should affect that device too.

[user34756361233]

I just checked. I can see the same as @bdbogjoe on my FGD212, but nothing on my FGD211; not in UI or in zwave log.

Because the majority of my switches is the FGD211 and I am using the scenes a lot its back to OZW for the moment I guess

[AlCalzone]

Did you reinterview the affected device?

[user34756361233]

Did you reinterview the affected device?

yes, a couple of times. I will now first start another instance as a test enviroment with said FDG211 and a spare controller. Just not to lose out on WAF ;-)

[AlCalzone]

And you are sure you're running the master branch of zwave-js? @bdbogjoe also had some problems earlier but got it to work.

[user34756361233]

BTW thanks for all the help sofar. I think.. I am running the right version, started a new container this afternoon.

I am not an expert on this ;-)

[AlCalzone]

@robertsLando?

[user34756361233]

I started a new container with another controller and added the FDG211 with the same result as before. I re-interviewed the node (logging in attachment)
zwavejs_1.log

[bdbogjoe]

unfortunately i don't have FDG211 to try myself

As it is the latest version of zwavejs2mqtt does not include this fix, we need to do custom build using master branch of node-zwave-js

[user34756361233]

I will start a new bug report for my FDG211

[robertsLando]

Try to update to latest 1.3.0 version

[user34756361233]

I have updated to the latest docker version (1.3.0 in dashboard, don't know if this is the latest in your view), I see scene information in debug, but no scene information in MQTT. Is there any logging I can provide?

[robertsLando]

I see scene information in debug

Please upload log files as described in bug issue template

[user34756361233]

@robertsLando, please find logfiles attached.
Actions performed:

1. re-interview of node 2 (FGD211)
2. single click of second switch (the one not carrying load)
3. double click of second switch
4. triple click of second switch

thanks in advance!
zwavejs_1.log
zwavejs2mqtt.log

[AlCalzone]

The values get received and published as events. But I'm not sure if zwavejs2mqtt sees the value ID, because

11:14:06.437 DRIVER   version 6.4.0

[user34756361233]

@AlCalzone because version 6.4.0 is not the right version?

[AlCalzone]

6.4.0 was released before the fix. I'm not sure if the docker image 1.3.0 was built with the master branch after the fix was merged 🤷🏻‍♂️

[user34756361233]

Ok no big problem, I just have to wait till it pops up then I guess. When I see driver 6.5.0 then its included?

[AlCalzone]

yep

[user34756361233]

@AlCalzone, just respun my docker container. My driver version is now 6.5.0.
I now see the scene information in MQTT and I am able to catch it in HA.
As soon as the message with the scene information arrives, its overwritten by a new message. I don't if this behaviour is intended. Was also mentioned by @bdbogjoe.

zwavejs2mqtt.log
zwavejs_1.log

[AlCalzone]

The entire MQTT part is handled by zwavejs2mqtt, so you'll have to talk this through with @robertsLando.

Essentially this value is stateless, so it is not meant to be retained. zwavejs2mqtt resets it to undefined after a second.

[user34756361233]

Essentially this value is stateless, so it is not meant to be retained. zwavejs2mqtt resets it to undefined after a second.

I can work with that I think. Thx!

[robertsLando]

I now see the scene information in MQTT and I am able to catch it in HA.

I think this can be closed so