Delays in reaction

[chapa 3]

Hi Fibaro Community,

 

I experience strange behavior on my HC2 system.

 

My Hc2 is on 3rd floor. I have many Wall Plugs on 2nd floor.

I am trying to control my lights on 1st floor using Fibaro Dimmer 2 and Switch 2, included as security devices.

 

What I experience is, that is working just fine, reaction is less than a second ... for most of the time.

It works fine for some minutes, than a lag of 15-30 seconds appears. All commands for turnOn/Off are stacked and delayed with about 30 seconds.

 

First I thought it is a mesh network problem, I added many Wall Plugs, did mesh reconfiguration a few times, manually asked for neighborhoods update of affected devices and these between gateway and them...no success.

What is interesting, that dimmer and switches react smoothly 1-2-3 minutes, than stopping for a while.

That makes me thing it is not a zwave problem, but Fibaro's one. At most I have 1 hop between devices.

If it is a zwave problem, there should be no cases of smooth reacting.

 

Tried re configuring, adding/removing, waiting for hc2 to do its routing config, stopping HUE plugin, stopping Scenes, VDs...month so far no success, really disappointed.

 

I am a tech guy, always digging into the problem, and it is first time no progress.

 

Zwave used to be open protocol, and I can not understand, why I have no debug info in HC2, to examine where the problem may be.

Is it communication error, is it hc2 problem? Even CPU diagnostics tells some %, but no clue what is rising the CPU. Information is usable for hackers and reverse-engineers, but not to installers, having to switch off all >50 scenes and vds one by one to see what is causing the issue...I read somewhere.

 

Fibaro, what I should do? 

Ask for remote support? Why you think 20k of engineers out there, and all of the community members are more stupid than you?

All of the competitors have zwave debug information, and not only, available, and community just spot the problem, than fixed.

We have to spend weeks digging the problems with no instruments and give up disappointed.

 

Again, what should I do, to make my Dimmer2 and Switch2 controlling some lights work without a delay from time to time?

How can i debug where the problem might be?

 

I use 1.453 beta, 58 devices. Most of them Fibaro ones.

 

Anyone dealed with such a problem?

 

Regards

 

[speedy 64]

How does your CPU usage of the HC2 look when you have the delay in the system?

Like "normal" upp and down, or is it s straight line during the delay?

[chapa 3]

Absolutely nothing suspicious in CPU during delays. Overall I see some peaks, but dunno why they are, no process information. Overall 15-20% in average when we are home, 5 family members, other times 4-5%.

Nothing in changing VDs and Scenes helped reducing the CPU load, tried it a few times.

[Reintjan 29]

Fibaro HCL and HC2 suffer memory issues. Do you see something strange here?

 

i have delay problem sometimes, its always one or two days before my HCL completely freezes. I found out by testing that use of scenes in my HCL only increases memory use and never releases it. So after a few days all memory is used and before complete freese i have switches reacting very slow. My solution for now is a scene pushing VD button. The VD reboots HCL. Scene is triggered every night, for now it works, no more delays, no more freeses. 

Edited January 11, 2018 by Reintjan

[chapa 3]

I suffer no memory issues, but delay in reaction to dimmer and switch from time to time.

As stated, HC2.

[Reintjan 29]

4 minutes ago, chapa said:

I suffer no memory issues, but delay in reaction to dimmer and switch from time to time.

As stated, HC2.

Maybe you still can try to reboot the system regulary and see if it helps  at my place no more delays, it's running smoothly now for almost a month. Keep my fingers crossed

[chapa 3]

Last 20 days, I had more than 10 restarts hoping the same. Nothing changed.

Any idea how to dig into the problem, but not trying magical resolving reboots/tasks?

[Jamie mccrostie 82]

Have'nt used one but seems very cheap 

Please login or register to see this link.

[colvs 1]

good, I also had problems with fibaro and I asked to check them and after they checked they fixed the problems.

The first thing to do is check them out by remote and surely fix the problem. then you can buy a sniffer to check your communication.

Edited January 12, 2018 by colvs

[petergebruers 1,264]

4 hours ago, Jamie mccrostie said:

Have'nt used one but seems very cheap 

Please login or register to see this link.

I have one of these. I recommend one, but only if you are prepared to dig into Z-wave protocols. I have helped a few users via PM. It takes several hours, even with guidance, to get some basic understanding. It is easy to jump to conclusions... but I have to say it has helped a lot. You cannot diagnose all problems, for some I recommend an SDR. The sniffer allows you to get some idea of "who is talking to who and when". I know of no other tool, except contacting support or an installer with the official sniffer. Or forcing root access, something I did not do and I recommend you do not do that either.

Edited January 12, 2018 by petergebruers

[chapa 3]

3 hours ago, colvs said:

good, I also had problems with fibaro and I asked to check them and after they checked they fixed the problems.

The first thing to do is check them out by remote and surely fix the problem. then you can buy a sniffer to check your communication.

 

Did you get any explanation from Fibaro, what the problem was in your case?

 

