ZWave message duplication on RPi

[cdjackson]

Messages from the zwave controller are duplicated on the RPi.

See https://groups.google.com/d/msg/openhab/_Wh_iurrIIo/6QH5gLimgNEJ

For example, right at the beginning of the log, we send out this request -:

2014-04-13 20:13:44 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:763]- Sending Message = 01 03 00 07 FB 

This is the only time that this request is sent, but the response comes in 4 times

2014-04-13 20:13:44 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:913]- Receive Message = 01 2B 01 07 … 
2014-04-13 20:13:46 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:913]- Receive Message = 01 2B 01 07 … 
2014-04-13 20:13:49 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:913]- Receive Message = 01 2B 01 07 … 
2014-04-13 20:13:50 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:913]- Receive Message = 01 2B 01 07 … 

The problem gets worse as I think there’s a cascade effect. The response to the initial request would normally cause the subsequent message to be queued, but because the initial message gets 4 responses, the next message gets requested 4 times - and I think each on of these 4 requests gets 4 responses and by the time we get to the MessageSerialApiGetInitData, we have 30 or so responses….

[cdjackson]

It would be worth testing the latest - it should be largely the same as the last one you tested, but it would be good to get a log with this and confirm that you only have the repeated frame during the initialisation of the sensor.

[tudstudent]

I will have the server run for 30 mins, after that I will send the trace. But as can be seen underneath it is not working as expected I think (unlesss initialisation takes way longer). Later today I will test again in my core i5 windows to see if it is behaving the same.

Launching the openHAB runtime...
osgi> 2014-12-26 04:38:43.611 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.7.0).
2014-12-26 04:39:18.969 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2014-12-26 04:39:20.441 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.
2014-12-26 04:39:36.158 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'switchrelay.items'
2014-12-26 04:39:43.152 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'multisensor.items'
2014-12-26 04:39:43.735 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'networktime.items'
2014-12-26 04:40:09.492 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'motion.sitemap'
2014-12-26 04:40:36.351 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest
2014-12-26 04:40:43.030 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /openhab.app
2014-12-26 04:41:08.588 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'motion.rules'
2014-12-26 04:41:20.925 [INFO ] [.o.io.habmin.HABminApplication] - Started HABmin REST API at /services/habmin
2014-12-26 04:41:26.633 [INFO ] [.service.AbstractActiveService] - NTP Refresh Service has been started
2014-12-26 04:41:27.650 [INFO ] [.service.AbstractActiveService] - ZWave Refresh Service has been started
2014-12-26 04:41:27.794 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:41:27
2014-12-26 04:42:05.104 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:42:14.156 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 752
2014-12-26 04:42:14.205 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:42:14.227 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 23
2014-12-26 04:42:27.672 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:42:27
2014-12-26 04:43:00.474 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:43:00.480 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:43:06.695 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:43:07.008 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:43:07.275 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 726
2014-12-26 04:43:07.711 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:43:07.775 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:43:07.780 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:43:08.076 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 23
2014-12-26 04:43:27.870 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:43:27
2014-12-26 04:44:04.485 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:44:04.932 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 699
2014-12-26 04:44:05.491 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:44:05.495 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:44:05.533 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:44:05.817 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 23.1
2014-12-26 04:44:28.006 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:44:28
2014-12-26 04:44:46.346 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:44:47.031 [INFO ] [runtime.busevents             ] - switch_fibaro_02 state updated to ON
2014-12-26 04:45:04.457 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:45:04.805 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 727
2014-12-26 04:45:05.306 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:45:05.347 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:45:05.350 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:45:05.724 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 22.9
2014-12-26 04:45:28.165 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:45:28
2014-12-26 04:46:04.462 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:46:04.822 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 707
2014-12-26 04:46:05.251 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:46:05.442 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:46:05.460 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:46:05.708 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 23
2014-12-26 04:46:28.340 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:46:28
2014-12-26 04:47:04.451 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:47:06.837 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 687
2014-12-26 04:47:07.295 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 687
2014-12-26 04:47:07.370 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:47:07.374 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:47:07.696 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:47:07.700 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:47:07.781 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:47:08.035 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 22.8
2014-12-26 04:47:28.501 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:47:28
2014-12-26 04:48:04.468 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:48:04.784 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 689
2014-12-26 04:48:05.201 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:48:05.278 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:48:05.283 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:48:05.625 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 22.9
2014-12-26 04:48:18.560 [INFO ] [runtime.busevents             ] - switch_fibaro_02 state updated to OFF
2014-12-26 04:48:18.569 [INFO ] [runtime.busevents             ] - switch_fibaro_02 received command OFF
2014-12-26 04:48:28.655 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:48:28
2014-12-26 04:49:04.478 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:49:04.721 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 764
2014-12-26 04:49:05.093 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:49:05.098 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:49:05.114 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:49:05.371 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 23
2014-12-26 04:49:28.840 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:49:28
2014-12-26 04:50:04.487 [INFO ] [runtime.busevents             ] - sensor_1_battery state updated to 100
2014-12-26 04:50:06.420 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 764
2014-12-26 04:50:06.731 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:50:06.735 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:50:08.675 [INFO ] [runtime.busevents             ] - sensor_1_luminance state updated to 764
2014-12-26 04:50:08.970 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:50:08.981 [INFO ] [runtime.busevents             ] - switch_fibaro_01 received command OFF
2014-12-26 04:50:08.986 [INFO ] [runtime.busevents             ] - switch_fibaro_01 state updated to OFF
2014-12-26 04:50:09.253 [INFO ] [runtime.busevents             ] - sensor_1_humidity state updated to 36
2014-12-26 04:50:09.458 [INFO ] [runtime.busevents             ] - sensor_1_temp state updated to 23
2014-12-26 04:50:29.001 [INFO ] [runtime.busevents             ] - network_datetime state updated to 2014-12-26T04:50:28

