doh!
Need a cup of coffee 
Iâll wait for the next time you update the binding, its only 1 lamp I cannot control so no biggie.
Cheers and thanks again!
Incidentally, my fibaro RGBW had been working fine, but stopped working with the latest version. Deleting the Thing, deleting the xml file and then re-adding fixed it.
Incidentally, my zwave folder has some files like ânode40.xmlâ and some like ânetwork_c10458a8__node_39.xmlâ, with some nodes showing up in both formats. Is that a problem and, if so, what should I do?
thanks!
Dan
Itâs not a problem, but you can delete the node40.xml files if you want. These are from the master binding - the ones that have the network on the front are from the new version.
thanks. Is it a problem that some of the nodes donât have a new version xml?
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
1 Like
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âŠ