Yes, that’s correct. I will look to merge this soon.
1 Like
today I upgraded to 2.3 stable release. now I want to troubleshoot my errors which I thought that it was because I was running oh2.2 with the zwave 2.3 security snapshot binding. but it seems not.
first (new) error after upgading to 2.3 (not sure if its regarding zwave): to all my nodes I get an info loggin
2018-05-28 20:13:08.830 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 2: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 3: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 4: Node found
2018-05-28 20:13:08.831 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 5: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 6: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 7: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 8: Node found
2018-05-28 20:13:08.832 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 9: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 10: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 11: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 12: Node found
2018-05-28 20:13:08.833 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 13: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 14: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 16: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 17: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 19: Node found
2018-05-28 20:13:08.834 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 20: Node found
2018-05-28 20:13:08.835 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 21: Node found
2018-05-28 20:13:08.835 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 22: Node found
2018-05-28 20:13:08.835 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 23: Node found
2018-05-28 20:13:08.836 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 24: Node found
2018-05-28 20:13:08.836 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 25: Node found
2018-05-28 20:13:08.837 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 29: Node found
but all nodes are working, also showing as online.
coming now to the error logging:
2018-05-28 20:13:19.381 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 8: AssignSucReturnRoute command failed.
2018-05-28 20:13:19.385 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 6: AssignSucReturnRoute command failed.
on some nodes this message appear. on oh2.2 the error message looked like this
2018-05-28 19:57:12.182 [ERROR] [age.AssignSucReturnRouteMessageClass] - NODE 19: Assign SUC return routes failed.
I think that could be a reason why I’m running into some problems with my fibaro switchs (and association groups), that the current state of the switch sometimes doesnt get reported back correct. sometimes I need to reconfigure on my switch the association group (although it was already defined correct). Also in habmin the lifeline group was on 90% of switch empty after saving the openhab controller into it and refreshing habmin (never understood this).
any idea?
This is not an error. It’s just saying that the node is found.
Yes - that’s what the log says - they are found ok.
I will reduce these messages to debug so that they are removed from normal logging.
Why do you think it’s related? Personally, I doubt it, but maybe I’m wrong. This “error” is the failure to set the SUC return route, but it is VERY unlikely to cause any problem unless you have multiple controllers in your network?
Do you mean Fibaro Single/Double Switch 2 (ie FGS-213/FGS-223) or Fibaro Relay Switch (ie FGS-212/FGS-222)? And were they first included using the development binding?
Thanks,
Steve.
oh man… thats embarrassing :S I dont know why… I read “Node not found” in the log file… maybe it was regarding my evening beer 
I’m sorry …
regarding suc return route log:
I dont have any rational explaination why I thought that. I dont even now what suc and sis is. It’s just, because I had a problem with zwave states and there are error messages with terms like suc (which seems to be sth controller relevant) and return route. But after your statement I dont believe anymore.
I’m using and talking about Fibaro Doubleswitch. That is a good question with what zwave binding I included them! I dont really remember 
Explanation:
1 Like
I’ve created a new TEST binding here. This has some changes that might cause problems as I’ve made some mods to change the way dead nodes are handled and messing with the low level transaction code is always a little dangerous.
If you’re feeling adventurous, then please feel free to give it a go and report back 
. This is one of the last major changes I want to make before I can merge the dev binding into master so it would be good to iron out any issues…
1 Like
testing now
quick question: Is the Bridge name editable?
I see zwave:serial_zstick:512 but I can’t change the 512 part.
If I remember well, I was able to specify the bridge name (I have all my items linked to channel names)
Maybe I am doing something wrong 
OH 2.4 S1292
You can set it on startup, but I’m not sure you can go around changing it (I think it’s meant to be immutable). This isn’t anything to do with the binding though - it’s up to the core…
Correct. Maybe something changed in OH 2.4 core… If I remember well, I was able to modify that part. Anyway… no worries…
Continuing the tests now
I did a quick test and half of my devices, even mains powered, were reported as dead. Had to roll back due to house guests, but will test more (and get some logs) over the weekend.
Quick question: does the latest 2.3 version (from the top of this thread) work with 2.4 snapshot?
In other words is it safe to upgrade to OH 2.4?
I mean are there any breaking changes in 2.4 core? I did upgrade to 2.4, but zwave did not resolve due to missing guava dependencies. I know there was a plan to remove guava from OH, so maybe this happened in 2.4?
Yes.
Remember - all that is changed is the number… Last week it was numbered 2.3, now it’s numbered 2.4. It’s still basically the same thing…
Really - I’ve not seen that issue. ZWave doesn’t use guava so I don’t know why this would have been the case . There were some other missing dependencies relating to UoM and USB, but that was due to new features and these are in 2.4 anyway.
That’s what I thought.
It has been mentioned in this thread too. But it wasn’t an issue with the binding itself, it was enough to just reinstall it. I will do that today, yesterday it was really late, so I just gave up. Now that you confirmed it should work, I will try to reinstall the binding, hopefully all the issues will gone. 
I think that was a change of ESH - they changed a definition of a protected field from static (from memory) and that made it binary incompatible, so needed to be reinstalled. At least that wasn’t guava related, but maybe there was something else that I didn’t know about… If I search this thread for guava, there is basically nothing other than our mails this morning (and one message from 12 months ago which is I think unrelated).
I think it’s ok in any case 
.
Search for com.google.common.collect, this is what I meant. I assume this package is part of guava library…
Again, this is all from a LONG time ago - well before 2.2 was released, let alone 2.3…
That’s true, but this is what got yesterday. Strange, but true… 
Tested today with openHAB build #1292 (2.4 snapshot).
All devices are online and seem to work properly.
Debug log provided through website ticket.
It still is possible to modify it. It am running OH 2.4 1292 and named it.