Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZMNHDA Qubino Flush Dimmer multilevel switch current value not propagating from zwavejs to zwavejs2mqtt #2910

Closed
1 task done
NINE78 opened this issue Feb 10, 2021 · 59 comments · Fixed by #3555
Closed
1 task done
Assignees

Comments

@NINE78
Copy link

NINE78 commented Feb 10, 2021

Version

Build/Run method

  • Docker -> running a Home Assistant supervised add-on

zwavejs2mqtt version: 1.1.0
zwavejs version: 6.1.3

Describe the bug

For my Qubino (GOAP) ZMNHDA dimmers, I see multilevel switch ("current value") updates sent to Endpoints 0 and 1, but only Endpoint 1 is received in zwavejs2mqtt, this when manually toggling the light switch.

From zwavejs log:

15:34:46.396 SERIAL « 0x0109000400400326030094                                            (11 bytes)
15:34:46.398 CNTRLR   [Node 064] [~] [Multilevel Switch] currentValue: 63 => 0          [Endpoint 0]
15:34:46.399 SERIAL » [ACK]                                                                   (0x06)
15:34:46.402 DRIVER « [Node 064] [REQ] [ApplicationCommand]
                      └─[MultilevelSwitchCCReport]
                          current value: 0
15:34:46.407 CNTRLR   [Node 064] [~] [Multilevel Switch] currentValue: 63 => 0          [Endpoint 1]
15:34:47.336 SERIAL « 0x0110000400400a320221340000023b0000bd                              (18 bytes)

However in zwavejs2mqtt log, only 38-1 value is updated, which does not get picked up by the "Current Value" entity in HA (there is only one for the light):
2021-02-10 15:34:46.411 INFO ZWAVE: Node 64: value updated: 38-1-currentValue 63 => 0

To Reproduce

Steps to reproduce the behavior:

  1. toggle lights
  2. observe only endpoint 1 coming through to zwavejs2mqtt in the logs

Expected behavior

Also expect 64-38-0-currentValue to be updated

Additional context

Logs attached
zwavejs2mqtt.log
zwavejs_578.log

@robertsLando
Copy link
Member

@AlCalzone ? I don't think I'm missing the value event

@robertsLando
Copy link
Member

@NINE78 I see also the endpoint 0 updates in your logs:

2021-02-10 15:27:58.047 INFO ZWAVE: Node 64: value added 64-38-0-currentValue => 0

@NINE78
Copy link
Author

NINE78 commented Feb 10, 2021

Value added for 64-38-0-currentValue, but it's never updated, whereas zwavejs is picking up changes on both endpoints... Do note timestamps on my paste above; don't think this should be closed. Thanks!

@robertsLando robertsLando reopened this Feb 10, 2021
@AlCalzone
Copy link
Member

I think that is a misunderstanding. The device reports to endpoint 0 (which duplicates endpoint 1 and thus is hidden). Because you still want to see the value, the report is mapped to endpoint 1 - and that report is passed on to zjs2mqtt.

@NINE78
Copy link
Author

NINE78 commented Feb 10, 2021

Ah ok, thanks @AlCalzone. So it appears Endpoint 1 isn’t propagated to Home Assistant. I notice only Endpoint 0 is added on interview, and Endpoint 1 Currrent Value when it is first transmitted (as observed in zwavejs2mqtt). Is this expected behavior? Trying to figure out why the device in HA isn’t reflecting state. Is there a way to force Endpoint 1 in the config upon interview?

@AlCalzone
Copy link
Member

@robertsLando from the log in the first comment it looks like the value reaches zjs2m, so the problem probably lies between there and HA, right?

@robertsLando
Copy link
Member

@NINE78 Are you using mqtt discovery or zwavejs server ?

@NINE78
Copy link
Author

NINE78 commented Feb 11, 2021

@robertsLando Zwavejs server to which HA integration connects over websocket.

So my current thinking is that:

  1. upon device interview 64-38-0-currentValue is added by zwavejs
  2. HA creates the device and a corresponding Current Value entity for endpoint 0
  3. Upon operation of the device, 64-38-1-currentValue is what to listen for, but no corresponding entity exists in HA