5 hours ago, Jamie mccrostie said:

Have'nt used one but seems very cheap 

Please login or register to see this link.

 

I was looking at it and now really considering buying one.

 

Still not sure if it is zwave or fibaro problem.

Although I experience problems with long range Dimmer2 and Switch2, I have a long thought last night and just did another experiment with interesting results.

 

Included 2 Fibaro Wall Plugs at 3 meters distance from the HC2.

First, included in Secure mode, other Non-Secure.

 

Both Plugs reported direct communication with the hub.

 

Start turning non-secure one On and Off via the UI, after 5 minutes of switching I observe nothing suspicious. Everything worked smoothly.

Next, I did same with the Secure one. It took less than a minute and about 40 switches on/off to stop responding. I have to wait about 2 minutes in order my pending switches to get processed.

 

Repeated the test a few times. Results:

1. Non-secure plug - reactive, with no lag

2. Secure one - getting non-reactive from the UI after 30-60 clicks. Before the "freeze", switching is somehow laggy and responding period differs on every status change. After the "freeze", waiting interval for the system to get responsive again is between a minute and 5. All clicks, which I did during the "freeze" period get send to the device.

 

During the "freeze" period I observed the reaction of the HC2.

What I further find is even more interesting.

 

1. I was NOT able to turn on/off no one powered device in the system, secure and non secure ones. But all commands was queued and get processed once the system returns operational after the freeze. It seems like HC2 delayed processing the commands, but not zwave communication problem

2. Secure sensors (door sensors in my case) was NOT able to report status change. Status reports get lost, never reached the HC2

3. Non-Secure devices (fibaro motion sensors in my case) WAS ABLE to report status change. I see them breaching and going safe during the "freeze" period, and reacting smoothly with no observable delay.

4. Absolutely nothing in CPU or RAM Diagnostics panel does not point there is a problem. CPU going between 2-10%. No peeks. During the "freeze" I see less movement in CPU graph, and than CPU going up with 5-10% for a few seconds after the "freeze" period, which may be due to processing queued commands

 

All above makes me think than the problem is somewhere on HC2 side, when it comes processing commands for secure included devices.

A zwave sniffer probably will only prove this. I am also not aware if a sniffer can watch secure communication between zwave nodes.

 

Anyone experienced common issues?

I read, that it is highly recommended including devices in secure mode, even most of the hubs do that on default, I think. On Fibaro you have to explicit click, probably is not recommended due to some limitations or bugs?

Can it be because of the old Zwave chip inside HC2?

 

Many questions, so far no clear solution except exclude/include(non-secure) all of my >40 secure nodes.

I see people in the forum with big setups, can you please share if nodes are non-secure?

 

Thanks.

[colvs 1]

Unfortunately I have not received explanations very clear from them, but I trust them 100% and I see that they are continually working and improving the system. I answer very late, which is not right. I took a sniffer, but I still have not had time to test it. With the sniffer you can see when your command comes to the device and from which node. you can determine the strength of the signal and its (intelligibility) quality.

I have attach FGD-212 without HC2 after press button for association

 

RSSI is a signal strength indication. It does not care about the "quality" or "correctness" of the signal. LQI does not care about the actual signal strength, but the signal quality often is linked to signal strength. This is because a strong signal is likely to be less affected by noise and thus will be seen as "cleaner" or more "correct" by the receiver.

There are four to five "extreme cases" that can be used to illustrate how RSSI and LQI work:
1. A weak signal in the presence of noise may give low RSSI and high LQI.
2. A weak signal in "total" absence of noise may give low RSSI and low LQI.
3. Strong noise (usually coming from an interferer) may give high RSSI and high LQI.
4. A strong signal without much noise may give high RSSI and low LQI.
5. A very strong signal that causes the receiver to saturate may give high RSSI and high LQI.

Note that both RSSI and LQI are best used as relative measurements since the values are dependent on the modulation format.

 

from:

Please login or register to see this link.

 

 

 

 

Please login or register to see this attachment.

Please login or register to see this attachment.

Edited January 12, 2018 by colvs

[petergebruers 1,264]

1 hour ago, colvs said:

Note that both RSSI and LQI are best used as relative measurements since the values are dependent on the modulation format.

 

I agree with your previous post generally and I think this remark is particularly important. If you want to have some idea of network performance, you have to be aware that your Z-Sniffer should be close to either the receiver or transmitter. And even then, your Z-Sniffer is not receiving the same signal as your module or controller. Because it only registers packets that look like Z-Wave packets, it does not detect anything below a certain threshold or collisions that corrupt the packets "beyond repair". This might seem obvious, but I think it easy to forget this! I say this, because my personal opinion is you should not start your diagnosis with this tool, by looking at this parameter... As I say, this is my personal opinion, I might be wrong about that. I would not even start diagnosing right away! I really recommend to start looking at thinks that *do* work so at least you have some idea of what normal traffic looks like. For instance, if node 2 sends to node 1 but cannot reach it, it might decide to do routing, for example via node 42. If Z-sniffer does not hear the traffic from node 2 either (which is a reasonable assumption if it is close to your controller), it might register packets from node 42 to node 1. Then you wonder... why is node 42 transmitting to node 1 right now? But in fact it is only relaying the message from node 2. I have made some modest attempts at analyzing the (raw) packets dumped by this device, but I am still not sure on how to detect this. I bet the information is there, but I do not know how to interprete it. So if you *do* know more, please enlighten me! BTW for the technically inclined, this is a software defined radio chip, tuned to one of the Z-Wave frequencies, coupled to a STM8 microcontroller. Because of the limited capabilities of that MCU, it is unlikely to get more detailed output (in ASCII mode) from this device. That said, I found it money well spent!

