Endless updates

[zwbob 0]

Hello All,

 

I am using fibaro for almost 5 years and I am on the brink to give up. I have 180 devices and around 200 scenes. The hardware looks to handle this

 

I make updates praying that at last this time everything will work properly. 

 

My experience so far after updates, in case they might work properly:

- need to exclude include some devices, afterwords checking all scenes

- losing connections constantly with devices even the nearest ones

- Not possible to configure parameters for example auto off delay in smart implant....looks configured but it stays ON

- constantly lagging and very slow reactions

- need for restart one or two times per day

- 5 or 6 attempts to include fibaro devices in secure mode, adding/removing freezing very often

- smart implant with humidity sensor freezes the humidity readings. After power the implant off and on again working 1 day and than the same

- many many other issues like not logical battery drainage of some door/window sensors, walli switches being OFF, but seen as ON into the web interface

 

I remember ONLY ONCE an update working properly around 2 years ago and I have the following question:

 

- IS IT POSSIBLE TO MAKE ONE UPDATE WORKING PROPERLY AND DO NOT TOUCH IT ANY MORE?

 

I am desperate as I have systems that do not have possibility to control manually and I think that I should replace fibaro after quite big investment in fibaro.... 

 

Thank you for your attention,

Regards

Boris

 

[SmartHomeEddy 1,005]

Hi Boris,

 

there aren’t that many stable updates. I would like some more stable updates and less betas. If you also count the betas, well they are betas, nobody forces you to use them. I don’t use the betas for my production environment. 

[Tim__ 126]

From what you have written, I think you might have multiple problems that need addressing. These are unlikely to be just update related. You'll need to methodically work through this.

 

1. Firstly as SmartHomeEddy has said, you should avoid installing beta updates if you don't want to spend extra time being a beta tester for Fibaro.

 

2. You have a lot of devices. These may be creating a lot of messages and causing the freezing/delays. Get a zwave sniffer and analyse the traffic (there is a post on here detailling how to do this). You might have some devices that are sending too many periodic updates, like temperature updates, which you can reduce the frequency of.

 

3. Check that your humidity sensor is not a clone (if bought off Amazon etc then this is likely). There are plenty of issues from non-genuine sensors like you are seeing. Try replacing the sensor anyway.

 

4. You have a lot of scenes. Check whether your CPU usage is high. Try turning all your scenes off, to see if you still need to restart your hub every day and whether some lagginess goes away. Then switch on groups of scenes to see if you have one or some that are the cause. Sometimes bad LUA programming can cause CPU hogging loops. Also look to consolidate the number the scenes and how often they are automatically triggered.

 

5. When adding new devices, make sure these are within 1 metre of the hub.

 

Hope this helps! You have a bit of work ahead. The Fibaro platform is quite powerful but it does need careful attention to work properly. 

[SmartHomeEddy 1,005]

17 hours ago, Tim__ said:

2. You have a lot of devices. These may be creating a lot of messages and causing the freezing/delays. Get a zwave sniffer and analyse the traffic (there is a post on here detailling how to do this). You might have some devices that are sending too many periodic updates, like temperature updates, which you can reduce the frequency of.

@zwbob And if Zniffer is a bit hard to get working and understand, start with the z-wave diagnostics and look for the high values. 
 

 

 

Edited February 2, 2025 by SmartHomeEddy

[Łukasz997 117]

16 godzin temu, Tim__ napisał:

5. When adding new devices, make sure these are within 1 metre of the hub.

Good morning, Tim__,

I sometimes observe similar problems, but not so dramatic. It mainly concerns the Heat Controller (God forbid to enable Zwawe 3.0)

I would like to ask about point 5. I mean you think not about all devices but the battery-powered one, aren't you? It will be hard to add every o.e power outlet near the hub...

So do I understand correctly: you advise to add a device within 1 metre of the hub and then take it to the place where it's working.

What I don't understand is what's the difference: add near and normal use far from the central (but still within the range). Will it communicate better?