Does that make sense? From his comment above, @AlCalzone suggests that — due to duplication — endpoint 0 is hidden. Can we somehow force this not to? Or alternatively force xx-38-1-currentValue to be added during the interview process?

@AlCalzone
Copy link
Member

The latter is what I'd expect to happen. Can you re-interview the device and share a log of that? Can't debug this when the interview restarts from cache.

@NINE78
Copy link
Author

NINE78 commented Feb 11, 2021

Just performed a re-interview of the device, followed by a toggle off and on again (the light was on when re-interviewing).

From the log I observe, when toggling the light for the first time: Endpoint 0 is updated, and Endpoint 1 currentValue appears to be newly created:

19:06:01.549 CNTRLR   [Node 064] [~] [Multilevel Switch] currentValue: 63 => 0          [Endpoint 0]
19:06:01.562 SERIAL » [ACK]                                                                   (0x06)
19:06:01.567 DRIVER « [Node 064] [REQ] [ApplicationCommand]
                      └─[MultilevelSwitchCCReport]
                          current value: 0
19:06:01.571 CNTRLR   [Node 064] [+] [Multilevel Switch] targetValue: undefined         [Endpoint 1]
19:06:01.577 CNTRLR   [Node 064] [+] [Multilevel Switch] currentValue: 0                [Endpoint 1]

Thanks so much!

zwavejs_463.log
zwavejs2mqtt.log

@str2der
Copy link

str2der commented May 5, 2021

I have the same problem with all my Qubino Flush Dimmers. When the wall switch is toggled, the "dimmer level" turns on, but the switch in HA stays off. When I turn the "dimmer level" or the switch on in lovelace, the light turns on as it should.

However - the big problem is that when turning off the light with the "dimmer level" button in lovelace, the light turn off but after a second or so, the "dimmer level" button comes on again (with the light still off) creating a lot of issues with wrong status of lights. If the light is turned off with the switch in HA, it turns off as it should and the status of the light is off in lovelace.

@andyboeh
Copy link

Same for me on ZMNHDD dimmers. Is there anything that I can do to help in improving the situation?

@robertsLando
Copy link
Member

@AlCalzone Updates on this? I think it's something on your side

@AlCalzone
Copy link
Member

Essentially this is a mix of #2286 and automatically figuring out the correct associations. There's no one-fits-all solution, so I've been putting this off while thinking about an approach that requires as few device-specific overrides as possible.

@AlCalzone
Copy link
Member

This should be fixed with #2997 in the upcoming 8.x release. If not, feel free to reopen with new logs.

@bratanon
Copy link

bratanon commented Jul 25, 2021

Also seeing this issue with all ZMNHDD.

Have re-interviewed the devices but still the same issue when turning off the lights. Turning on works fine.

Currently using z-wave js addon in HA 0.1.32 which includes Z-Wave JS 8.0.5

@AlCalzone
Copy link
Member

Z-Wave JS 8.x includes some changes to endpoints/associations which might require compat flags for some devices. Please share a driver log of a re-interview, so I can use that to figure out which changes are necessary.

@bratanon
Copy link

bratanon commented Jul 26, 2021

Is "driver log" the same as I get from the Home Assistant addon for z-wave js?

Is there a way to filter the logs for a specific node? I have a lot of nodes reporting all the time which clutter the logs.

With which serviery do you what the log? Debug? Info?

@AlCalzone
Copy link
Member

AlCalzone commented Jul 26, 2021

Its this one - loglevel "debug" please:
https://zwave-js.github.io/zwavejs2mqtt/#/troubleshooting/bug_report?id=driver-logs

Is there a way to filter the logs for a specific node?

zwavejs2mqtt should let you do that. If not, it's also okay.

@bratanon
Copy link

node014.log

Hope this helps.

@bratanon
Copy link

Not sure if this also helps, but it seems like if i start with what I think is brightness level 50 and turn off the light, its correctly reflected in the UI. However, If i start with brightness level 30, its not working. it will still be turned on in the UI.
node014_turn_off_30.log
node014_turn_off_50.log

@fbietlot
Copy link

