The node.xml files are generated by the binding at the completion of the interrogation/initialisation, and whenever something changes (eg if you change a configuration parameter). This is done to speed up the initialisation when the binding starts next time…
If some nodes don’t have an XML file, then it likely means they aren’t completing the initialisation phase which probably indicates something isn’t right somewhere. Note that for battery devices, these files can take some time to appear…
thanks, Chris
I have a YRD120 which seems similar to YRD220 from what I can tell since I’ve been using that documentation. YRD120 did not have the alarm_number channel originally either until I added it to the jsondb as well. You can modify the jsondb for this easily by stopping openhab, edit json, and restart openhab as you mentioned.
Can I request that people update the database please if channels are missing. Otherwise it doesn’t get updated for everyone to use!
Thanks
Chris
@chris, I did modify the database to add alarm_number for YRD120. But for the alarm events I reused the alarm_general channel by changing the binding type to DecimalType. Can we just make up a new channel of DecimalType to get the alarm events? I tried adding alarm_event and PaperUI just errors out trying to link the channel to an item.
Thanks.
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).