…
Thats when i was messing with it after it woke me up; it happens at 2:20ish every morning This morning it actually didn’t wake me up and i noticed it at 2:50ish, than in my sleepiness, i opened the app and jammed on the switch button and dimmer slider a few times in frustration
In that case there is nothing showing in the log, so it doesn’t seem to be the binding that is turning the device on. There appears to be no commands to this device at 2:20 - there’s some heal function at 2:14, and more at 2:29 - none of which should impact the light state.
I noticed in Zniffer that on start I see node 1 trying to talk to node 1. I have not dug far but I am amazed it is even possible and as it is start it fails a few times and issue goes away. I notice odd things in this log with node 1 also. Is this possible from the binding? I was thinking a z-wave issue as I have never seen the binding do this.
Where is the sniffer log published please? I really can’t see how this can be related at all, but I can’t see the log at the moment so it’s hard to comment.
Not sure how it could be either and understand you are very busy so as it was causing no issue had not posted. What do you think about how node 1 neighbour update is in this log though?
Well leaving aside that this network is not happy.
I don’t see anything wrong, but obviously the controller is not happy about something as it fails. Again though, I don’t think it’s related to this issue though as there doesn’t seem to be any command being sent.
OK if that is how node 1 is supposed to be treated. Agreed not related. Hope move goes well and thanks for all hard work. Will dig out a zniffer for you but don’t make it a priority as it is only issue on start and it just fails a few times to NOP node 1 from node 1.
OK. Do not think this is a binding issue but your network is not behaving well. To get things simpler suggest reduce polling and turn heel off so log is cleaner so we might see the issue. Just now a lot of noise in there and it is impossible to see what might cause a dimmer to turn on. Certainly no command from the binding at that time.
As far as I know anyway 
Thanks - it’s been a challenge with the state of the world at the moment 
Ok, so when you referred to the sniffer log - it’s not from this issue, but something you’ve seen? Ok, we can worry about that elsewhere then
1 Like
I don’t want to tangent here, but now I’m a bit worried about my controller LOL. It’s been setup for two months now and working fine; all 40ish nodes on the network; save for this one bulb that just started acting weird last weekend. What, if anything do i need to do about my controller?
There are so many failures in the log it is hard to know what is going wrong.
All I can suggest is minimise the traffic bit by bit to identify what is causing the failures. Some nodes can be terrible spammers and sit and send messages constantly and this might be what is happening but you will not necessarily see this in the log as it is not initiated by the controller or the binding.
There are also some types of nodes from well known manufacturers that have known poor behaviour when certain parameter are set.
The best way to solve these issues is always to make yourself a zniffer. This is just a controller with a special firmware that you plug into a machine that can run a windows application. The application shows all of the network traffic not just what the binding sends and recieves. A UZB3 which are about €25 from mouser are suitable to make a zniffer and there are guides how to do it online.
Turned off network heal last night; light did not come on.
The other thing i tried previously was to heal that node and it didn’t turn on.
So turning off network heal last night i figured wouldn’t work; but it did.
Now im even more stumped? Could a heal on a “different” device cause the other device to turn on?
I’m wondering if something is causing the device to reset, and hence turn on. From the logs, the binding itself if not sending the ON command, and it’s probably unlikely other devices are, so maybe the device is doing a reset - possibly due to a bug, or something it receives during the heal that it’s unhappy with, or maybe it gets overloaded and a watchdog triggers…
Just speculating really as it’s hard to put a finger on any of these things and even a sniffer log may not help.
1 Like
Yeah i agree; its definitely not a command; i only have one rule and that is not getting triggered. I speculate maybe the power flicker damaged it somehow. I have a new one that should arrive this weekend so I’m going to replace it and try that out.
1 Like
Rich Smith & Bob Eckhoff and other fellow members,
There is NO solution to this erroneous nightime behaviour of this bulb turning on! The ONLY solution is to turn OFF your nightime heal.
Basically this bulb has an intrinsic hardware flaw which which makes it misbehave under network heals. Nobody can seem to pin it down though.
I had the equivalent (alternate branding) of this bulb many years ago with my VERA PLUS system and suffered the very same problems and frustration… light turning on in the middle of the night…nothing showing in logs etc etc. The VERA forums were filled with a similar discussion to this openhab one now. Turning OFF nightime heal was the only answer.
The VERA community and the bulb manufacturers had no solution to offer! I dumped this bulb eventually! You shouldn’t HAVE to turn off your nightime heal for the case of a rogue device!
I absolutely recommend you all cease wasting your time excluding/including/resetting/deleting and that whole merry dance and ditch these bulbs and go for a normal LED bulb with a z wave dimmer/switch fitted behind your wall switch. Don’t buy anymore of those LB60z1 bulbs!
regards,
Denis
2 Likes
So you are saying the solution is to replace the bulb with a different product.
1 Like
Hi Bruce,
Absolutely AVOID these bulbs! They have some internal flaw/bug. No amount of merry dancing will solve it. You’ll just drive yourselves crazy digging a deeper hole. Now some users may say they have used them without issues but the statistics will eventually catch up and you’ll have problems.
I have also experimented with ‘DOMOTICZ’ and also another French opensource system called ‘JEEDOM’ and found the same problems arising with this bulb. It’s clearly NOT solely an openHAB problem.
ps. another serious criticism of these bulbs is that you have to wire your wall switch so that the bulb is LIVE at ALL times (to keep its internal zwave radio going). You cannot switch off/isolate your bulb (for changing or other repairs say…) just with the wall switch and would have have shut off the circuit breaker for the whole zone. This is poor practice from a safety and instrumentation perspective.
regards,
Denis
I have about 8 of these(for the past 4 years); this is the first time one has failed like this. I use them in lamps, wall sconces, ceiling lights.
Hi Rich,
Well you’ve been lucky so far I guess but I suspect others in your system may start to act up eventually. The issue appears randomly out of the blue and never goes away.
Look at the facts: the vast VERA community flagged the same issues with users over the years. The manufacturers seem to tacitly accept users may have issues. I also had problems on those other opensource systems I mentioned earlier so one is chasing rainbows trying to find the flaw with openHAB.
Apart from the poor safety issues I referred to, I would migrate to reliable Fibaro or Qubino dimmers & switches and install them in your wall switches. Long term, you’ll reap the reliability payback.
regards,