[cdjackson]

I’m not sure how to interpret the event log - you obviously know what events you’re expecting to see on your system, but I don’t so I really need to see the debug log..

[tudstudent]

I am aware, I will send in a couple of minutes. But I am now looking in my habmin config and what I do not understand is the green and gray dots/balls in bindings.

Node 1 - Aeon Stick - gray Node 2 - Aeon Multi - gray Node 3 - Fibaro - Green

Shouldn't they all be green?

[tudstudent]

Furthermore, just to check (to avoid it is my own fault):

Group   Motion
Number  sensor_1_temp   "Outside temperature: [%.1f °C]"        <temperature>   (Motion)                { zwave="2:command=sensor_multilevel,sensor_type=1" }
Number  sensor_1_humidity       "Relative humidity: [%.0f %%]"  <bluetooth>     (Motion)                { zwave="2:command=sensor_multilevel,sensor_type=5" }
Number  sensor_1_luminance      "Luminance: [%.0f Lux]" <sun>   (Motion)                { zwave="2:command=sensor_multilevel,sensor_type=3" }
Contact sensor_1_motion "Motion [MAP(motion.map):%s]"   <contact>       (Motion)                { zwave="2:command=sensor_binary,respond_to_basic=true" }
Number  sensor_1_battery        "Battery 4-in-1 [%.0f %%]"      <energy>        (Motion)                { zwave="2:command=battery" }

[cdjackson]

Shouldn't they all be green?

Green means it’s finished initialisation and working ok Grey means it’s still in the initialisation phase Orange means it’s working, but maybe not well (high retry rate) Red is dead

[petrklus]

With a risk of sounding redundant, I would like to add that the orange can also mean that it was marked dead in the last 24h (for whatever reason). Is that still correct Chris?

On Tue, Feb 10, 2015 at 4:19 PM, Chris Jackson notifications@github.com wrote:

Shouldn't they all be green?

