Odd zwave things defintion I cant explain

I managed to get zwave working last night. For some reason, the serial driver wasn´t installed… I cant explain how come the controller was able to scan the devices. But it did. When I installed the serial driver (again). Then the scanning show the devices correctly…

Anyway… something odd is still going on. @chris
In my endless try to get the controller to read the devices the last coupple of days, I tried different stuff. First I had the controller in a thing file. Then changed it to a PaperUI thing, and then back and forth a few times.
After installing the serial driver last night when things started to work, I ended up having the controller in a thing file… This is my thing file:

Bridge zwave:serial_zstick:controller "Z-Wave Controller" @ "Z-Wave" [ port="/dev/ttyUSB_ZStick", controller_softreset="false", controller_master="true", heal_enable="true", heal_time=2 ]
{   

 }  

But notice my devices in PaperUI, (take a notice of the thing definition).

My controller is: “zwave:serial_zstick:controller”
But my devices are scanned at “zwave:device:controller”

Whats even more strange… Things are working…
These are my AeoTec Multisensor 6 items:

// Aeotec Multisensor6
Switch      ZWaveNode5ZW100MultiSensor6_MotionAlarm              "Multisensor6 PIR Alarm [MAP(motion.map):%s]"  		<cum_motion>  	(gMotion)	{channel="zwave:serial_zstick:controller:node5:alarm_motion"}
Number      ZWaveNode5ZW100MultiSensor6_SensorRelativeHumidity   "Multisensor6 SensorRelativeHumidity [%.0f %%]"   		<Humidity>  	(Fugtighed)	{channel="zwave:serial_zstick:controller:node5:sensor_relhumidity"} 
Number      ZWaveNode5ZW100MultiSensor6_SensorUltraviolet 	     "Multisensor6 ltraviolet Sensor [%.0f %%]"   			<Temperature>   			{channel="zwave:serial_zstick:controller:node5:sensor_ultraviolet"} 
Number      ZWaveNode5ZW100MultiSensor6_SensorTemperature 	     "Multisensor6 Temperatur Sensor [%.1f °C]"   			<cu_heating>  	(Temperatur)	{channel="zwave:serial_zstick:controller:node5:sensor_temperature"} 
Number      ZWaveNode5ZW100MultiSensor6_SensorLuminance 	     "Multisensor6 Lumiance Sensor [%.0f Lux]"   			<Light>      	(gLumiance)	{channel="zwave:serial_zstick:controller:node5:sensor_luminance"} 
Switch      ZWaveNode5ZW100MultiSensor6_TamperAlarm 	         "Multisensor6 Tamper Alarm Sensor [%s]"  				<switch>        	   		 {channel="zwave:serial_zstick:controller:node5:alarm_tamper"}
Number      ZWaveNode5ZW100MultiSensor6_BatteryLevel             "Multisensor6 Battery Level [%.0f %%]"                 <Battery>        (BatteriLevel)  {channel="zwave:serial_zstick:controller:node5:battery-level"} 

It works fine???
If I change the item to “zwave:serial_zstick:controller” it no longer works.

I tried remove the device and rescan it again. But the devices are still found at “zwave:device:controller”.
How is that possible?

I´m pretty sure this happened somewhere between not having the serial driver installed, and having the serial driver installed, while changing controller from a thing file to PaperUI… I just cant get the things defintion to be the same… I have cleared cache and tmp about a zillion times… It doesnt change anything.

Btw… Using openhab 2.5M1 and the latest z-wave binding (1-2 days old). Serial driver got installed, when I installed the Zigbee binding from PaperUI, (again).

Pretty normal. I have never seen it in another way :sunglasses:
grafik

Hmm… strange… I have never actually noticed this before cause I used to have the controller configured from PaperUI. And then the controller and the devices are the same, But when I used the things file and rename the controller… they´re not equal any more… But it still works…
Thats odd.

That is how I do it too: result in the screenshot :grinning:

I may have to start all over again… Things doesnt seem to work (again)… And I think it´s due to using the things file. All devices stopped responding around midnight… I can´t recall doing anything, other than changing the channels definition… I´ll go back to use PaperUI for the controller, and then remove all devices and rescan them… Hopefully it should work then.

What time is your daily heal? I have my heal turned off to prevent all of the command Channels for my zwave devices from becoming unresponsive once a day and requiring an OH restart to clear the hung threads. Meter and alarm data still come in, so motion sensors report, but lights, switches, etc. do not turn on after receiving a command. Like Rx works but Tx is stuck. TMK, nobody else has reported this, so it will be very interesting if the same is happening for you.

It´s sat to default 02.00 AM… I havn´t given it any thoughts that it might be the cause of the problem :thinking:

Which openHAB version?
If I find the time I could set up a test system and install the same version.
I’m still on #1549 where everything works fine :sunglasses:

I’d suggest disabling the nightly heal, then restart openHAB to clear out any stuck initialization/heal threads. Once these threads get stuck, polling no longer works (i.e. the device stays in initialization until the next openHAB restart). I see this more with battery devices than with mains devices, but it happens with both. Since disabling the nightly heal several weeks ago, my network has been much more stable.

I’m currently on S1615 with a patched openhab-core to work around the high load issue, but as noted in the PR, this was happening in S1602. I haven’t made time to run the heal while using the patch to see if it may have helped. With the patch, OH is running better than it has in quite a while, e.g. my zwave startup lagginess only lasts 5-10 minutes, if that!

Unfortunatly other stuff is broken in the latest builds, (google cloud). So I´m staying with the 2.5M1 release.
I´ll switch off the healing later tonight to see if this change anything.

This all drives me crazy by now. Any answer given on any question in this forum will be some kind of useless with recent snapshot versions … :joy:

1 Like

Yeah, I hear you! In some respects this feels a bit like the early days of version 2. The good news is that I think we’re close to having a fix for the high load issue. I just have some more performance testing to do.

It’s really important right now to log issues when we run into problems. So much was changed in the last few months that there’s undoubtedly going to me more problems discovered as the recent snapshots get more usage.

3 Likes

Agree… Atm things are not the best it can be…

1 Like