search

openhab / org.openhab.binding.zwave

openHAB binding for Z-Wave
Eclipse Public License 2.0
171 stars 202 forks source link

FortrezZ LLC MIMO2+ device multilevel sensor value overwritten #1413

Closed kpanchen closed 4 years ago

kpanchen commented 4 years ago

If the problem is associated with a device, please provide the following -:

Provide a full debug level log of the problem.

debug_excerpt.zip

Problem description: Device itself works fine with the binding. However device configuration provided have the same Channel for two classes:

  </channel>
  <channel id="sensor_general1" typeId="sensor_general">
    <label>Sensor 1</label>
    <properties>
      <property name="binding:*:DecimalType">**SENSOR_MULTILEVEL:1,BASIC:1**;type=GENERAL</property>
    </properties>
  </channel>
  <channel id="sensor_general2" typeId="sensor_general">
    <label>Sensor 2</label>
    <properties>
      <property name="binding:*:DecimalType">**SENSOR_MULTILEVEL:2,BASIC:2**;type=GENERAL</property>
    </properties>
  </channel>

Device can work in two modes: periodic send and send when changed. For most sensors (binary specifically) "send when changed" is a prefered mode and it works the following way: configuration parameters set to indicate when sensor is triggered. When triggered device sends two classes to LIFELINE: SENSOR_MULTILEVEL indicating sensed value and BASIC indicating that it was triggered. However configuration links both to the same channel at the second (BASIC) will always overwrite value almost immediately, those should be a separate channels on both sensors.

Please let me know if you need more information.

Thank you.

cdjackson commented 4 years ago

Device itself works fine with the binding.

If the device works fine, then I'm not sure what the problem is?

However device configuration provided have the same Channel for two classes:

It is not the same channel - it is different. It is two different channels linked to two different command classes.

however switch_binary is still absent from Basic Class it would be possible to read values.

Why do you need this though? Is it used for something - you don't mention this in your first comment. The BASIC class is linked (as you can see) to the multilevel class.

kpanchen commented 4 years ago

Device itself works fine with the binding.

If the device works fine, then I'm not sure what the problem is?

Meaning device communicating with the controller and sending information it is suppose to send, however binding because of misconfiguration is overwriting multisensor value.

However device configuration provided have the same Channel for two classes:

It is not the same channel - it is different. It is two different channels linked to two different command classes.

No, it is the same channel linked to both. And the second one is always replacing sensor value with 0 or 255 depending on was it triggered or triggered. In the new database it is different from the old one (see my second comment).

however switch_binary is still absent from Basic Class it would be possible to read values.

Why do you need this though? Is it used for something - you don't mention this in your first comment. The BASIC class is linked (as you can see) to the multilevel class.

Exactly and it shouldn't - BASIC class is just notifying that sensor was triggered and should be a switch channel, MULTILEVEL is the numeric value of the sensor it should be number as it is now. In the new database this is fixed for so called endpoint 0 (which is technically the same as Endpoint 1 only used with controllers which don't understand multiple endpoints), there we have Switch Binary on Basic and Number on Multilevel, same should be on Endpoint 1 and 2.

cdjackson commented 4 years ago

No, it is the same channel linked to both.

Pleae explain what you mean then since the definition quite clearly is different. The channel ID is different for each, and the endpoint is different for each channel - they are different definitions.