[Christb 33]

Using my knowledge of Data transfer through radio wave: with a poor signal, a lot of errors occurs in the receiving device which means then a lot of retries to receive correctly the needed message. The worse case is for message sent by the remote device to the home center making the inclusing to fail or giving incorrect data or incomplete information to the created device in the hub.

Device very close to the hub means strong signal with good protecion against interferences.

[Tim__ 126]

9 hours ago, Łukasz997 said:

I would like to ask about point 5. I mean you think not about all devices but the battery-powered one, aren't you? It will be hard to add every o.e power outlet near the hub...

So do I understand correctly: you advise to add a device within 1 metre of the hub and then take it to the place where it's working.

What I don't understand is what's the difference: add near and normal use far from the central (but still within the range). Will it communicate better?

Hi @Łukasz997, yes it can be a pain to include mains powered devices.  I discovered the hard way about needing to be close to the hub, trying many times before moving very close and then having it work first go. What I did for for my new devices:

1. Temporarily power them them up next to the Home Centre

2. Include as per normal (generally triple click the B button to initiate)

3. Relocate the device to the final location (ie inside ceiling or wall)

4. Do a z-wave mesh reconfigure, for that device only.  This ensures an efficient z-wave route back the new Home Centre location (the new route might use other zwave devices as repeaters)

5. Check that the routing has good signal strength using a zWave monitor app (or you could use a Zwave sniffer)

 

For existing devices that need to be re-included (I have some Qubino devices that periodically drop off the network and have to be re-added, very frustrating!)

1. Temporarily move the Home Centre to nearby the affected devices, using a long power cord and long Ethernet cable

2. Include as per normal (generally using the Home Centre interface to initiate)

3. Return the Home Centre to normal location

4. Update scenes etc with the new Device IDs

 

As @ChrisB said, the further away the device, the more communication errors.   In normal operation, the z-wave message is quite small, but during inclusion there is a lot more information transfer and hence more potential for the message to be corrupted during the allowed time period.

[Łukasz997 117]

W dniu 3.02.2025 o 02:10, Tim__ napisał:

4. Do a z-wave mesh reconfigure, for that device only. 

I will try it this way with the most problematic (and most remote) three heat controllers...

 

But, one more question: should I reconfigure z-wave separately for all "sub-devices"? Or it's enough do it for - usually made hidden - parent device (marked red in the picture)?

In another words: is all comm traffic from/to device is realised via parent or all sub-devices communicates independently?

 

Disabling not used devices for sure reduces traffic.

 

Please login or register to see this image.

/monthly_2025_02/image.png.9e5ba5cf9e657858d67312907102233a.png" />

[Tim__ 126]

There is only one zwave radio per physical device, so you only need to reconfigure zwave once on each one. You could trigger it from either parent or slave i think.

[zwbob 0]

Hi,

@Tim__

I read your comments very carefully and:

 

1. Firstly as SmartHomeEddy has said, you should avoid installing beta updates if you don't want to spend extra time being a beta tester for Fibaro.

I understand and I will try to avoid doing this. Just I can't resist sometimes after reading the change log while having some problems for example "...bug fixes"

 

2. You have a lot of devices. These may be creating a lot of messages and causing the freezing/delays. Get a zwave sniffer and analyse the traffic (there is a post on here detailling how to do this). You might have some devices that are sending too many periodic updates, like temperature updates, which you can reduce the frequency of.

I agree that I have a lot of devices but this cannot be avoided.

 

 

3. Check that your humidity sensor is not a clone (if bought off Amazon etc then this is likely). There are plenty of issues from non-genuine sensors like you are seeing. Try replacing the sensor anyway.

The humidity sensor is not a clone. I have totally 6 of those and I have problem with one. I might need to exclude and than include the smart implant connected to it or to replace the sensor just in case. The problem is that its location is quite inaccessible.

 