At first I missed the exclusion and reinclusion part. Then I was even not able to see the Binary Swicth
But after correct exlusion and red reinclusion, the binary switch is now there.... but not working.
I will try to get you the log
PS: Thank you

@fbietlot
Copy link

OK I did a re-interview and here are the log and node.json
zwavejs_2021-10-15.log
nodes_dump.json (2).txt

As far as I understand in the log the endpoint for the switch was found ..
But...
2021-10-15T15:17:32.620Z CNTRLR [Node 010] Endpoints seem unnecessary b/c they have different device classes,
ignoring all...

@AlCalzone
Copy link
Member

Ok we can work around that with a compat flag. Will add it later.

@AlCalzone AlCalzone reopened this Oct 15, 2021
@fbietlot
Copy link

@AlCalzone so I maybe find something that can be fixed ?
😁😁😁 if yes, so glad ;-) My first participation to an issue on github ;-)

@fbietlot
Copy link

Hello again,
Thanks to your comment, I've try to understand compat flag logic for preserveEndpoints.
My intention was to change the config file to add the compat flag.
I've created a custom config file in ZwaveJStoMQTT in store/config
image

check config
image

I have Save -restart (even reboot) - reinterviewed.
But my custom config file doesn't seems to be taken into account
2021-10-18T11:32:00.844Z DRIVER « [Node 010] [REQ] [ApplicationCommand] └─[ManufacturerSpecificCCReport] manufacturer id: 0x0159 product type: 0x07 product id: 0x52
2021-10-18T11:32:02.981Z CNTRLR [Node 010] Embedded device config loaded

zwavejs2mqtt: 5.8.0
zwave-js: 8.4.1
Core
Version
core-2021.10.4
Supervisor
Version
supervisor-2021.10.0

@robertsLando did I miss something to activate custom config file ?
zwavejs_2021-10-18.log

@robertsLando
Copy link
Member

robertsLando commented Oct 18, 2021

Seems you have followed all the steps described in: https://zwave-js.github.io/zwavejs2mqtt/#/device-support/custom-device-files

Just found the error in logs:

2021-10-18T11:04:38.140Z CONFIG   Error parsing config file zmnhtd.json: The device config file is malformed!
                                  packages/config/config/devices/zmnhtd.json:
                                  paramInformation is not an object

@fbietlot
Copy link