endpoint 0 (which is technically the same as Endpoint 1 only used with controllers which don't understand multiple endpoints)

That is not technically true. The two endpoints are different - the root endpoint is supported on all devices and is not the same as endpoint 1. It is normally a combination of information from multiple different endpoints.

Please feel free to update the database directly then since I'm not sure I understand your issue.

kpanchen commented 4 years ago

Let me try it differently. Here's excerpt from MIMO2 documentation: One of the following, depending on whether Endpoint 1 or Endpoint 2: • SIG1 (Multilevel Sensor Report, Multichannel) - upon change-of-trigger or periodically (Default: every 20 minutes) • SIG2 (Multilevel Sensor Report, Multichannel) - upon change-of-trigger or periodically (Default: every 20 minutes) 2 2 One of the following, depending on whether Endpoint 1 or Endpoint 2: • SIG1 (Basic Set) - upon change-of-trigger • SIG2 (Basic Set) - upon change-of-trigger

In XML configuration we have this:

<channel id="sensor_general1" typeId="sensor_general"> <label>Sensor 1</label> <properties> <property name="binding:*:DecimalType">COMMAND_CLASS_SENSOR_MULTILEVEL:1,COMMAND_CLASS_BASIC:1;type=GENERAL</property> </properties> </channel>

So both MULTISENSOR and BASIC pointing to the same channel called: "sensor_general1", when sensor triggered device sending both, here's the log:

NODE 15: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=2.88E+3 NODE 15: Updating channel state zwave:device:controller:node15:sensor_general1 to 2880 [DecimalType] - that's the correct value.

However second later: NODE 15: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_BASIC, value=0 NODE 15: Updating channel state zwave:device:controller:node15:sensor_general1 to 0 [DecimalType] - this is incorrect! This value 0 must go to a separate channel something like "sensor_trigger1".

This separation must be done for all three Endpoints otherwise there's no way to read value of the sensors. I guess something like this: <channel id="sensor_general1" typeId="sensor_general"> <label>Sensor 1</label> <properties> <property name="binding:*:DecimalType">SENSOR_MULTILEVEL:1;type=GENERAL</property> </properties> </channel> </channel> <channel id="sensor_trigger1" typeId="sensor_general"> <label>Sensor Trigger 1</label> <properties> <property name="binding:*:DecimalType">BASIC:1;type=GENERAL</property> </properties> </channel>

P.s. I've removed my other comment to avoid confusion.

kpanchen commented 4 years ago

I think I see where we have a problem, in the database it is set to treat multilevel as basic (see screenshot), it should be false: bastrue

Triggers channel is not really required as change in the value of multisensor basically means it was triggered. I can change it, raise a ticket to get access.

cdjackson commented 4 years ago

As I said earlier, please feel free to update the database with this change if that’s what is needed. There is no such thing as a trigger channel in the binding, so just ignore that.

kpanchen commented 4 years ago

As I said earlier, please feel free to update the database with this change if that’s what is needed.

It seems like I have access now but when I change it and click save it blinks with a green checkmark and when I try to go back it is still the same. Am I doing something wrong?

cdjackson commented 4 years ago

There is a known bug saving the endpoint information. I will look at that over the next few days.

kpanchen commented 4 years ago

There is a known bug saving the endpoint information. I will look at that over the next few days.

Thank you!

cdjackson commented 4 years ago

I've fixed the bug on the database site and updated the command classes to remove basic=true.

kpanchen commented 4 years ago

I've fixed the bug on the database site and updated the command classes to remove basic=true.

Thank you so much, I also set it to False on Endpoint 0. Do I need to do anything? I guess it will go in the next binding update? I can test it and close the issue?

cdjackson commented 4 years ago

Once the binding is updated you need to update to the latest snapshot. If you’re unsure about how to do this, please discuss on the forum.

On 1 Oct 2020, at 07:42, kpanchen notifications@github.com wrote:

I've fixed the bug on the database site and updated the command classes to remove basic=true.

Thank you so much, I also set it to False on Endpoint 0. Do I need to do anything? I guess it will go in the next binding update? I can test it and close the issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/1413#issuecomment-701923655, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH6IQ4WKI7DL3TTP4YE23LSIQQFTANCNFSM4RZDD3GA.

kpanchen commented 4 years ago

I've tested the snapshot version and it works fine now. "Thing" has to be removed and re-added. BASIC CHANNEL is empty now and not linked to anything, can be link if needed to something like sensor_binary. I don't need that, but if somebody request it after update I can do that.

Thanks a lot, Chris!! Closing the issue!