4. You have a lot of scenes. Check whether your CPU usage is high. Try turning all your scenes off, to see if you still need to restart your hub every day and whether some lagginess goes away. Then switch on groups of scenes to see if you have one or some that are the cause. Sometimes bad LUA programming can cause CPU hogging loops. Also look to consolidate the number the scenes and how often they are automatically triggered.

CPU and RAM usage is below 30% most of the time. I am using only block scenes. Some of them are quite complicated. In order to avoid triggering those scenes I use boolean variables. The events that occur often as temperature reading above setpoint triggers a small scene that assesses the value and triggers the boolean variable if there is a change below or above setpoint. That way the complicated scenes that consumes recourses are triggered only when variable changes. The actual number of scenes is 260. May be around 40-50 are assessing boolean variables. The most annoying scenes are those which I use to switch off switches which I need for momentary switches. Most of them are smart implants which is set in the parameters to switch off bit they do not so I use scenes when they are switched on to go off again.

 

5. When adding new devices, make sure these are within 1 metre of the hub.

At that stage I can even imagine to remove walli switches and sockets ....remove....add....going trough all settings.....going trough all scenes. If needed I will do it. I might move the HC3 room by room...sounds more practical. Reconfiguring can keep the settings and device numbers and can safe me work but often when reconfiguring it fails. Any advice will be appreciated.

 

I would appreciate to advise me how to reconfigure the mesh network as I think this option was removed since several revisions of the firmware.

 

In addition what I did and need some advice too.

 

I have some some of the devices outside and in the garage. this includes smart implants (for barrier and garage door), smart implants for some doors in the basement, double switches for some lights, door sensors for doors, IT and electrical cabinets, and 2 the button of fibaro. As this is quite far from the HC3 I have a repeaters in the garage and closest possible place in the direction to the garage having assured signal from the HC3 (Aeotec Range Extender 7). The HC3 in the diagnostics menu says that they doesn't have templates but might work properly. I also have Internet in the garage which is in the same subnet as the HC3. From time to time I am losing connectivity with the devices in the garage including those that are mains powered. Basically almost all devices are from fibaro. I have some 0-10V controllers of Qubino and few Eurotronic air quality sensors. I think that all lagging might come when scenes are triggered they cant communicate properly with the devices and this is engaging recourses to connect and everything is just queued.

 

Today I installed HC3 Light as a slave and installed it into the garage. I started to include the devices from the garage into the slave (using some spare was thinking to add and, substitute and replace one by one).

I noticed that it might not be needed and removed the installed device. I noticed that the functionality stabilizes ....at least looks like this.

 

My question is shall I leave it like this or to remove the devices in the garage from the master, include into the slave and preprogram everything there?

 

I will check and observe some more time and will be back how it works. Both HC3 and HC3 L are with the latest beta 5.171 release.

 

Regards,

Boris

Edited February 9, 2025 by zwbob

[Tim__ 126]

Hi @zwbob,

 

I'm glad you feel that my comments are pointing you in the right direction!

 

On 2/8/2025 at 9:24 PM, zwbob said:

At that stage I can even imagine to remove walli switches and sockets ....remove....add....going trough all settings.....going trough all scenes. If needed I will do it. I might move the HC3 room by room...sounds more practical. Reconfiguring can keep the settings and device numbers and can safe me work but often when reconfiguring it fails. Any advice will be appreciated.

I wrote this because you said it takes "5 or 6 attempts to include fibaro devices in secure mode, adding/removing freezing very often".  You only need to include devices when they are new (or when they fall off the network ie nodes marked as "dead").  You shouldn't need to do this otherwise.

 

You mention that you are losing connectivity in the garage.  Normally, a zwave repeater should be good enough to extend your coverage, but adding a slave hub is also a valid solution.  Something like a zniffer will allow you to see what is really going on with your traffic and signal strengths.

 

This thread is also interesting.  It talks about if you are using the zwave 3 engine you may not be able to reconfigure the network, also that signal strength is reduced.