Serious delays in communication

Community Playground General Discussions
1

I have been fighting a problem for days now, I have learned a lot but I hope I can come to any conclusions with some help.

I installed an IR-sensor on my driveway which is connected to a Fibaro Universal Sensor. I want to use this sensor to trigger a bell (connected to a fibaro FGS 221 switch). The bell runs fine: if I switch it on it rings. It switches off automatically within a second, using the custom parameters 3 and 4 of the module. This way it switches off without using a scene. Also the IR-sensor with the Universal Binary Sensor (UBS) appears to function OK. If I trigger it, the vera user interface shows that it is triggered immediately. So I thought this is a piece of cake: make a scene with the UBS as trigger and switch the bell on and done. Unfortunately this didn’t work.

The problems:

First the bell didn’t ring at all when triggered by the UBS, while it still would ring when triggered from the interface. At this stage I still switched the Fibaro for the Bell on and off in a script, and the logs would tell me that the command to switch on was superseded by the command to switch off. I changed the script to what was described above: I only switch it on and it switches off automatically. Now the bell eventually rings, albeit with a delay of minutes. I have been searching for the cause of this delay for days now.

Some more info:

I also have a Mail and Prowl script with the UBS as trigger, and I get the messages pushed to my iphone in seconds. So this runs absolutely lovely. So the vera receives the status change almost instantly, as shown in the interface as well; the problem appears in the communication between the nodes after the notification. The problem does not appear if I use another sensor to trigger the bell scene.

I thought the problem might be related to unreliable communication between the nodes, so I started analysing the network structure. It appears that most nodes can talk to each other directly and to the vera (Vera II UI 5 with latest updates) directly. I have 7 mains powered nodes, mainly Fibaro switches, that should be able to relay. Furthermore I have 4 battery powered nodes that work fine, and finally, the 12V powered UBS also from Fibaro. The UBS was quite far away from the vera, so direct communication may have been unreliable. But there are 3 Fibaro switches about 10m away from the UBS with mainly air in between, just one thin wall of glass and wood. The reception should be fine. To take away all last doubts with regard to the reception I positioned an additional Fibaro switch between the UBS and the other switches and rebuild the network (heal). This made no difference at all. I also moved the vera closer to the UBS and the other switches (of course I rebuild the network with a heal). One more thing that I tried: I replaced the scene with an association between the UBS and the Bell switch. This did not solve the problem. The delay was still considerable, although it was nice to see that it still functioned without the vera being online… Associations with other sensor were very responsive. Finally I tried several configuration options for the z-wave network: I rebuild the network with: ‘limit neighbors to Z-Wave discovery (requries Vera routing)’ switched on. (If is off again now.) I also tried ‘Use Vera routing instead of Z-Wave (requires 4.5)’ switched off. Basically I tried many combinations of these settings and each time I rebuild the network. Under some settings I would get more trouble with devices but the delay problem never disappeared… Now I have the default setting under z-wave options again. The first three checked, the fourth unchecked and the fifth checked.

I have been studying the logs to see what is going right and wrong and here I’m hoping to get some help with these.

[ul][li]I have the feeling that some node may be jammed causing the delay. But I can’t really identify this from the logs.[/li]
[li]I think my network may not be relaying properly because all my routes look like 10.0.0.0 and I see a lot of NO ROUTES in the logs, but maybe this is meaningless.[/li]
[li]I think there may be some kind of memory leak, since I keep seeing LEAK, this appears when I trigger the UBS.[/li]
[li]I see that sometimes jobs are cancelled (or ‘superceded’)[/li][/ul]

When I experience the delay I see this:

04 12/27/12 13:00:32.593 <Job ID="9" Name="ON node 9" Device="30" Created="2012-12-27 13:00:26" Started="2012-12-27 13:00:32" Completed="2012-12-27 13:00:32" Duration="5.595904000" Runtime="0.0" Status="Aborted" LastNote="Superceded by job#28" Node="9" NodeType="ZWaveNonDimmableLight" NodeDescription="Deurbel s2 DingDong"/> <0x803>

I attached three log files:

[ol][li]SeriousDelay.txt: Here the problem appears, it took two or three minutes for the bell to ring.[/li]
[li]TestBellwithKitchenSensor.txt: Here the UBS is replaced with another sensor and no problems appear[/li]
[li]ProwlFeedBackFine.txt: Here the UBS triggers a Prowl notification that is delivered within seconds[/li][/ol]