Green means it’s finished initialisation and working ok Grey means it’s still in the initialisation phase Orange means it’s working, but maybe not well (high retry rate) Red is dead

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/1564#issuecomment-73716451.

[cdjackson]

With a risk of sounding redundant, I would like to add that the orange can also mean that it was marked dead in the last 24h (for whatever reason). Is that still correct Chris?

Yes - that’s also correct (sorry - I was going for the short answer :) )

[tudstudent]

Just checked again and this is what I noticed:

1. When starting openhab and opening of HABmin during initialization you get a lot of duplicates. However would it not be possible to state in the event log that initialization starts and when it ends? So it is clear not to expect "trustfull" data in this initialisation period!
2. Aeon Z-Stick has always a gray color in HABmin (other items are green now). Is this normal?

In my last log send to you Chris, can it be that when openhab gets "stressed" it also loops and displays values twice?

[cdjackson]

1. When starting openhab and opening of HABmin during initialization you get a lot of duplicates. However would it not be possible to state in the event log that initialization starts and when it ends? So it is clear not to expect "trustfull" data in this initialisation period!

What would you do wit this information? Is it just for ‘debug’ purposes so you can see what’s happening? From what I’ve seen there wasn’t any duplication as such - there were packets being sent twice in some cases, but this was generally (I think) because they are being requested twice - at least some of this might be caused by he CAN errors which still persist in your logs.

1. Aeon Z-Stick has always a gray color in HABmin (other items are green now). Is this normal?

No - the Aeon should be green - mine is. Looking at yours, it’s not reporting a specific device class (!!) so this means one of the checks in the code fail… I’ll change this to use the generic device class and we’ll see if that works better...

In my last log send to you Chris, can it be that when openhab gets "stressed" it also loops and displays values twice?

Anything is possible….

I think there is still a protocol violation - I’m still seeing CAN errors in your system so I need to take another look at this as in my mind this is the route of all evil (for now)!

[tudstudent]

Good, just ping me when you have a new test version (concerning the green).

Concerning the CAN errors: you do not have a Pi yourself?

Concerning dupplication, I am looking at the terminal output and there I see the duplicate lines, but it makes sense indeed that these are requested because of an error (CAN?!?) so could be related to previous sentence. Hope you figure it out, coz till now I love the flexibility of openHAB (and support!).

[cdjackson]

Good, just ping me when you have a new test version (concerning the green).

Will do - I’ll certainly post a version later this evening and I’ve already made this change.

Concerning the CAN errors: you do not have a Pi yourself?

Hard to believe I know, but nope :)

[petrklus]

Is there a donation button anywhere to send you one? ;)

On Tue, Feb 10, 2015 at 6:37 PM, Chris Jackson notifications@github.com wrote:

Good, just ping me when you have a new test version (concerning the green).

Will do - I’ll certainly post a version later this evening and I’ve already made this change.

Concerning the CAN errors: you do not have a Pi yourself?

Hard to believe I know, but nope :)

— Reply to this email directly or view it on GitHub https://github.com/openhab/openhab/issues/1564#issuecomment-73744753.

[cdjackson]

Sorry - I meant to say I updated with a change to the controller detection… Let me know if the controller goes green...

[cdjackson]

Is there a donation button anywhere to send you one? ;)

To be honest I’m not sure if it would help. It doesn’t seem to be as universal a problem as it was earlier - some files seem to show signs of problems, while others look largely ok… Maybe the new RPi2 will be better - if not, I might be tempted to get one to debug further...

[tudstudent]

Well, new Pi is nice, but majority will have a pi 1. Furthermore, do you say there are still some bugs in the general code which occur at Pi, or is it Pi specific, or randomly. I am testing the change now and it seems that they are all 3 green (including the aeon z-stick). So that is fixed.

Would you share your thoughts for upcoming changes, expecting to test something soon?

Updated, tested twice so far and all good now (concerning green)

[cdjackson]

