openHAB2 is still a beta snapshot, so we should all be willing to test it as much we can (although I must admit I’m using it already as a “daily driver” because it’s pretty stable already)
2nd Edit: and yes, it’s still working after reinit:
2016-12-10 17:56:44.941 [ItemStateChangedEvent ] - FibUniSens1_1 changed from OFF to ON
2016-12-10 17:56:44.963 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:46.859 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:56:47.014 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:48.499 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:56:48.604 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:50.348 [ItemStateChangedEvent ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:57:05.359 [ItemStateChangedEvent ] - FibUniSens1_1 changed from ON to OFF
I don’t get it: the warning message disappeared.
Sometimes I’m really lost in the jungle of openHAB debug log files … (not only for zwave).
I’m sure I did delete the device as thing and re-added it with the currently used snapshot. I did not do a re-initialization or deleted the xml file though.
Is that what I should have done after the database update?
If yes, sorry, my mistake …
This shouldn’t be needed (I think!). I think that the XML should be deleted when you remove the thing, although I’m not 100% sure.
Anyway, I don’t think that’s the issue here since the BASIC class was missing from the device endpoints. This probably means that there was some sort of error when the binding interrogated the device. I’ll take a look at your log to see if I can see where this gets defined, but in the upcoming version of the binding, this is done differently anyway as BASIC should always be included, and it’s not mandatory for a device to report that it’s supported.
I added an extra check to make sure that manufacturer data is set before I export since I had a new manufacturer which wasn’t properly configured… Unfortunately, in the summary list, this information isn’t available so it shows errors (at the moment). I’ll sort this out - it’s not real though and ‘only’ shows up on this page - not the device pages (unless the data is really not set).
I’ve removed this check for now - once I work out how to manage it in the device list I’ll add it back… All the checks are managed centrally, but in this list I don’t load all data as it’s not needed (although I might see if it slows things down as it might ensure better consistency)…
I’m trying to migrate to OH2 but I’m facing some problems with the Fibaro Universal Sensor: I can configure that as a contact but once I try to see it on the sitemap, nothing appear. I only see the label without the value.
On my sitemap it is configured as “Text” and in item configuration, I’m using a mapping.
In habmin->things, I see the value “Triggered” and “Untriggered”.
I found it wouldn’t work correctly as a contact, but works fine as a Switch. Since then has been 100% reliable (it’s on a doorbell, so triggered multiple times/day).
All configurations at defaults. Items file as follows:
Is it a Contact (Open/Closed), or is it a Switch (On/Off), or something else - your view is it’s a contact but if the binding is using a switch, then you will need to use the same type.
Overlooked that statement: that is wrong.
If you bind an item to one of the binary_sensor channels (in HABmin click on the plus sign) it comes up as default with a switch … and you should not change the default as the item might not work then …
OK, I configured that as a switch and I get ON and OFF correctly.
I have 2 problems:
The switch is updated only on page refresh
The [%s] in the label doesn’t work
Frankly speaking, I don’t like to use that as a switch because any user can change the value of the item and this don’t make sense: a device like this should be a contact and not a switch.
Thanks sihui!
I solved that. The problem now is that the text value isn’t updated. I have to refresh (F5) the page to see the changes.
This seems to be more related to basicui because the classic works fine.
Thank you for starting this thread. I experienced the same problem with this sensor, but managed to get it working with the help from this thread. I can confirm it’s working now with the zwave 2.0 binding from 2.0.0.b5.
I have a FGBS-001 with a 1-Wire temperature sensor connected to Openhab2 using z-wave binding 2.2.0.201712022337.
Openhab reports the temperature with a value in the range of 170 at room temperature. When I connect additional sensor both read the same value in the range of 170. (Additional Sensor added as per Fibaro instructions.)
The log console shows the following "NODE 10: Received a multi instance encapsulation with a destination endpoint = 3. " for each temperature update.
Solved*
The DS18b20 Temperature sensors were set 9 bit resolution, they need to be set to 12 bit resolution. To change the resolution I followed the guide here. It uses an Arduino to write the resolution to 12 bit in the eeprom.
