I would prefer to make a string type that provide all the information in a single item rather than getting into the mess of trying to recombine different data from the same event. I assume that’s ok?
So we’d maybe have a channel that said “alarm=1, event=2”. How does that sound?
Does it need to be human readable? Maybe just 1:2 or 1,2 to make parsing easy.
No, but I want to make it self defining, and parsable.
With this suggestion, it’s not ‘future proof’ so if we add another dimension in future, then it gets messy! Here, there’s only currently two elements, so we can do what you suggest. However, I went down exactly this route for the central scene command class and we have “.” as a decimal value. Now newer versions add a timer value and this can’t be supported with this sort of format.
So, I would prefer to have something that is self defining. This doesn’t need to be human readable, but it would probably end up that way (eg json formatting). The question is how easy is it to process this in a rule (I’m not a rule expert, so someone else might want to comment).
It’s a bit messy and not my preferred approach, but I don’t see any nice alternative being implemented within the limited functionality that ESH/OH offers in this area. If people have suggestions though, please feel free to suggest them 
.
You’ll always have this problem, even with your example if a value included a comma (,) then it’s the same problem. What we can do in the future is simple escape the characters before adding them to the string if necessary. Period (.) is a poor separator I think as you discovered. colon (
or comma (,) are better and probably wouldn’t be in a value in most cases. Definitely easier to just split on a specific character than parsing the property names, =, etc. Unless there is a JSON parser we could use within rules.
I’m not sure what problem you mean? Do you mean future proof? If so, then a having a string, and managing any issues there is a LOT more future proof than a single number.
Well, that’s why I suggested json. However, if we choose a delimiter, then we can mange deltas with an escape - it’s not that hard. It’s what json does, it’s what java, C, and every other parse does…
My preference is something completely different where items/channels have a primary type, and we can then set attributes, but we’re stuck with the limited definition that ESH provides, and in this instance I think a string is the only option.
Not a rule expert, but using a JSON transform or split in a rule is fairly easy. I currently use both in my rules. Cart before horse, but here are some possible examples (Lock_Alarm and Lock_Event would be Number items):
rule "Lock: String updated"
when
Item Lock_String received update
then
Lock_Alarm.postUpdate(transform("JSONPATH", "$.alarm", Lock_String.state.toString) as DecimalType)
Lock_Event.postUpdate(transform("JSONPATH", "$.event", Lock_String.state.toString) as DecimalType)
val String[] splitString = Lock_String.state.toString.split(",")
Lock_Alarm.postUpdate(splitString.get(0) as DecimalType)
Lock_Event.postUpdate(splitString.get(1) as DecimalType)
end
May have found a problem with the treatment of the Fibaro Button under the refactored binding. Works flawlessly under the standard 2.0/2.1 binding but, under the factored binding, it sometimes takes a while to come back to life when it hasn’t been used for a while. Often this is first thing in the morning, but unpredictable. The debug logs when it doesn’t respond straight away look are quite lengthy, but have saved them here.
thank you!
Dan
The log has been filtered so it’s not of any use. Please provide unfiltered logs…
Sorry to be dense, but what’s a filtered log?
Are you doing a grep for NODE 26? That would filter out a lot of other stuff.
Exactly what @5iver said - you’ve used something like grep to filter out messages to a specific node, and this has removed most of the information I need…
Thank you both - I was indeed being dense. I’d grep’d NODE 26, which is the one causing the trouble. I’ve now uploaded the full log
Dan
I don’t see anything obviously wrong here - at least not with the binding. The only thing to note is that it’s getting to the point where it’s updating neighbours which can take a while - maybe this is what you’re seeing?
What is very strange is that I see the same information in your log multiple times - ie exactly the same data, with the same timestamps… Maybe this is something to do with your logging configuration - it just seems a bit strange…
well… when you’re on bleeding edge, its bound to be broken sometimes
@chris, on the latest 988 version and development binding z-wave seems to be broken.
Log files show a lot of this:
2017-07-23 19:18:24.540 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:24.545 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:26.553 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-07-23 19:18:32.882 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-07-23 19:18:34.461 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:34.466 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 21: Sent Data was not placed on stack.
2017-07-23 19:18:37.968 [ERROR] [lmessage.RequestNodeInfoMessageClass] - Request node info not placed on stack due to error.
2017-07-23 19:18:39.900 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data was not placed on stack.
2017-07-23 19:18:39.907 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 2: Sent Data was not placed on stack.
It looks like there were big changes to ESH according to:
I doubt it’s related to the changes in ESH, and I’m not even sure it’s a binding issue - I suspect it’s more likely to be an issue with your system.
This error isn’t coming from the binding - it’s coming from the controller (ie the stick) and normally this sort of thing means the controller needs to be reset (ie removed from the PC and plugged back in).
really funny, I had restarted the computer several times before hand.
But removing the stick from the computer physically when it was running and then putting it back in did the trick.
Thanks
I found that the computer I run OH on does not kill power to the USB ports during a restart, so my zstick didn’t reset during a restart. This required me to power down completely or unplug/plug in the zstick to actually do a clean startup.
@chris, can you shed any light on adding new channels to openhab? Is that permitted? Or can you only use predefined channel names? When I attempted to add the channel alarm_event, paperui errored out attempting to link the channel to an item.
I’m asking because I thought I might help code the changes and submit a pull request but I’m just learning ESH et all.
Thanks.
One other thing, I find that when I lock and unlock the Yale YRD120 a few times in quick session some of those signals get lost and never make it to the controller. However, in normal operation, my hack of changing the alarm_general channel to DecimalType has given me exactly what I need and has proven to be reliable.
Thanks.
@chris, this has been discussed in several threads.
But probably not regarding development binding.
My Fibaro eye (Motion Sensor FGMS-001) gives me:
Motion
Luminance
Temperature
However, alarm_tamper does not work.
Looking at the logs I can see that the command is sent but no “state is written”.
02:08:30.798 26
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=255
02:08:30.801 26
STATE UPDATE zwave:device:e25d115d:node26:alarm_motion ON [OnOffType]
02:08:31.357 26
RX REQ ApplicationCommandHandler SENSOR_ALARM_REPORT GENERAL=255
02:08:34.717 26
RX REQ ApplicationCommandHandler SENSOR_MULTI_LEVEL_REPORT LUMINANCE=10
02:08:34.720 26
STATE UPDATE zwave:device:e25d115d:node26:sensor_luminance 7 [DecimalType]
02:09:01.670 26
RX REQ ApplicationCommandHandler SENSOR_BINARY_REPORT=0
02:09:01.672 26
STATE UPDATE zwave:device:e25d115d:node26:alarm_motion OFF [OnOffType]
02:09:01.831 26
RX REQ ApplicationCommandHandler SENSOR_ALARM_REPORT GENERAL=0
LOG: https://www.dropbox.com/s/6adodsvs0vg2x94/openhab.log?dl=0
Development XML: https://www.dropbox.com/s/i8rbce8org4j0vh/network_d90b1add__node_26.xml?dl=0
OLD openhab 1.9 XML: https://www.dropbox.com/s/mddc72rbbb6vglo/node11.xml?dl=0
Cheers!