Furthermore, do you say there are still some bugs in the general code which occur at Pi, or is it Pi specific, or randomly.

The issue that we are looking at here is a specific issue that only occurs (as far as known) on the Pi. Much of the recent discussion has now blurred this issue into other issues, but the original issue was Pi specific.

Would you share your thoughts for upcoming changes, expecting to test something soon?

One the initialisation refactoring is done I hope to work on some of the smaller tasks that are piling up in the issues list e.g. some new command classes. I don’t have another major thing to work on right at the moment (although I hope to look at the security classes soon which could be a large piece of work).

[mebj]

I have followed the discussion with great interest but not contributed lately mainly because my Pi again has been running extremely well for some time. There have been occasional duplications but very few and I can not see any for the last few days. The system is running as a daemon and with just standard logging so there is not much info to share and I have not wanted to make any changes and touch it in any way.

So the behavior changes with time which is the worst thing ever to monitor and troubleshoot. There is no obvious logic in it (at least not to me :-)). Therefore a big thanks to Chris for the work and interest you are putting into this and thanks also to other people contributing.

My installation is rather small, 1 Aeon 4-in-1, 6 Aeon switches, a Mysensors network (on MQTT) with some 10 temperature sensors (some with humidity as well) and an energy pulse meter installation. There are quite a few events from these sensors so I think the Pi has enough to do keeping in mind the posting of data, diagrams etc onto the web as well.

I may test with a Pi 2 later but can not start with that now for other reasons. But from the few tests I have made so far the Pi 2 seems very promising capacity wise compared to the B+ version I use now.

[maggu2810]

I am using the following components:

• latest code in the openhab/master repository to build a zwave binding bundle.
• OH2 compat1x bundle
• ESH bundles

I can monitor the duplication of messages in the log on my system, too. The system consits of a quad core x86_64 cpu and 8GiB RAM.

