Its not a browser issue as it worked prior to going to 2.4 stable. It shows nothing. Not a thing
Please provide an image of what the browser shows. If there really is nothing at all, and the thing properties are showing neighbors, then it seems like itās a browser issue.
What are you seeing in the logs? You should confirm that there is, or isnāt, any data being received for starters.
Hi Chris
Ive used the same browser for over 5 years, no recent updates at all have been made to the version im aware off. I use Firefox
See the image:
The binding does not generate these graphs - this is done 100% in the browser.
Please check the browser console to see if there are any errors. I donāt think this is a binding issue as you told me that there are neighbors showing in the properties. Given that the graph is completely blank, I think there must be a browser issue.
Even if there were no neighbors, I think you would still get a graph showing all the nodes, but with no lines connecting them.
Hi Chris
Both Chrome and Firefox display the same, nothing. Its an OH2 issue, perhaps not a binding issue but definitely OH2 as its the only thing thats changed. The console shows no errors
Ok, maybe you know this better than me .
OH2 doesnāt really have anything to do with this unless itās not serving up the files to HABmin, in which case there would be a browser error. You say there are no browser errors in the browser console, so we can assume the files are all being downloaded ok.
The binding only provides the neighbor properties - you say that the neighbor properties are showing ok, so itās not a problem with the binding.
If the browser (ie HABmin) was working ok, it would show a graph of the nodes - it doesnāt. To me, it all points at a problem on the browser side.
Unfortunately, I donāt think I can be of further help unless you have more information?
Typically I use Firefox, but using the Console in Chrome this is the only thing I see in terms of errors upon a refresh of the page, Iām unsure if this is related.
Ok, so when I asked if there were any errors in the browser console - I guess the right answer was āyesā
This is definitely related, and is why itās not working. Do you have more than 1 controller? If so, the it seems the viewer doesnāt like this.
Hi Chris, my bad!! seems there are errors in Chrome, not Firefox. Odd!
Yes, I have a second controller connected (with no devices as yet)
Is it typical to have the Map not work with two controllers or is that supposed to work?
Itās the first time Iāve come across this - not many people have multiple controllers and no-one has mentioned it. However clearly this is the problem.
Damn. Is it something you can look into or given its not generated by the binding, no?
I will see if there is something I can do easily or not - itās been a long time since I looked at that code so I donāt really remember it well. The question will be if the browser can easily work out what network each node is on so that it can be split.
Data is only received in the logs when some action is initiated by a UI or the App, or a script etc. If it is a manual action on the device, such as on/off, then nothing is received in the logs, neither is a state change, such as temperature or humidity registered in the logs.
To be clear (sorry) - the log is in debug mode? If thereās nothing received, and the log is in debug, then the problem is with the configuration of the device. Normally I would suggest the associations as the place to look, but I think you already said these were ok, and you are running the latest binding which ought to enforce the associations if you have the controller set to master in the controller configuration (??).
Hi,
I have had an issue when upgrading to openhab 2.4 this weekend. My HS1DS-Z ZWAVE sensors (https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/551) no longer update the alarm_access channel to ON when the sensor_door channel is updated (OPEN/CLOSED)
This normally wouldnāt be a problem, as I should be able to just use sensor_door, however these devices have a bug. When they report other channels e.g. the battery level (I think as a result of polling, not sure) they send sensor_door as CLOSED even when itās still OPEN.
I therefore setup a proxy item and populate it via a rule only when alarm_access is fired (alarm_access isnāt fired when it returns the battery level, etc.) and populate it with the value of sensor_door. This has been working fine in 2.3.
I think the issue lies with this in the log:
2018-12-31 16:08:53.243 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 29: Alarm converter NOTIFICATION event is 3, channel alarm_access is not implemented.
Logs (inc. discovery) at https://pastebin.com/uYP9hZB3 - I also attached the channel updates generated in 2.3.
Is there something I can do to get the alarm_access channel updated? Iāve currently rolled back to 2.3.
Yep, logs are in debug mode, the controller is set to master, and the zwave bundle is version: 2.5.0.201812302011 on OH 2.4.0 Stable.
I just checked my associations and theyād disappeared! So, Iāve reset them all back to lifeline=controller, and it appears Iām getting data. Just to confirm if the settings stick through a restart, I restarted the OH instance and rechecked the associations and they seem fine for now, so Iāll keep an eye on these over the next few days.
Just one thing I noticed when I clicked on the zstick controller configuration in habmin, the following appears in the DEBUG log, not sure if itās significant to anything:
00:01:40.216 [DEBUG] [ng.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:fb129a71
It looks like this is the tamper alarm report. The database will need to be updated to resolve these reports - I guess it also supports the door report, so I will update both channels.
Are you able to provide a log showing the door sensor opening/closing? Or is the log you provided showing this, and the sensor is reporting incorrectly that itās the tamper alarm? Does it have a tamper alarm, and if so, what is shown when you trigger that?
Please provide a log showing the period between when you know the associations were set, and when they are no longer set.
This may (likely) just be an issue with the UI, but I would like to check.
This is fine - there is no bridge for the controller as the controller is the bridge.