Wow - that’s quite amazing - it’s nearly unreadable it’s so long now .
Take a look at the list of supported channels here and let me know what you’d like added (I can take a guess, but you sounds like you know this better than me, and I have no roller shutters). We don’t seem to have any channels relating to roller shutters yet…
The other thing is that presumably the device config in the database will need updating to support the channels. So, if you can suggest a channel configuration, and update the database for your device that you can test with, I’ll create a binding for you to test.
I also use the fibaro fgrm222 roller shutter module. In my case I use it to control my curtains, where “open” and “close” would be better suited.
The fgrm222 is working fine at the moment, but agree that better named states/command would be welcome. This can also be said for motion and door sensors.
I’d more than welcome any critical feedback on the channel definitions - if someone has some time to look over them, it would really be appreciated. I put them together quite quickly and didn’t spend a lot of time thinking about names as there were bigger fish to fry
Options are handled in a different way, but again, feel free to provide a suggestion. Generally, I’ve kept options that were already in the OH1 binding, although at the moment there’s no way to set them as ESH didn’t provide the support. The change for this was merged this morning, so we will be able to add working config options soon.
I submitted a database changes so my door sensors will have a sensor_door channel instead of a sensor_binary channel. Lets see if that’s an improvement.
fully agree, and you have fried a lot of them, thanks
As for motions sensors, maybe a sensor_motion channel would make a nice addition?
Tried to include 3 Fibaro Motion Sensors with PaperUI. Did not work. Sometimes a device was found, but “unknown”. After a few tries it worked. And i changed some configuration parameters with Habmin2. Transferred this changes to the devices by wakeup them manuell. After this it seems as some sensors stopped working. Like PIR. Very frustrating. Don’t really know whats wrong right there.
After this i cleaned all up. Deleted all node#.xml from the zwave-folder. Reseted the hole hardware…
Included the Fibaro Motion Sensor to the Aeotec Z-Wave Stick by using its own inclusion mode (there is a button on the Stick). Back in PaperUI the nodes are found. Again als unknown. Woke them up a view times until PaperUI found them as Fibaro Motion Sensors. Added them as Things. Switched to Habmin2 because in PaperUI i could not change configuration parameters. The “Save-Button” could not be clicked… In Habmin2 i made changes to “Motion Sensor cancellation time”. Saved them an transferred them to the nodes. Again: Some nodes stopped working.
Solution
Started over again … Deleted everything, reset hardware… Included Sensors to the Stick. Stick back in the USB. Nodes added with PaperUI as things. This time i did not touch configurations parameters! And everything seems like working till the last few hours… In Habmin2 some configuration parameters are empty. Associations Groups are not set! Wakeup interval and Wakeup Node are empty … If i take a look to the node#.xml in zwave-folder the changes i made before (like motion sensor cancellation time) are still set to the values i saved bevor i deleted the nodes and all the files. I don’t understand why the values are still in there… Came back from a mother db?! It’s okay, because those are the values i need! But Habmin2 and PaperUI displaying other values. Or just noting like the Wakeup Interval. In node#.xml there is a wakeup intervall by 7200.
Opinion / Thoughts - BASIC ON BROKEN BY HABMIN2
Configuration Parameter #14 (BASIC ON command frame value) is set to -1 (Negativ). It always was! It was with OH1 and Habmin1 and it is in the node#.xml when its get created.
I think this is the reason why the Motion Sensor stopped working after saving changes with Habmin2. Habmin2 only allowed positive values! (as showing up with not allowing to set a negativ temperature offset) In node#.xml the value #14 is -1 (negativ) but Habmin2 shows 0 at configuration parameter 14. After saving, this value is written so the node#.xml and the node stopped working after syncing. Temperatur and Lux are still okay! But PIR that uses those BASIC ON command is broken after this!
I read something similar in this tread. But without that hint so parameter #14
Questions:
So … Where came those values from?
Can’t set a negativ temperature offset because this “isn’t a allowed value”? (Must be positive?!)
Which file holds the values to sync them to the nodes when its on “pending” … Are there for the node#.xml files? Do i better make changes directly to this files instead using Paper or Habmin?
I’m not sure I follow your problem (it’s quite a long report and a bit difficult to follow - sorry).
What does this mean? HABmin is just displaying the data from the binding…
[quote=“anfuchs, post:956, topic:7522”]
Configuration Parameter #14 (BASIC ON command frame value) is set to -1 (Negativ). It always was! It was with OH1 and Habmin1 and it is in the node#.xml when its get created.
[/quote]Sorry - don’t understand your point here. Is this good or bad?
This is how the database is set, so PaperUI will also show the same I think? Anyway, negative values are not allowed in Z-Wave. You should use 255 most of the time instead of -1.
What values do you mean? Most values are defined in the database.
That’s correct.
No file holds this - it is held in the binding, so when the binding resets, this will be lost.
You can’t make any changes in files - you must use the user interface.
I mean that the BASIC ON value in node.xml is set so -1 if the node.xml is generated the first time. Changing this to 0 (because thats what cabman does by not allowing negativ values, breaks the motion sensor. No motion is reported after saving the parameter changes in cabman.
-1 themes to be the right value. But it gets broken by habmin. Because it changes it so 0.
Yes, Paper shows the same values as Habmin
How can that be correct? With OH1 this was absolut possible. The Fibaro Motion Sensor itself allows negative temperature offsets! And there are a lot oft people needing one.
So the binding generated the node#.xml files with the parameter changes i made befor deleting and recreating the things? Don’t understand why the Paper and Habmin are displaying other values than the node#.xml files are holding. And, the values from node#.xml are those the Sensors are using right know.
I’ve not looked at this parameter, but you should use 255 - not -1 (negative values are in theory prohibited).
It’s what the protocol defines. However, it’s not really relevant since for a 1 byte value, -1 is the same value as 255. Basically, what this means is that the protocol defines unsigned values - how the sensor uses them is up to the sensor.
Yes - it reads the data from the device to generate the file.
So in this case the database is wrong right? (Parameter 14 set to -1) ore comes this value directly from the motion sensor itself. I’am sorry! I really mixing up what the device delivers and whats coming from the database.
If the -1 comes from the devices itself, and the protocol does not allow -1, habmin should change -1 to 255 instead of 0. Because 0 means “OFF” and 255 means “ON”. So the standard behavior of the device isn’t changed anymore.
I’ll give it a try with 255.
Temperatur Offset
In OH1 Binding it is possible to set values like -10. The Tooltipps showing values vom -100 - +100.
So how do i set a negative temperature offset in OH2. The same devices could handle this with OH1 and with OH2 (the feature!) the same device like bevor loses function?!
There must be a way to have negative offsets … for illumination, temperature, humidity sensors …
Empty parameter
What about the empty parameters in Habmin/Paper?
Wakeup Intervall is set so 7200 in the node#.xml but Habmin/Paper displaying nothing. So there Binding didn’t not read the xml the right way? Because this value came from the device itself i’am right thinking it uses those 7200? Also the Associations Groups are empty. Don’t know if i should change this or better leaving everything untouched after this long day.
Ultimately, the plan will be to use set options for these sort of values, so that it’s easy for the user. At the moment, the database doesn’t always have this configured - it will take some time…
And that doesn’t work in OH2? What parameter do you mean - I’ll check the database. The binding should sort out the conversions - hopefully.
Maybe this isn’t displayed correctly from the binding - I’ll check (it looks ok though).
I’m sure associations are working fine, so if they are empty then you should set them. However, make sure that you use the latest OH2 as there is a bug that has been fixed in the last 2 days.
Did you changed it? … Because the devices always initialized with -1. Maybe because i made the inclusion between the Stick and the Sensor using its hardware button from the stick instead of PaperUI?
I mean Parameter 66 Temperatur Offset. Doesn’t work because i can’t set negativ numbers
I’am using the latest snapshot (online version).
Association Groups: What the difference between 1.Device Status and 2. Controller Update?
Ok - the database needs to be updated… In the past (ie OH1, and OH2 up till recently) these limits weren’t checked so errors in the database didn’t matter. Now they are checked, so the errors need to be fixed…
You’d need to check the manual. Typically for Fibaro sensors they have 3 groups, and it’s normally (but not always) group 3 that needs to be set. It’s up to the device/manufacturer what each group does though, so it’s totally dependant on the device…
Setting parameter 14 from -1 to 255 is working. As said before. BUT after updating the note with this parameter change, the alarm sensor stopped working … Even if i set OpenHAB Controller to the association Group 2 (tamper alarm) it still not working.
My other Motions Sensors, not updated by Habmin or PaperUI still reporting tamper alarm.
It did not think that this parameter (14) is the problem, but something else must be changed by habmin, that this happens. At the point where the tamper alarm has to reporter it just says “Thing ‘zwave:device:153dc43a57a:node4’ has been updated.”
Normally for Fibaro you should use Group 3 for the controller. I’m not sure this will help, but this is what OH1 would automatically set (OH2 should as well, but I think there’s a problem with that in the current version).
Did set Group 3 for the controller. Didn’t change anything. Maybe there is something wrong with the configuration parameter 24 - tamper operating modes.
From OH1 i know it has a lot of operating modes. Maybe just the text is displayed the wrong way … but maybe it is the value itself.
Tried this:
BEFOR saving device with Habmin tamper alarm worked out of the box. Alarm ON was send.
After updating the config i have to change parameter 24 to value 1. After this tamper ON and OFF is reported…
BEFOR touching the config tamper Alarm was reported with value 0 whats means only ON is report. Now setting value 0 reports “Thing ‘zwave:device:153dc43a57a:node4’ was updated” instead of ON.
Value 3 didn’t work also:
“3 - Tamper alarm is reported in Sensor Alarm command class / Cancellation is reported in Sensor Alarm commad class after the time period set in parameter 22. Sensor’s orientation in space is reported in Fibar Commad Class after the time period set in paramer 22.”
Looking in the database, all options 0 to 3 are the same so I’m not sure what this does, but changing the configuration clearly will change what’s sent
.
… Because the devices always initialized with -1. Maybe because i made the inclusion between the Stick and the Sensor using its hardware button from the stick instead of PaperUI?