So, if your habmin repository does not contain a relevant bugfix, I think the problem is not triggered by a low system performance (I don't think that the OH2 / ESH bundle will waste so much CPU).

[cdjackson]

I'm not completely sure I understand your point, but you're using an old version (ie not the version from the HABmin branch) and as per messages I've sent to the group there will be duplicates due to a timer issue in the stick that is made worse by a low performing device. I can't really comment further on your problem unless you use the latest test release and provide a log.

[maggu2810]

Okay, I will change to use the latest version. There is your HABmin repo that contains a build bundle (https://github.com/cdjackson/HABmin/raw/master/addons/org.openhab.binding.zwave-1.7.0-SNAPSHOT.jar). What repository / branch could I use to build the latest one for myself?

The message duplication is (ATM) no problem on my systems, I just want to inform (you), that it occurs (with the version in the openhab repo) also with a non-low performing machine [my laptop](I do not know, if "low performance device" refers to the stick or the RPi).

If you point me to the most up-to-date source branch, I will use that one. I could create logs and perhaps I could also debug it for myself.

[cdjackson]

The latest branch is here -: https://github.com/cdjackson/openhab/tree/zwave-initialisation_state

[waconiglio]

Positive note: I just tested for close to 24 hours on a Pi 2 with no duplication. Z-stick and Aeon Multisensor a couple of rooms away. OpenHAB 1.6.2 from release snapshot. HABmin is quite snappy.

[MrMontesa]

Hey, looks like I might ran into the same issue. From the events.log I can see: 2015-02-20 22:46:51 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:51 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:51 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:51 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:51 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:52 - Fibaro_Motion_1_Lux state updated to 80 2015-02-20 22:46:53 - Fibaro_Motion_1_Lux state updated to 80

Also a few rules that are based on this item are exectuted twice or more often. I'm about to upgrade zwave binding to the one mentioned above. Let me know if you want me to do some special tests. My system: rPi model B with Linux raspbian 3.12.28+. All patches installed.

[cdjackson]

looks like I might ran into the same issue. From the events.log I can see:

Sorry, but the events log doesn’t really mean anything. This data might have been requested multiple times, in which case it’s correct. The only way to see what is happening is with a debug log.

[MrMontesa]

Ahh, ok. I thought events.log would help. I'm new to zwave but I cant imagine that one single OH item bound to this device will poll 14 times in 3 seconds. Looks abnormal to me. But you're right, could be something else. Is there any experssion I can grep in zwave.log? Thanks

[cdjackson]

I do agree that it looks abnormal, but the question of ‘why does it look abnormal’ is a different matter. It might be a bug in the binding sending multiple requests (I’ve seen this), or it’s even possible that the device can send this sort of sequence (probably not in this case), or it might be this duplication issue… The only way to know is to look at the debug log though...

[mdeneen]

I'm planning on acquiring a rPI 2 in the coming weeks and moving my openHAB stuff to that. I have a few z-wave nodes on my network and will let you know if I experience this condition with my z-stick.

[christianwaite]

Can anyone confirm that OpenHab is working on the RPI2 without this issue?

[waconiglio]

I have a Pi2 and have been using it without issue on a 7 node network with an Aeon Zstick. I see duplication, but it is always on specific nodes and is immediate, not delayed 2 seconds. That may be a configuration issue or something not related to this thread. I did experience some unexplained freezes that the Pi 1 didn’t have, but curiously, no freezes since I installed a watchdog timer. Go figure.

On Mar 11, 2015, at 9:28 AM, christianwaite notifications@github.com wrote:

Can anyone confirm that OpenHab is working on the RPI2 without this issue?

— Reply to this email directly or view it on GitHub.

[christianwaite]

Thank you. Very helpful!

[samwinans]

For anyone with a Pi B+, I have installed 1.6.2 runtime and addons and the issue has been resolved - back up and running. Thanks Chris & team.

[bakkerv]

Are the fixes already merged into the master branch of openhab? If so, which versions include the fixes? Saying it works in the new pi only seems to be related to having faster hardware.

[cdjackson]

I don't think there is 'a fix' to this issue. The binding has been improved (although not for 1.6.2 - 1.6.2 is the same as 1.6) and this has helped a lot of installations. These changes are in the latest 1.7 snapshots in the OH master repository.

However, I continue to see some issues - it seems a lot less of a problem even on older hardware, but I don't believe it's necessarily "fixed" and depending on other bindings that are running (or whatever) your mileage may vary...

[mebj]

Finally I have had the time to convert my installation to a Pi2 and it has been running now for 1½ day without any signs of problems at all. I made a completely fresh installation of the Razberry software as well as Openhab 1.7.0. Now also the app on my phone works well and can show the diagrams and icons without errors. So far the conversion thus is well worth the effort.

[sercasyr]

I also get the CAN error with the same line "Error extracting value - length=9, offset=6, size=6"

I am 99% sure this is caused by messages from an Aeon Labs 4in1 Motion Sensor. Although I own also several Fibaro devices.

I am using Windows 8.1, not a RaspPi. My OpenHAB is 1.6.1, but the Zwave binding is the 1.7.0 snapshot from March 7th.

However, the values I get for items are correct so I haven't put too much effort in finding the cause of this.

But, if someone is interested, in happens using Windows too...

[cdjackson]

I also get the CAN error with the same line "Error extracting value - length=9, offset=6, size=6”

Why are you reporting this here? I don’t think that it’s anything to do with message duplication (is it?) and you’re not using a RPi?

[sercasyr]

Because I get exactly the same message "Error extracting value - length=9, offset=6, size=6”. I looked up this message in Internet and this thread came up... I thought it might be related. It's the same string and some people were talking about the possibility of testing in with a Windows system. My apologies if it is not related. I any case it's an issue...

[cdjackson]

This issue has nothing to do with these messages - it is associated with raspberry Pi message duplication - ie multiple messages being received at the same time. When you say "I get exactly the same message" I think you're the first person to mention this in the thread! (yes, I know it's in some of the logs shown, but that's not what this issue is about).

Please can you raise a separate issue if you have a problem and I'd be happy to look at it, but adding to this is not the right way to get it solved. If you raise another issue, please provide the debug logs - I doubt I'll be able to fix it though as this sort of error normally means that the device is sending corrupted data (and it's normally associated with Aeon equipment).

[sercasyr]

I will open a separate issue. My apologies.

[corb555]

Keep in mind that there have been issues with Raspberry Pi and some other ARM SoC's duplicating USB messages from other devices (keyboard, etc). This may have nothing to do with the Z-Wave binding. Anyone with this issue, should first check their board's boards to see if there is a USB duplicating issue and how to fix it.

[cdjackson]

Keep in mind that there have been issues with Raspberry Pi and some other ARM SoC's duplicating USB messages from other devices (keyboard, etc).

Can you provide a reference to this? If there really is a USB problem with ARM chips then it would be useful to know to avoid wasting too much time on this...

[watou]

Be aware that there was a very long period with the first-gen Raspberry Pi where the USB driver had many serious bugs (partly due to the underlying hardware having many serious design problems). Over time they were able to work through most of them. But just about any non-trivial demands on the USB hardware would show problems in the early days.

[cdjackson]

Interesting - thanks John. I wasn’t aware of that - I guess it’s not impossible that this is a contributor here...

[watou]

I fought the USB nightmares early on building a photobooth with USB webcams on the original Model B, and it was a hot mess for a long time. For those using old drivers, they would almost certainly have USB problems.

[corb555]

Here's a link to the issue. (http://elinux.org/R-Pi_Troubleshooting#R-Pi_does_not_respond_to_key_presses_.2F_Keyboard_randomly_repeats_key_presses). I believe if the ZWave stick is the ONLY USB device and you have a good power supply, the problem never showed up. If you have more than one USB device, you need latest image (and possibly some other steps).

[brutevinch]

Using OH1 i686 Intel atom and razberry+fibaro dimmer. in log i see duplicated messages. Any chance to fix it? 2015-07-07 22:28:25.373 [INFO ] [runtime.busevents ] - ITM_LIGHT_BEDROOM_MAIN state updated to ON 2015-07-07 22:28:25.375 [INFO ] [runtime.busevents ] - ITM_LIGHT_BEDROOM_MAIN_DIMMER state updated to 17 2015-07-07 22:28:25.467 [INFO ] [runtime.busevents ] - ITM_LIGHT_BEDROOM_MAIN state updated to ON 2015-07-07 22:28:25.505 [INFO ] [runtime.busevents ] - ITM_LIGHT_BEDROOM_MAIN_DIMMER state updated to 17

[cdjackson]

Using OH1 i686 Intel atom and razberry+fibaro dimmer.

I guess since this isn't an RPi that this isn't the same issue as the RPi? IF you really think this is a bug in the binding, then it would be better to raise a separate issue as it's confusing to discuss different problems in a single issue.

If you do think it's a bug in the binding, please provide information that supports this, and also allows me to see what is wrong - ie debug logs showing the problem. A "any chance to fix it" question without such information can't really be answered.

[brutevinch]

98% of RPi users used razberry and i've got same problem at other arch (i686) with same board(razberry). board the same, binding the same, arch is other. Maybe it's not RPi at all?)) Today i try to catch info in wave debug. Here is debug info of duplicate:

2015-07-08 13:42:45.183 [DEBUG] [ApplicationCommandMessageClass:38 ]- NODE 2: Application Command Request (ALIVE:DONE) 2015-07-08 13:42:45.184 [DEBUG] [ApplicationCommandMessageClass:56 ]- NODE 2: Incoming command class SWITCH_MULTILEVEL 2015-07-08 13:42:45.185 [DEBUG] [veMultiLevelSwitchCommandClass:94 ]- NODE 2: Received Switch Multi Level Request 2015-07-08 13:42:45.186 [DEBUG] [veMultiLevelSwitchCommandClass:114 ]- NODE 2: Switch Multi Level report, value = 1 2015-07-08 13:42:45.187 [DEBUG] [b.z.i.protocol.ZWaveController:682 ]- Notifying event listeners: ZWaveCommandClassValueEvent 2015-07-08 13:42:45.188 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent 2015-07-08 13:42:45.189 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_MULTILEVEL, value = 1 2015-07-08 13:42:45.191 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63 ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 02 01 00 2015-07-08 13:42:45.193 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64 ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 03 26 03 01 2015-07-08 13:42:45.194 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65 ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false 2015-07-08 13:42:47.182 [DEBUG] [eController$ZWaveReceiveThread:1528]- Receive Message = 01 09 00 04 00 02 03 26 03 01 D7 2015-07-08 13:42:47.186 [DEBUG] [eController$ZWaveReceiveThread:1452]- Receive queue ADD: Length=1 2015-07-08 13:42:47.186 [DEBUG] [b.z.i.protocol.ZWaveController:1210]- Receive queue TAKE: Length=0 2015-07-08 13:42:47.188 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 09 00 04 00 02 03 26 03 01 D7 2015-07-08 13:42:47.190 [DEBUG] [b.z.i.protocol.ZWaveController:1211]- Process Message = 01 09 00 04 00 02 03 26 03 01 D7 2015-07-08 13:42:47.192 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 03 26 03 01 2015-07-08 13:42:47.193 [DEBUG] [ApplicationCommandMessageClass:38 ]- NODE 2: Application Command Request (ALIVE:DONE) 2015-07-08 13:42:47.194 [DEBUG] [ApplicationCommandMessageClass:56 ]- NODE 2: Incoming command class SWITCH_MULTILEVEL 2015-07-08 13:42:47.195 [DEBUG] [veMultiLevelSwitchCommandClass:94 ]- NODE 2: Received Switch Multi Level Request 2015-07-08 13:42:47.196 [DEBUG] [veMultiLevelSwitchCommandClass:114 ]- NODE 2: Switch Multi Level report, value = 1 2015-07-08 13:42:47.197 [DEBUG] [b.z.i.protocol.ZWaveController:682 ]- Notifying event listeners: ZWaveCommandClassValueEvent 2015-07-08 13:42:47.197 [DEBUG] [.z.internal.ZWaveActiveBinding:433 ]- ZwaveIncomingEvent 2015-07-08 13:42:47.198 [DEBUG] [.z.internal.ZWaveActiveBinding:450 ]- NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_MULTILEVEL, value = 1 2015-07-08 13:42:47.200 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:63 ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 02 01 00 2015-07-08 13:42:47.203 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:64 ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 03 26 03 01 2015-07-08 13:42:47.204 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:65 ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false 2015-07-08 13:42:47.462 [DEBUG] [eController$ZWaveReceiveThread:1528]- Receive Message = 01 09 00 04 00 02 03 26 03 1A CC 2015-07-08 13:42:47.466 [DEBUG] [eController$ZWaveReceiveThread:1452]- Receive queue ADD: Length=1 2015-07-08 13:42:47.466 [DEBUG] [b.z.i.protocol.ZWaveController:1210]- Receive queue TAKE: Length=0 2015-07-08 13:42:47.468 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ]- Assembled message buffer = 01 09 00 04 00 02 03 26 03 1A CC 2015-07-08 13:42:47.470 [DEBUG] [b.z.i.protocol.ZWaveController:1211]- Process Message = 01 09 00 04 00 02 03 26 03 1A CC 2015-07-08 13:42:47.472 [DEBUG] [b.z.i.protocol.ZWaveController:190 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 03 26 03 1A

[cdjackson]

The problem on the RPi occurs with other sticks as well.

Please provide the debug log when you get it and I'll take a look when I get a chance, but I think it's better to raise a separate issue.