I commented the logs with ‘!!!’

Sorry for the long read, but I hope that giving a lot of information helps solving this problem. If this is solveable at all because I starting to consider the possibility that the Vera support of this UBS may be flaky.

2

Hi all, still fighting the problem described above…

Basically scenes won’t run reliably. So I re-read the manual, especially the parameter settings. But I don’t understand the parameter setting 14. Here is the manual.

I understand what the intention is of this setting but not how I should configure this setting. I understand how to turn on this custom parameter on the device options page. But how can scene’s be coupled to this functionality? The manual says that information is sent to devices that are assigned to association group 3. But I would understand how a device can be assigned to an association group but how can this trigger scene’s depending on which input is triggered and how?

3

The problem described above seems to have been solved by a ‘z-wave network reset’. I reset the z-wave network, did a factory reset of the vera and started to build up the network again.

It was a lot of work but it solved the problems.

4

Resetting the entire network sounds a little drastic :slight_smile:

I’ve had an issue with a device that just wouldn’t behave right, but in that case I just excluded and re-included only that device, which fixed the issue.

5

Thanks for pointing that out. I’ll try that as well next time.

But this was not just one or two devices this time. The gate sensor in combination with a certain switch would give delays but other combinations with either the switch or the sensor would be fine. Furthermore I had issues including Duwi.me scene controllers and setting custom parameters on other Greenwave sensors. After the reset all functions normal again… So I’m happy.

6

The problem is back again.

If my sensor is triggered a Prowl message to my iPhone is delivered in seconds but the z-wave devices that should react to a scene can take up to a minute to react.

I think I’m dealing with the same issue as described in this topic. There is some kind of z-wave related problem going on here.

For switching garden lights on and off this may not be an issue but for anything else a response time of more than a few seconds is not acceptable. In starting to become fed up with my vera.

7

Hi Apt

Please hang in there. I had several of these moments ;D
Still i am happy with Vera…

I suggest you install Vera Alerts and let Vera play several sound files during the day, like dogs or chickens etc
It does not solve your Z-wave problem but at least it is funny ::slight_smile:

8

I don’t see how hanging in there is going to solve the problem. I have been using the vera for less time critical applications. But now I finished building the system as I wanted it and it involves some situations where you want quick and reliable reactions.

z-wave is sold as a system that reacts quickly and reliable… I’m curious wether I would have similar problems with other controllers like vera 3, the Fibaro one, or Homeseer.

At the moment I’m sorry I invested in vera. I’m considering my options.

9

I have a feeling you want to shoot the messenger ???
There seems to be some indication that it could be the selection of Z-Wave devices and the topology causing the problems.
Vera is just one component in the collection of devices that must work together. You could replace it with something else and still have the same problems.

10

That may be, of course I am not sure wether the vera is to blame.

But after resetting the vera to factory settings and reconfiguring everything it worked with much less delay for a few days.

In the procedure of resetting everything al devices were reincluded and therefore reset. The reset of the devices may have temporarily solved the problem. Maybe there is some kind of memory leak or a buffer that gets filled in one of the Fibaro devices. Are any such problems known? I didn’t read about them.

If it helps: my network consists of 6 fibaro in-wall switches: FGS-221 and the sensor involved here is the Fibaro Universal Binary Sensor. (and several other Greenwave and Duwi switches and controllers that are not related to the problem)

11

I have been having trouble getting a Fibaro Universal Binary Sensor (FUBS) to work in a similar application. I think one of the issues is that this device is designed as battery-powered, meaning it goes to sleep almost immediately after sending out a binary input change-of-state message. In my case, the device is attached to a large battery that is continuously charged from mains, so it could happily stay awake all the time.

I did reduce the “Poll this node at most once ever” time from 60 seconds down to a few seconds (device Settings tab). It could be that Vera waits the 60 seconds before attempting to poll the device before initiating the scene and by then it has gone to sleep. That seemed to improve matters, but I also got a Vera firmware beta upgrade as well.

Please post any progress you make regarding use of FUBS. Thanks.

12

@dgriffith,

Welcome!

For battery powered devices, the wake-up time will determine how often the device wakes up. The ‘poll at most’ setting only sets a limit of how often a poll is allowed, not how often a poll will be done. If you set the ‘poll at most’ setting to something lower than the wake-up time, the device will effectively be polled every time it wakes up.