indeed I didn't notice this message :-(
This is actually strange because I've just copy/paste the config file "packages/config/config/devices/0x0159/zmnhtd.json" and add the compat flag.
I made another test without the compat flag (so just exact copy of the file on github)
Same error : -(

2021-10-18T12:34:05.937Z CONFIG Error parsing config file zmnhtd.json: The device config file is malformed! packages/config/config/devices/zmnhtd.json: paramInformation is not an object

Reading the documentation : https://zwave-js.github.io/zwavejs2mqtt/#/device-support/custom-device-files

paramInformation An array of the configuration parameters the device supports. See below for details.

From my undersatnding : paramInformation is not an object but an array (so I'm not sure the error message is accurate)

@AlCalzone
Copy link
Member

The problem is that we recently switched the config file format. You copied a new file which is not yet understood by the driver version installed on your system.
If @robertsLando pushes a new update of zwavejs2mqtt, you should be able to use that to load the new file.

@robertsLando
Copy link
Member

@AlCalzone If beta 2 supports it he can use master tag on docker and it will work

@AlCalzone
Copy link
Member

yeah beta supports it

@robertsLando
Copy link
Member

@fbietlot So just use master tag if you are using docker

@fbietlot
Copy link

Sorry but I know a little bit what docker is but no clue how to interact with it and how to use "master" :-( (Still a lot to learn...)
More easy for me, I picked the old version of the config file (with object instead of array) and change the compat flag.
and good news !!
The binary switch is now linked to endpoint 2
image

So I'm progressing.
Unfortunatly I'm not home so I can not check if the relay is correctly working. Will check later and keep you posted.

In the meanwhile, I received this answer from Qubino.
I must read it with more attention later because it's not self speaking to me :-(

<

Hello Francois,

Thank you for the links, going trough that and your emails again I notice something that was not make the things fit as it have to be.

The command class that you use 37 is not a part of the command classes that are used in the Smart Meter you can see al the Command Classes that our Smart Meter support in the extended user manual that you can find on this page ( Qubino Smart Meter ) check the pages 48 and 49, because of that is not possible that you will get any reply from there. The command class 37 refers to COMMAND_CLASS_HRV_STATUS 0x37, if you need to know the status of the IKA you must use the switch binary command class COMMAND_CLASS_SWITCH_BINARY 0x25
a command 25 02 sent to the Smart Meter it will trigger the meter to reply on the status. The Command have to be sent to the endpoint 2 as the IKA endpoint is that one.

As you may see in the video the reports are sent to the COMMAND_CLASS_SWITCH_BINARY 0x25 under the command 03 which is the SWITCH_BINARY_REPORT. You can see in the video and in the gif that the reports are sent and you can also hear the IKA trigger when the command On or Off is sent.

In the second gif I send the COMMAND_CLASS_HRV_STATUS 0x37 and as you may see there's no response.

Best regards,
Igor, Technical support

PCc_Check1PhIkaCC37No
PCc_Check1PhIkaReports

PcCont1PHIkaTest_14097.mp4

@AlCalzone
Copy link
Member

AlCalzone commented Oct 18, 2021

Regarding Qubino's response

The command class that you use 37 [...] The command class 37 refers to COMMAND_CLASS_HRV_STATUS 0x37

They are confusing decimal 37 (hexadecimal 0x25) with hexadecimal 0x37 (decimal 55).
37 = 0x25 = SWITCH_BINARY

@robertsLando
Copy link
Member

Sorry but I know a little bit what docker is but no clue how to interact with it and how to use "master" :-( (Still a lot to learn...)

What build method are yopu using? If docker instead of using latest tag use master

@fbietlot
Copy link

Sorry but I know a little bit what docker is but no clue how to interact with it and how to use "master" :-( (Still a lot to learn...)

What build method are yopu using? If docker instead of using latest tag use master

I'm just clicking on install in Home Assistant Supervised 😳 😕

@robertsLando
Copy link
Member

Oh ok so you are using hass addon, @blhoward2 how can he use docker images with hass os?

@blhoward2
Copy link
Collaborator

blhoward2 commented Oct 18, 2021

The only way to use a built docker image is by installing the Portainer addon, or you may be able to install the ssh addon and manually run docker (I'm not sure on that one). Otherwise he's limited to the zwavejs addon or the zwavejs2mqtt addon.

https://community.home-assistant.io/t/home-assistant-community-add-on-portainer/68836

@QubinoHelp
Copy link
Contributor

They are confusing decimal 37 (hexadecimal 0x25) with hexadecimal 0x37 (decimal 55).
37 = 0x25 = SWITCH_BINARY

Hi to all, yes I did assume that the command you're sending was in RAW so in hexadecimal, that's why the mistake. I didn't use the zvaveJS to zwave2mqtt as I was testing and checking the command with the PC controller and the Zniffer to see what is going on between the device and the z-wave controller. As you may see from the video and the Gif the Smart Meter reacts and replies properly if the proper command is received.

@NINE78 I went again to the first message you send us and notice that you use the Parameter 100 set to 1 while the IKA is controlled setting the parameter 100 to 2
2- Endpoints IR external relay (BICOM) disabled, Triac External relay (IKA) enabled

After you do the change exclude the Smart Meter, wait at least 30 seconds and re-include it again.

@fbietlot
Copy link

fbietlot commented Oct 19, 2021

Hi @QubinoHelp thank you for the follow up. I understand the confusion.
Regarding param 100 as I don't have the infrared relay I set it up to 1 (and not 2)

"label": "EP IR external relay dsbld, External relay enbld",
"value": 1

I will try to install PC controller to also do some testing. But unfortunately I don't think I have the knowledge to deal with a Zniffer.
Back to the command send from ZwaveJS. here is the Raw log when I activate the 2 available binary switch 👍

2021-10-19T08:56:48.999Z SERIAL » 0x010e00130a07600d0001250100250785                                  (16 bytes)
2021-10-19T08:56:49.004Z DRIVER » [Node 010] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      7
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 1
                                    └─[BinarySwitchCCSet]
                                        target value: false
2021-10-19T08:56:49.018Z SERIAL « [ACK]                                                                   (0x06)
2021-10-19T08:56:49.028Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-10-19T08:56:49.032Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:49.039Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-10-19T08:56:49.047Z SERIAL « 0x0107001307000003ef                                                 (9 bytes)
2021-10-19T08:56:49.049Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:49.052Z DRIVER « [REQ] [SendData]
                                    callback id:     7
                                    transmit status: OK
2021-10-19T08:56:49.066Z CNTRLR   [Node 010] [\~] [Binary Switch] currentValue: false => false       [Endpoint 1]
2021-10-19T08:56:50.085Z SERIAL » 0x010d00130a06600d0001250225088b                                    (15 bytes)
2021-10-19T08:56:50.086Z DRIVER » [Node 010] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      8
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 1
                                    └─[BinarySwitchCCGet]
2021-10-19T08:56:50.089Z SERIAL « [ACK]                                                                   (0x06)
2021-10-19T08:56:50.096Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-10-19T08:56:50.101Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:50.106Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-10-19T08:56:50.120Z SERIAL « 0x0107001308000002e1                                                 (9 bytes)
2021-10-19T08:56:50.122Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:50.126Z DRIVER « [REQ] [SendData]
                                    callback id:     8
                                    transmit status: OK
2021-10-19T08:56:50.138Z SERIAL « 0x010d0004000a07600d0100250300b1                                    (15 bytes)
2021-10-19T08:56:50.142Z CNTRLR   [Node 010] [\~] [Binary Switch] currentValue: false => false       [Endpoint 1]
2021-10-19T08:56:50.149Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:50.155Z DRIVER « [Node 010] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      1
                                    │ destination: 0
                                    └─[BinarySwitchCCReport]
                                        current value: false
2021-10-19T08:56:54.111Z SERIAL » 0x010e00130a07600d0002250100250988                                  (16 bytes)
2021-10-19T08:56:54.114Z DRIVER » [Node 010] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      9
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 2
                                    └─[BinarySwitchCCSet]
                                        target value: false
2021-10-19T08:56:54.124Z SERIAL « [ACK]                                                                   (0x06)
2021-10-19T08:56:54.134Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-10-19T08:56:54.137Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:54.142Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-10-19T08:56:54.155Z SERIAL « 0x0107001309000003e1                                                 (9 bytes)
2021-10-19T08:56:54.157Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:54.160Z DRIVER « [REQ] [SendData]
                                    callback id:     9
                                    transmit status: OK
2021-10-19T08:56:54.176Z CNTRLR   [Node 010] [\~] [Binary Switch] currentValue: false => false       [Endpoint 2]
2021-10-19T08:56:55.191Z SERIAL » 0x010d00130a06600d00022502250a8a                                    (15 bytes)
2021-10-19T08:56:55.193Z DRIVER » [Node 010] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      10
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 2
                                    └─[BinarySwitchCCGet]
2021-10-19T08:56:55.196Z SERIAL « [ACK]                                                                   (0x06)
2021-10-19T08:56:55.202Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-10-19T08:56:55.215Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:55.232Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-10-19T08:56:55.241Z SERIAL « 0x010700130a000002e3                                                 (9 bytes)
2021-10-19T08:56:55.242Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:55.244Z DRIVER « [REQ] [SendData]
                                    callback id:     10
                                    transmit status: OK
2021-10-19T08:56:55.253Z SERIAL « 0x010d0004000a07600d0200250300b2                                    (15 bytes)
2021-10-19T08:56:55.255Z CNTRLR   [Node 010] [\~] [Binary Switch] currentValue: false => false       [Endpoint 2]
2021-10-19T08:56:55.261Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T08:56:55.264Z DRIVER « [Node 010] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      2
                                    │ destination: 0
                                    └─[BinarySwitchCCReport]
                                        current value: false

I see some difference between your command (but not yet able to decode this)
DC08622a0141081325600D00022501FF00DA97

@blhoward2
Copy link
Collaborator

It looks like your commanding false and it's reporting that it's already false. What happens if you set true?

@fbietlot
Copy link

fbietlot commented Oct 19, 2021

sorry not the best example (I was focusing on message structure.)
Here is an example with true.
Set value to True
But report False

2021-10-19T07:29:31.852Z SERIAL » 0x010e00130a07600d00022501ff25057b                                  (16 bytes)
2021-10-19T07:29:31.854Z DRIVER » [Node 010] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      5
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 2
                                    └─[BinarySwitchCCSet]
                                        target value: true
2021-10-19T07:29:31.869Z SERIAL « [ACK]                                                                   (0x06)
2021-10-19T07:29:31.879Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-10-19T07:29:31.882Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T07:29:31.885Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-10-19T07:29:31.891Z SERIAL « 0x0107001305000003ed                                                 (9 bytes)
2021-10-19T07:29:31.893Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T07:29:31.896Z DRIVER « [REQ] [SendData]
                                    callback id:     5
                                    transmit status: OK
2021-10-19T07:29:31.908Z CNTRLR   [Node 010] [\~] [Binary Switch] currentValue: false => true        [Endpoint 2]
2021-10-19T07:29:32.925Z SERIAL » 0x010d00130a06600d00022502250686                                    (15 bytes)
2021-10-19T07:29:32.927Z DRIVER » [Node 010] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      6
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 2
                                    └─[BinarySwitchCCGet]
2021-10-19T07:29:32.930Z SERIAL « [ACK]                                                                   (0x06)
2021-10-19T07:29:32.937Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-10-19T07:29:32.943Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T07:29:32.946Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-10-19T07:29:32.971Z SERIAL « 0x010d0004000a07600d0200250300b2                                    (15 bytes)
2021-10-19T07:29:32.976Z CNTRLR   [Node 010] [~] [Binary Switch] currentValue: true => false        [Endpoint 2]
2021-10-19T07:29:32.982Z SERIAL » [ACK]                                                                   (0x06)
2021-10-19T07:29:32.985Z DRIVER « [Node 010] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      2
                                    │ destination: 0
                                    └─[BinarySwitchCCReport]
                                        current value: false

@AlCalzone
Copy link
Member

@fbietlot please select your logs after pasting and click this button:
grafik
That will make it easier to digest.

@fbietlot
Copy link

Me again but with good news this time ;-)
@QubinoHelp : your suggestion was actually good for marameter 100 ;-)
@AlCalzone there is a confusion in the config file packages/config/config/devices/0x0159/zmnhtd.json

Here is the config

{
			"#": "100",
			"label": "Enable / Disable endpoints relays",
			"valueSize": 1,
			"minValue": 0,
			"maxValue": 3,
			"defaultValue": 0,
			"allowManualEntry": false,
			"options": [
				{
					"label": "EP IR external relay and External relay disabled",
					"value": 0
				},
				{
					"label": "EP IR external relay dsbld, External relay enbld",
					"value": 1
				},
				{
					"label": "EP IR external relay enbld, External relay dsbld",
					"value": 2
				},
				{
					"label": "EP IR external relay and External relay enabled",
					"value": 3
				}
			]
		}

Versus the manual

Parameter no. 100 – Enable / Disable endpoints IR external relay (BICOM) and TRIAC External
relay (IKA)
Enabling IR external relay (BICOM) and Triac External relay (IKA) or both of them, means that
endpoint (IR external relay) and endpoint (External relay) or both will be present on UI. Disabling
them will result in hiding endpoints according to Parameter set value. Note that hiding endpoint
has no impact on its functionality.
Values (size is 1 byte dec):
• default value 0
• 0 - Endpoints IR external relay and External relay disabled
• 1 - Endpoints IR external relay (BICOM) enabled, Triac External relay (IKA) disabled
2- Endpoints IR external relay (BICOM) disabled, Triac External relay (IKA) enabled
• 3- Endpoints IR external relay and External relay enabled

Value 1 and 2 are inverted.

@AlCalzone
Copy link
Member

That file needs to be reworked as a whole, but I'll at least fix this switchup for now. Great that you figured it out.

@AlCalzone
Copy link
Member

@fbietlot can you verify that the changes made in #3555 match what you changed and make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants