tobof / openhab-addons

The next-generation open Home Automation Bus (openHAB)
Eclipse Public License 2.0
39 stars 30 forks source link

RollerShutter item not updated when recieving data #65

Closed fab33 closed 6 years ago

fab33 commented 7 years ago

Hi, My RollerSutters devices can be controlled by button or can be suddenly stop by user and they send updates to the gateway (Percetage value). Binding correctly recieve data but not updating RollerShutter items : `22:51:35.159 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'VoletBureau' received command 50

22:51:35.168 [DEBUG] [rs.internal.protocol.MySensorsWriter] - Sending to MySensors: 50;1;1;0;3;50

22:51:35.169 [INFO ] [marthome.event.ItemStateChangedEvent] - VoletBureau changed from 100 to 50

22:51:37.796 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'VoletBureau' received command STOP

22:51:37.799 [DEBUG] [rs.internal.protocol.MySensorsWriter] - Sending to MySensors: 50;1;1;0;31;1

22:51:37.986 [DEBUG] [rs.internal.protocol.MySensorsReader] - 50;1;1;0;3;87

22:51:37.987 [DEBUG] [ternal.handler.MySensorsThingHandler] - Setting last update for node 50 to 2017-02-14T22:51:37.987+0100 `

andreacioni commented 7 years ago

Hi @fab33, we are currently hard working on this binding. With the new version I'm quite sure that your issue won't appear, but I'll take a look πŸ˜‰

fab33 commented 7 years ago

Thank you for your work on this binding. It rocks ! I will test as soon as you made a new release !

andreacioni commented 7 years ago

Thank you for reporting that! Unfortunately this issue is present also in the new version, I'll try to fix it as soon as possible.

andreacioni commented 7 years ago

@fab33 I've now fixed your issue but I've some doubts about my solution. Cover thing is not easy to manage inside binding. I would ask your personal opinion about a question. What about adding a "dimmer" (percentage) channel in addition to "cover"? You could use it to show the percentage of the Rollershutter.

Let me know :)

fab33 commented 7 years ago

I don't understand exactly what you ask. Actually S_COVER child ID contains V_PERCENTAGE message. before S_COVER, we usually use a separate child ID for percentage (I think it's implemented like this in Jeedom) If we use the last solution, how we can declare it in Shutter item ?

andreacioni commented 7 years ago

Yes my question should sound tricky to understand if you haven't see how the binding works. Anyway @tobof has merged the fix I made and in the meantime I convinced myself that this solution could be right πŸ‘

gersilex commented 7 years ago

I can confirm the problem with customSensor and text as well. Probably this affects all the thing types.

Somehow the items are write-only. Incoming messages are received just fine. The binding is also updating the last update channel, but the messages are never parsed and fed back into the channel of the thing.

In my example, I send a payload of 0 in V_VAR1 to the gateway. You can see it comes in just find but the item never updates. Sending openhab commands to the item works fine and the commands are sent to the customsensor as well.

20:43:14.207 [DEBUG] [rs.internal.protocol.MySensorsReader] - 0;255;3;0;9;TSP:MSG:READ 11-11-0 s=2,c=1,t=24,pt=2,l=2,sg=0:0
20:43:14.218 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsBridgeHandler@1c41736
20:43:14.220 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.sensors.MySensorsDeviceManager@8d3162
20:43:14.221 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.protocol.serial.MySensorsSerialConnection@1e81d8c
20:43:14.222 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@bf65f1
20:43:14.223 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@10ec8d8
20:43:14.224 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@19f38ad
20:43:14.226 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@1eb59d
20:43:14.227 [DEBUG] [rs.internal.protocol.MySensorsReader] - 11;2;1;0;24;0
20:43:14.229 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsBridgeHandler@1c41736
20:43:14.230 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.sensors.MySensorsDeviceManager@8d3162
20:43:14.238 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.protocol.serial.MySensorsSerialConnection@1e81d8c
20:43:14.239 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@bf65f1
20:43:14.245 [DEBUG] [ternal.handler.MySensorsThingHandler] - Setting last update for node 11 to 2017-02-21T20:43:14.241+0100
20:43:14.246 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@10ec8d8
20:43:14.249 [DEBUG] [ternal.handler.MySensorsThingHandler] - Setting last update for node 11 to 2017-02-21T20:43:14.247+0100
20:43:14.250 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@19f38ad
20:43:14.252 [TRACE] [col.serial.MySensorsSerialConnection] - Broadcasting event to: org.openhab.binding.mysensors.internal.handler.MySensorsThingHandler@1eb59d
20:43:14.256 [DEBUG] [ternal.handler.MySensorsThingHandler] - Setting last update for node 11 to 2017-02-21T20:43:14.253+0100
root@openhab /u/s/o/addons# stat org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar
  File: β€˜org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar’
  Size: 76453           Blocks: 152        IO Block: 4096   regular file
Device: b302h/45826d    Inode: 130928      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2017-02-21 20:58:27.000000000 +0100
Modify: 2017-01-18 14:09:30.000000000 +0100
Change: 2017-02-21 20:58:27.775296901 +0100
 Birth: -

I'll go back to the rule-based parsing of incoming messages for now. If I can provide you with any information, please let me know.

andreacioni commented 7 years ago

Hi @gersilex, thanks for reporting. I'll take a look if this issue is also present in test version. Could you also provide item/thing definitions for the customSensor and text?

gersilex commented 7 years ago

Of course. Here you go:

items

Number aacc_last_update "Heartbeat [%s]" {channel="mysensors:rgbLight:bridge:living_aacc_color:lastupdate", expire="5m"}
Number aacc_mode  "Modus" {channel="mysensors:customSensor:bridge:living_aacc_mode:var1"}

things

Bridge mysensors:bridge-ser:bridge [serialPort="/dev/mysensors"] {
  mySensorsMessage gateway [ nodeId="999", childId="999" ]

  rgbLight     living_aacc_color    [nodeId="11", childId="1", requestAck=true]
  customSensor living_aacc_mode     [nodeId="11", childId="2", requestAck=true]
}

Thanks for looking into it.

andreacioni commented 7 years ago

@gersilex I didn't encounter this bug in the test version. Rollershutter are a little bit tricky to manage because it combines more variable (V_STOP,V_UP,V_DOWN,V_LEVEL) into one single channel (cover channel). For all other sensor/actuator (like custom/text) the situation is very different and it is more linear (one variable to one channel). So it is not strange that with the refactoring we are doing the issue is gone πŸ˜ƒ

gersilex commented 7 years ago

@andreacioni Is there a way to download a compiled version of the test version? If not, when can we expect a new SNAPSHOT?

andreacioni commented 7 years ago

To see if Rollershutter/CustomSensors issue is solved, you could use this SNAPSHOT from my repository. Please remember that it is a test version and so I advise against using it in production environment. Let me know if your test goes well as mine!

fab33 commented 7 years ago

It works fine for me. Thank you.

gersilex commented 7 years ago

Can confirm it works fine. Great work with the graceful handling and clear log messages that cam up in the test version:

22:54:32.691 [WARN ] [rs.internal.gateway.MySensorsGateway] - Variable 47 not present
22:54:53.999 [WARN ] [rs.internal.gateway.MySensorsGateway] - Presented child is alredy present in gateway
22:54:57.684 [INFO ] [marthome.event.ItemStateChangedEvent] - aacc_mode changed from 9 to 21

As advised I will go back to the recent SNAPSHOT and use the rule-based thing while waiting patiently for a final update and comment :grin:

creynlds commented 7 years ago

Reading above "Rollershutter are a little bit tricky to manage because it combines more variable (V_STOP,V_UP,V_DOWN,V_LEVEL) into one single channel (cover channel)" and on MySensors: S_COVER 5 Window covers or shades V_UP, V_DOWN, V_STOP, V_PERCENTAGE something does not make sense and I see this also in how it is working: 21:15:54.420 [DEBUG] [rs.internal.gateway.MySensorsGateway] - Child 0 found in node 12 21:15:54.422 [DEBUG] [ensors.handler.MySensorsThingHandler] - Updating channel: cover(29) value to: UP 21:15:54.438 [DEBUG] [ensors.handler.MySensorsThingHandler] - Setting last update for node/child 12/0 to 2017-06-03T21:15:54.000-0400 21:15:54.444 [DEBUG] [rsAbstractConnection$MySensorsReader] - 12;0;1;0;30;1023 21:15:54.445 [INFO ] [marthome.event.ItemStateChangedEvent] - Sensor12LastUpdate changed from 2017-06-03T21:15:43.000-0400 to 2017-06-03T21:15:54.000-0400 21:15:54.451 [DEBUG] [rs.internal.gateway.MySensorsGateway] - Node 12 found in gateway 21:15:54.453 [DEBUG] [rs.internal.gateway.MySensorsGateway] - Child 0 found in node 12 21:15:54.461 [DEBUG] [ensors.handler.MySensorsThingHandler] - Updating channel: cover(30) value to: DOWN To me there is a sensor, S_COVER and there are variables, V_UP, V_DOWN, V_STOP, V_PERCENTAGE. I see nothing on MySensors that says these variables are some state of variable (channel) V_COVER, which is also not mentioned on MySensors. However, it seems this binding is placing V_UP (29) and V_Down (30) into this undocumented V_COVER; please help me understand why. How is this any different than: S_MOTION 1 Motion sensors V_TRIPPED, V_ARMED, which you have all independent variables (channels) for these variables. Reference: https://www.mysensors.org/download/serial_api_20

andreacioni commented 7 years ago

Hi @creynlds, I implemented the solution with cover-channel. I understand your doubt. The answer of your question is not simple and involves the knowledge on how OpenHab treats items like cover. OpenHab not allow to have three separate channel for cover items, it groups all of that into one item. This involves differences between cover and simple item like motion (where we can have one channel for every variable). I swear you I spent some hours to make S_COVER child works πŸ˜‰ . Please don't think on cover-channel as a MySensors variable. It is only a convenience channel that OpenHab recognize and treat with a specific behaviour.

Did you use S_COVER child? Have you experienced some issue?

creynlds commented 7 years ago

Thanks @andreacioni for the reply. Yes, I have used it without issue I just need to have access to more variables; would it be possible to add the V_VARs to cover? I have switched to customSensor, but if I had more variables to use in cover I would use it.

andreacioni commented 6 years ago

Hi @creynlds, sorry for the long delay. Your suggestion was discussed on MySensors forum here (see answer 3 of TimO). I agree with you about adding these channels in cover (and all the other things) but, as you see in the forum discussion, there are pros and cons.