I believe that the issue here is associated with this bug in ESH. When the binding starts, it discovers the nodes, and it looks in the XML files to see if it can find the information for the node - if it can, it adds it as the named node, if it can’t, then it adds the unknown node. The problem is that I don’t have direct access to the XML files - they are read by ESH, and I access them through an API, and it seems that sometimes, they aren’t being read before the binding needs them.
I’m not sure how to work around this at the moment. I might be able to find a bodge that solves it but I don’t want to spend a lot of time trying to work-around this when I think it should be fixed in the core.
So, I suggest you ignore this for now and leave the unknown ones in the inbox until we have a solution for this. Unfortunately, this is likely to get worse before it gets better as the number of database entries grows .
I don’t disagree, but at the moment I haven’t worked out how to add this. I want to try and work within the existing APIs as much as possible, and presently I don’t think there’s a good API for providing this information to a UI.
You should however be able to see the state by moving your mouse over the online icon for each thing (ie the green tick). If it’s not fully operating (ie still initialising) then there will be a popup. showing the initialisation stage.
I will add some more debug in the initialisation today so we can have a better look at this tomorrow…
EDIT1: Is there any warnings about this sort of thing when the binding starts?
EDIT2: When does this warning happen - when an sensor update is received, or a command sent (I assume state change from the sensor)?
I have concluded that the Network View doesn’t work as intended in my setup. Not sure why. But I think that although it seemed to work initially, it never really did.
The network can’t be “this good”, and secondly it never changes. Even dead nodes are not red.
But I’m not sure this is really the fault of the network view - even the “Things list” in PaperUI does not properly show node status (e.g. dead nodes are not red, but some nodes that are still in “Deferred” are red).
This morning I updated everything. Maybe there’s something in the mapdb that is broken.
Is there a proper way of restarting zwave, or selected nodes from scratch? Maybe a tool to edit mapdb?
I can of course wipe everything and start all over again, but it takes quite some time to get back. Especially I hate Hue and Sonos configurations.
The warning happens if state change come from the sensor - 2 days before it works perfectly.
Is there a good way to filter the Z-Wave Logs with HABmin and OH2?, in OH1 i used the loopback function especially for the tons of Z-Wave messages:wink:
EDIT: Very strange, after restarting and looking into the log it works:
11:00:15.351 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_fibaro_fgms001_00_000_f1ab5187_node10_sensor_binary changed from NULL to ON
11:00:45.438 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_fibaro_fgms001_00_000_f1ab5187_node10_sensor_binary changed from ON to OFF
Maybe that is the problems with reading the XMLs, when OH2 starts?
Possible, but the properties that are used to define the channels are not stored in the XML - well, they are, but once the thing is added from the inbox, it uses data stored in the mapdb, and doesn’t re-read the XML.
I’m not too familiar with logging in OH2 - you can use the Karaf console and the log:set command to change logging levels for different bindings, and it also allows filtering of recent log entries, and displaying exceptions - it’s quite useful, but it will only give the logs for the past few minutes I think.
Same for me, i learned a lot about Karaf in the last 2 weeks, but not enough. But i still miss the old options in HABmin to filter the log on nodes with problems.
Coming back to my problem with “No converter set for zwave:*” - it happens sometimes for my 3 sensors and sometimes not, always on motion detected:
11:33:36.121 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: No converter set for zwave:aeon_dsb05_00_000:f1ab5187:node2:sensor_binary
11:47:01.769 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: No converter set for zwave:devolo_mt02648_00_000:f1ab5187:node13:alarm_general
12:17:19.421 [WARN ] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: No converter set for zwave:fibaro_fgms001_00_000:f1ab5187:node10:sensor_binary
Sometimes when i restart OH2 it works, sometimes not
EDIT: restarting OH2 it works again: 12:38:56.841 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_fibaro_fgms001_00_000_f1ab5187_node10_sensor_binary changed from NULL to ON
Do you mean the Z-Wave log viewer? If so, that’s still there. Or do you just mean the list of nodes with the ‘green dot’?
Just to be clear - without restarting OH, does it always either work, or not work, for a node? Or sometimes it works, and sometimes not - even without restarting the binding?
Just now I realized that you where not talking about the network view, but maybe the ‘Thing Configuration’ list in HABmin?
Well, I don’t get any such popup here, I have tried both Chromium and Firefox.
I have now flushed the old installation, to see if I have better success starting from (almost) scratch again. I have only saved /conf folder. Half of the zwave nodes are still marked ‘Red’ in the ‘Thing Configuration’ list in HABmin even though they are online, and working (e.g. I can dim the light from UI).
I’m guessing this is the same reason behind this, as the Network View in Tools also does not work correctly(?).
ah, thanks. That’s much more readable than when I set the root level to debug.
There’s a trash can icon in PaperUI, but before hitting that, I went to HABmin, and now things are weird again – my Items using the zwave switch are there, but the Thing is not – only the controller is listed under Thing Configuration. If I click “+”, in the Add New Thing Wizard, there are no types listed to select from in step 2. But at any rate, since the thing is configured and working in Paper, it should already be in HABmin, right?
Well, since I have quite some nodes, I try not too restart too often, since I also want oh to pick up the new (late battery-) nodes. But yes, I am hitting F5 in the browser frequently.
… restarting oh now again … nodes shows online!
But this to me means that I need to restart oh every time I want to know the actual status of a particular node, which I guess is not how it is intended to be. This is what I have been seeing all along - the nodes status is unreliable where ever I look at it (Paper/HABmin), apart from debug log.
That’s quite possible - items are independant of the things and I’m not sure if items get deleted when a thing is deleted. Also, if you a changing back and forward between paper ui and HABmin, and stopping and starting the server, this might cause problems and you should refresh the browser. HABmin works by receiving notifications from ESH when something changes - it doesn’t continually poll the state. So, if you restart OH, then it will likely have a different view of the world.
Yes - they both should be displaying the same information coming from the server. But as above, HABmin is using notifications to keep up to date where I think PaperUI might poll more often.
Well, I’m not sure why you think this. All I said was to refresh the browser if you restart OH - not to restart OH each time you refresh the browser .
If the node is not completely initialised, then you should be able to get a tooltip in the thing list. If a node is offline, then you can’t send commands to it as this is prevented by ESH (the commands aren’t even sent to the binding I think). If you see something different, then I’m not sure why.
As I said above, if you restart OH, then you should also refresh the browser so that the UI updates the state as it might otherwise loose track.
Yes i mean the log viewer - is there a way to use it with OH2?
Sometimes if i start OH2 and the binding it works. Sometimes i don’t works. Maybe it depends from “OH2-Session” to “OH2-Seesion”. So i thing there could be a timing or order problem.
Yes, I think so, but my question was if in a single “session” (ie without restarting the server) does it sometimes work, and sometimes not? Or does it ALWAYS work, or ALWAYS not work?[quote=“Heiko_Fanieng, post:577, topic:7522”]
I don’t get any such popup here
[/quote]
This is only displayed if the thing is in the initialisation phase. If it’s completely initialised, this won’t show up…
No, you misunderstand me, I need to restart oh in order to get a true online status. It does not matter how many time I hit F5 or ctrl-F5 in the browser. Only a restart does the job. Like I said, this is how it has been all the time for me. Restarting oh does the job, but there’s some issue with the sonos binding that makes stopping oh taking a couple of minutes (some internal timeout or exception in upnp), that I don’t restart oh as often as I used to, and it also makes slow nodes to disappear again. So the only way for me to know node status, is to eyeball scan the debug log, and enter data in a separate spreadsheet.
I don’t know why it is this way, but it is. And starting from scratch obviously did not fix anything related to this.
That’s even more confusing to me. If you restart, then the node will be set to offline in ESH, and then go to online almost immediately. I’m clearly not understanding the issue at all - sorry.
The issue is that I am unable to trust the node status, be it in Network view or things list.
Network view did not for a week update until I did a reinstall this morning, and things list had the newly nodes marked red, even while working.
I’m sorry that I am unable to explain this any better.
.
. Unfortunately, I can’t answer…