Some devices may have a configuration parameter that will cause them to be awake all the time, for setups where you power the device from mains. I don’t know if the FUBS has such a setting.

Also, typically, for sensors like motion, or a door/window sensor, the device will push a state change to Vera right away and the wake-up and polling mechanisms don’t come into play.

13

@dgriffith, Thanks for posting your experience…

That is what I thought too, but: as I described in this thread: the FBUS pushes a state change to Vera, but then Vera starts polling the FBUS. In my case the polling of the FBUS seems unreliable, maybe because it went to sleep, maybe because of sloppy relaying of z-wave signals. Some scenes that are coupled to the FBUS trigger wont run until the polling is successfull. It can take minutes to get a successful poll and therefore I experience a delay of minutes before a scene is run, even though the push had been received properly…

14

Thank you both. I can find no documented way to keep FUBS awake.

15

@apt
I’m not sure if the following information is actually relevant to your issues but I thought I would bring it to your attention just in case:
I also have a number of FGS221 modules which are about 18 months old with an internal firmware version of 1.4 according to the version information of the settings tab. These devices all appeared to do an immediate status push to my V2 running 1.5.408 whenever their status was changed locally using the switch input.

Recently I added a new FGS221 which has an internal firmware version of 1.9. Unexpectedly I found that this new module did not perform a status push when locally activated; there could be a significant delay (10’s of seconds) before the status change would be reflected in Vera which I presumed was a result of Vera ‘discovering’ the status change when it got to polling the device. It would appear there was some firmware change between my V.14 and V.19 Fibaro’s that caused the status push to break when operated with Vera.

I have recently upgraded my V2 to 1.5.622 and have noticed that in addition to the disappearance of the first child device (e1), that on all the FGS221 Device Options Tab Vera has automatically created an Association using Group 3 to device 1 (currently 2) which is the Vera unit. This seems to have restored the status push on the new Fibaro so that when the FGS221 is locally operated the change is almost instantly reported on the Vera dashboard. It may be worth checking if this could be contributing to your problems.

If you have still to upgrade Vera you will probably find you will have to repair any scenes that utilised the e1 child device that has now disappeared. Curiously one of my original three FGS221 has still retained its e1 child device on the dashboard although the settings tab also has the new Association with Group 3.

16

@Frasier
It may very well be relevant, I can’t say in advance. In principle the delay issue seems to be caused by the Universal Binary sensor. I’ll try the upgrade in a few weeks when I have more time. I didn’t do it yet because I read (and you mention it again) that it will break some scenes. I’ll check out the firmware versions of the switches as well. My fibs do an immediate push but it it broke down a few months ago. When it breaks down I need to reinclude the device in the network for the immediate push to reappear.

Thanks for the suggestions.

17

I have the Fibaro Universal Sensor also but I don’t use either of the inputs so can’t comment on delays associated with their operation. There was no Association group introduced on the universal sensor after the upgrade.

If you are still having the issues with the status push on the FGS221 it might be worth experimenting with just creating an Association with Vera using Group 3 on one of your switches to see if that fixes the status push on that switch without having to break scenes with the full upgrade.

18

I also have FGS221 Fibaro switches with the v1.9 firmware and may be experiencing this issue.

Frasier, I hope you reported the missing e1 child device for the beta firmware. This can be good.

I’ll try the association group 3 work around. How do you know what vera’s Z-wave device ID is? Is that the “node number” on “Z-Wave Settings”?

19

AFAIK if Vera is the primary controller it will have the ID of 1 so you associate it with the device ‘zwave’ - at least that’s how mine has defaulted.

As far as I understand the elimination of the e1 child is deliberate although for new users it would have made more sense to rename the remaining child e1.

Since I posted the original comment I have also had a new Scene controller device appear on the dashboard with an ID of e9, this appeared several days after the update and is related to the scene functionality on the Fibaro which must be due to the new Fibaro firmware as my older Fibaro devices don’t have one. I have not tried out the scene controller functionality.

20

I tried adding Z-wave (1) in association group 3. This also added scene_controller (2) in the “current” state of the group. So now I understand what you wrote before. Unfortunately it didn’t seem to make any difference. I probably also need to upgrade to the new version (when the beta becomes generally available).

One of my Fibaro switches also creates a scene controller, but in my case it is e8. If I delete it, it just reappears.