2 hours ago, colvs said:

 

Please login or register to see this attachment.

Please login or register to see this attachment.

 

I am curious... this is a broadcast packet, so is this part of an inclusion? Whit my limited knowledge of raw, just going by the length of that packet, is it a NIF?

[colvs 1]

14 minutes ago, petergebruers said:

 

I agree with your previous post generally and I think this remark is particularly important. If you want to have some idea of network performance, you have to be aware that your Z-Sniffer should be close to either the receiver or transmitter. And even then, your Z-Sniffer is not receiving the same signal as your module or controller. Because it only registers packets that look like Z-Wave packets, it does not detect anything below a certain threshold or collisions that corrupt the packets "beyond repair". This might seem obvious, but I think it easy to forget this! I say this, because my personal opinion is you should not start your diagnosis with this tool, by looking at this parameter... As I say, this is my personal opinion, I might be wrong about that. I would not even start diagnosing right away! I really recommend to start looking at thinks that *do* work so at least you have some idea of what normal traffic looks like. For instance, if node 2 sends to node 1 but cannot reach it, it might decide to do routing, for example via node 42. If Z-sniffer does not hear the traffic from node 2 either (which is a reasonable assumption if it is close to your controller), it might register packets from node 42 to node 1. Then you wonder... why is node 42 transmitting to node 1 right now? But in fact it is only relaying the message from node 2. I have made some modest attempts at analyzing the (raw) packets dumped by this device, but I am still not sure on how to detect this. I bet the information is there, but I do not know how to interprete it. So if you *do* know more, please enlighten me! BTW for the technically inclined, this is a software defined radio chip, tuned to one of the Z-Wave frequencies, coupled to a STM8 microcontroller. Because of the limited capabilities of that MCU, it is unlikely to get more detailed output (in ASCII mode) from this device. That said, I found it money well spent!

 

I am curious... this is a broadcast packet, so is this part of an inclusion? Whit my limited knowledge of raw, just going by the length of that packet, is it a NIF?

 

It is what the dimmer sends to the NETWORK and awaits the answer from HC2.

Edited January 12, 2018 by colvs

[chapa 3]

Just ordered ZWave Sniffer, but I think it will be more fun than real measurement.

 

Anyway, going out if topic.

Can secure inclusion of device be still a yearly problem or reintroduced?

 

I found following post around:

 

And in general many users posting here for problems with secure included devices.

The test above as described is easy to be replicated. Freezing up the system for a minutes for all secure devices is something which should be handled by Fibaro with high priority.

 

Edited January 12, 2018 by chapa

[colvs 1]

You are right, from master to slave, it is important through a number of devices to pass the information because a delay can occur due to package retransmission, check amount error (CRC).

[petergebruers 1,264]

I avoid secure mode...

[chapa 3]

10 minutes ago, petergebruers said:

I avoid secure mode...

 

 

Planning to reconfigure all the devices.

In the future, definitely I will do avoid also.

 

But ... I think there should be pinned post clearly saying "Welcome to the forum. You just bought brand new HC? SECURE INCLUSION - NO GO, except in the case you want to spend weeks digging without tools, reports, support". Also included in HC2 manual!

 

It will be good, if anyone else can confirm the "Two device turnon/off test (secure vs non-secure)" problem,  using Fibaro powered modules (Plug/Dimmer/Switch).

Edited January 12, 2018 by chapa

[unitedeurope007 2]

I can confirm the problems with securely included nodes. Support said to include the nodes as non-secure. Now switching all nodes to non-secure...pain in the neck. 

The reason is definitely not high CPU or memory utilization (checked these while waiting and waiting for the commands to reach the device)

[chapa 3]

Hi @unitedeurope007,

 

Thanks for feedback and confirmation.

 

SiliconLabs and all big manufacturing brands clearly recommends adding in secure mode. Even S2 is around from years now.

Please login or register to see this link.

 

Which obviously is not Fibaro case. Fibaro, are you Z-Wave Certified ?

 

With secure mode devices, HC2 just lags and does not work stable. It blocks on zwave communication.

As more secure messages go through, more "blocked" hc2 become.

 

But it is a step ahead, being a official position of Fibaro support.

Still new comers should be clearly warned not to go to recommended secure mode ... ops, not-recommended.