Domoticz

Posted: **Monday 25 January 2021 10:45**

Couple of 'interesting' observations:

I was having issues with various brands smoke detectors (first Heiman then replaced with Fibaro FGSD002) just dropping off the network after a while. Re-including did not revive but create new devices instead

Other issues with Philio X-in-one (PST02-x) both misbehaving (2 devices with the same FW acting differently with different settings) and stopping to work after a while.

At some point, I disabled the nightly heal as it seemed to not improve stability for me.

A week ago, I decided to reinstate the nightly heal hoping that it may fix the smoke detectors dropping off the network and and, surprise, surprise, the Philio's stopped working after the first heal. Dead in the water and only a restart brought them back to life. So disabled the nighly heal again.

Then this morning, out of nothing, one of my neo power plugs just stopped reporting power. It had been diligently doing that for ages and all of a sudden it just stopped (I use the power reading for my standby killer so guess what happens if the power reading is 0W ). I could still switch it just fine but the power readings were gone. I also noticed that the timed power off was enabled. Tried to disable that setting and domoticz crashed. After the (monit) auto restart, the plug was back to life with power readings and all...

Just a subset of regular 'inconveniences' I try to get stable but have failed so far. I have been gradually transferring functionality to z2m (I really like the mosquitto approach). Would be very interested to have zwave2mqtt as an alternative but that would require another plugin to interface.
H

Posted: **Monday 25 January 2021 16:48**

heggink wrote: ↑Monday 25 January 2021 10:45
Other issues with Philio X-in-one (PST02-x) both misbehaving (2 devices with the same FW acting differently with different settings) and stopping to work after a while.

This device looks to be a bit buggy. Had issues at installation (bad inclusion), then sometimes parameters reset after changing batteries... I have 3 devices, all 4 in 1 versions.

And default were not working:
-Had to associate groups 1 & 2 manually.
-Parameter 6 set to 7, otherwise misbehavior (FW too busy then buggy, so remove association groups reports, cf param 20 as well).
-Parameter 7 keep to default 6 (OZW recommended setting = 22 never worked for me).
-Parameter 20 set to 0: Device internal FW looks to misbehave when activating reports (lux/temp periodic report, instead of just changes).

Multiple on with no off for PIR side was most annoying issue.

Take care that this device looks to never wake up, nor wake interval modification looks possible: Always wake them up manually to have parameter changes taken into account!

No other module associate PIR+door switch. Otherwise would have sent them back to seller! I use them (under rain protection) externally in front of my windows: Shutter closed, the door switch will ring the bells even before a window break attempt. Shutter opened, the PIR will do the same.

Posted: **Monday 25 January 2021 17:05**

All of that sounds familiar. And it's not even cheap.

Posted: **Tuesday 02 February 2021 0:08**

Thanks for starting this topic!

in my case, I have a quite repeating problem with z-wave. It is only about changing the state of switches from within domoticz (all of my wall-plugs and relays at the same time). They won't switch after about 2-3 day from the web front end, dzvents or a timers. The odd thing is, if I switch them manually with the hardware buttons, the change in state is reported to domoticz immediately.
My impression is, that it started after I went to the 1.6 version of openzwave. So far, I have not fully understood how to look into logs or configurations to figure out, what might be the cause.

I would also have an additional question, how could I reset the "Neighbours" graph that shows which device is connected to which? I have two endpoints in it which are not in the Neighbours list, one is shown as it would have a z-wave NodeID and the other is just there, without a NodeID?

Posted: **Wednesday 03 February 2021 9:30**

rugspin wrote: ↑Tuesday 02 February 2021 0:08 Thanks for starting this topic!

in my case, I have a quite repeating problem with z-wave. It is only about changing the state of switches from within domoticz (all of my wall-plugs and relays at the same time). They won't switch after about 2-3 day from the web front end, dzvents or a timers. The odd thing is, if I switch them manually with the hardware buttons, the change in state is reported to domoticz immediately.
My impression is, that it started after I went to the 1.6 version of openzwave. So far, I have not fully understood how to look into logs or configurations to figure out, what might be the cause.

I would also have an additional question, how could I reset the "Neighbours" graph that shows which device is connected to which? I have two endpoints in it which are not in the Neighbours list, one is shown as it would have a z-wave NodeID and the other is just there, without a NodeID?

The neighbours and routes are refeshed when you use the 'heal' functionality. I sugest to stay awaw from the 'heal network' button and the 'nightly heal' option, as these may cause a storm of packages in your z-wave network. In an already overloaded network, this might do more damage than good. But the 'heal this device' function (the little +-sign behind each node in the z-wave devices list), can be useful in some situations. Important tip: only click one (1) heal button at a time, after each click wait sufficiently long (at least 5 minutes) before clicking another one.

If the failing node is out of range of the controller and you try to send it a "heal" message, that heal message may not arrive at the failed node too. So healing that node directly will potentially not do anything but keep a place occupied in the controller's buffer for a long time. What you can do instead is, first "heal" a mains-powered node near your failing node and give it time to learn about it's neighbours (I personally wait at least 5 minutes). After that you can try to heal the failing node, and again give it sufficient time. If nothing helps, you may have to add another mains powered node closer to your failing node.

This situation occurs often when someone bench-tests their devices before installing them. In other words: if you first include a new device at your 'test location', for example near the controller, and only then install it at it's final location. Doing this makes that the device, the controller and devices near your bench-test-location initially learn the routes between your device and the controller to be very short. After you've moved the device to it's final location those routes are no good any more. So it is better to always include new devices at their final location.You may have to 'heal' a series of mains-powered nodes to create a path through your network to each of the devices. If you do: start with healing the mains powered nodes closest to your controller, then work your way out to nodes further away.

Posted: **Thursday 04 February 2021 10:53**

rrozema wrote: ↑Wednesday 03 February 2021 9:30 the 'heal this device' function (the little +-sign behind each node in the z-wave devices list), can be useful in some situations. Important tip: only click one (1) heal button at a time, after each click wait sufficiently long (at least 5 minutes) before clicking another one.
(...)
it is better to always include new devices at their final location.

Hello,

Interesting comment, but I can see a way for a single node to lean about neighbors from the control panel, but not from device list: Is this a recent feature (I'm still running old-stable v4.10717, with a few http/js fixes, as I was expecting some hazards with the OZW 1.6 switch)?

On device inclusion location vs use, I discovered this kind of issue with a z-wave remote: By nature, mesh networks do not cope very well with devices that may be used from different locations.

Non + versions of z-wave were also unable to do remote inclusions (so using nodes able to relay for inclusion): You had to be close to controller... I presume many users still proceed this way + many devices manuals still advice to include near controller.

This post should be at the head of the zwave chapter in the wiki!

Posted: **Thursday 04 February 2021 19:37**

lost wrote: ↑Thursday 04 February 2021 10:53
rrozema wrote: ↑Wednesday 03 February 2021 9:30 the 'heal this device' function (the little +-sign behind each node in the z-wave devices list), can be useful in some situations. Important tip: only click one (1) heal button at a time, after each click wait sufficiently long (at least 5 minutes) before clicking another one.
(...)
it is better to always include new devices at their final location.
Hello,

Interesting comment, but I can see a way for a single node to lean about neighbors from the control panel, but not from device list: Is this a recent feature (I'm still running old-stable v4.10717, with a few http/js fixes, as I was expecting some hazards with the OZW 1.6 switch)?

On device inclusion location vs use, I discovered this kind of issue with a z-wave remote: By nature, mesh networks do not cope very well with devices that may be used from different locations.

Non + versions of z-wave were also unable to do remote inclusions (so using nodes able to relay for inclusion): You had to be close to controller... I presume many users still proceed this way + many devices manuals still advice to include near controller.

This post should be at the head of the zwave chapter in the wiki!

Thanks for the tips, I have tried all the above, now I will try not to use the nightly heal.

So far, I have not read any detailed technical specifications about z-wave. But I thought, that the mesh architecture was all about finding routes to all devices, even if they are out of reach for the main controller. And that the mesh should be able restructure if necessary. But maybe, I misunderstood this and for example relocating a device is something the mesh has difficulties to handle?

Posted: **Friday 05 February 2021 8:54**

rugspin wrote: ↑Thursday 04 February 2021 19:37 I thought, that the mesh architecture was all about finding routes to all devices, even if they are out of reach for the main controller. And that the mesh should be able restructure if necessary.

In my understanding, it's not the case: Routes are completely static if you never heal& you'll never see any topology change. Anyway, remotes could work much better if some kind of broadcast message was supported, but this is IMO not the case. Several messages coming to controller from different routes may also overload the network and need some strategies to reject duplicates... so it's probably, as usual, reserved to network discovery.

Making topology more dynamic would require almost continuous communication between nodes, looks OK for AC plugged modules but for battery ones that are sleeping 99.9% of the day (until they have a status/measure to report) it's not.

=> z-wave (and probably other low-power mesh networks competitors) was more designed as a wired system alternative, with devices location never changed, and energy savings as a constraint.

On my side, I heal 2 times/year: I have all my heating system controlled by several Qubino pilot-wire devices, with heaters (and Qubino modules) disconnected from AC power out of heating season. As these modules are able to relay, I heal network to make sure no battery module will try to use routes that will not work heaters disconnected from AC. And again at reconnect when winter is coming, as some heaters may themselves need relaying and now have no more routes to controller (due to previous heal after disconnect several months before)!

Posted: **Friday 12 February 2021 20:30**

rrozema wrote: ↑Wednesday 03 February 2021 9:30 The neighbours and routes are refeshed when you use the 'heal' functionality. I sugest to stay awaw from the 'heal network' button and the 'nightly heal' option, as these may cause a storm of packages in your z-wave network. In an already overloaded network, this might do more damage than good. But the 'heal this device' function (the little +-sign behind each node in the z-wave devices list), can be useful in some situations. Important tip: only click one (1) heal button at a time, after each click wait sufficiently long (at least 5 minutes) before clicking another one.

In my little z-wave network (only 17 devices: PIRs, relais, wallplugs) the little quirks that I experienced seemed to be related to the "nightly heal". I have disabled it now and for about a week, non of my switches got unresponsive. Let's see. Thanks for the advice!

Posted: **Monday 15 February 2021 14:57**

lost wrote: ↑Friday 05 February 2021 8:54 => z-wave (and probably other low-power mesh networks competitors) was more designed as a wired system alternative, with devices location never changed, and energy savings as a constraint.

Have to agree 100% with this post. I set up my system this way, and all the devices are mains-powered and hardwired to fixed locations. Apart from a couple of device hard failures, I haven't seen any of the problems being reported here. As Lost says there isn't much need to do Network Heals in that situation, and I don't either. My idea is that a ZWave network should try to reach the same level of reliability as the underlying mains power wiring, and shouldn't require much more attention than that gets. Oh, and Domoticz itself has been rock-solid over the last 3 years.

Posted: **Thursday 25 February 2021 19:50**

I'm running the last stable Domoticz Version. OPZW 1.6 is running much better then 1.4. Set it up from Scratch cause switching from Jessie to Buster.

My network includes 94 node's. Half/half Main and Battery powered (Razberry, Fibrao, Aeon, Heimann, Sensative, Steinel, etc). It runs pretty stable now. Only one Issue left, some Fibaro Smoke Detector lost their Connection randomly.

I disabled the nightly heal, cause after a couple of days the hole network slows down and won't react anymore. I always do the single node heal, first all main nodes, then the battery nodes, last the controller.
In the Controller Config you could enable "perform retourn routes". In my understanding this is the option to optmize the network topology constantly.

To perform your System you could also set the Timeout-Time in the Controller Config. I think the default ist 10s. If you get a timeout from a node the controller tries to reach the node for (default) 10s before this message will canceled. All other Network traffic is waiting. My Timeout is 3s.

I have a second Pi with Z-Way installed. So I'm able to mark battery devices as dead. I replace battery Devices with Z-Way cause OPZW can't do it. You also have the opinion to do a Backup of your (Razberry) Controller or Update the Firmware.
If you're running out of Node-ID's because of wrong inclusion or something else, go to Expert View on Z-Way, make a Backup of your Controller, Reset your Controller (no Soft Reset), Restore your Controller with all Opinions. Next time you Include a Node the ID's will fill all gaps. For Example you have node 1,2,4,5 normaly the next included node will get ID6, after backup/reset/restore it will get ID3.

Posted: **Friday 26 February 2021 22:52**

Let me quickly get back to my own topic. I love seeing the responses here! This is exactly the discussion I wanted to get going!

I read through all of the comments, but didn't (and am not going to) reply to all of them. That would be pointless.

However, I think I can draw some preliminary conclusions.

First of all, it seems that the issues that I had a few years ago where mostly caused by my limited understanding of Z-Wave, the nodes and devices. That has improved in the meantime, but most likely I will still make some mistakes.
The more recent issues seem to have been caused for a big part by implementing OPZW 1.6.
I went to the most recent beta and that seems to have helped a lot!
I currently have the nightly heal disabled and that seems to create a way more stable Z-Wave network as well

However, I still do have some weird things/issues going on:

I have one multi sensor that is in the attic and as soon as I place it in the attic, it doesn't properly communicate. So, it seems to be out of range. However, I have two nearby smart Z-Wave wall sockets and the multisensor is connected to both of them. Furthermure, very close to the multi sensor, I have different Z-Wave devices that have no issues whatsoever. How can I force the path over several routes?
I have replaced the batteries of my Fibaro smoke sensors and even though after replacing the batteries the temperature started being reporting immediately and the node was "last seen" a few seconds ago, the battery status was not updated. There is no way to update the battery level.
Today I tried updating from beta 12901 to 13016, but the service got paused and I wasn't able to start the service. Even not after a reboot of the server.
I have set my smoke detectors to give a signal every 10 minutes when the battery is running low. Is it normal that a Fibaro smoke detector then beeps multiple times every 10 minutes? It seems to do 3-5 beeps every 10 minutes.
After a restart (of the Domoticz server or the service) all battery levels are gone.

Posted: **Tuesday 02 March 2021 21:54**

So, I have been looking into this a little bit more...

The multi sensor in the attic is a Aeotec DSB05 Multisensor. If I look at the network diagram it is connected to two other nodes: 159 and 158. 158 is a Coolcam smart plug on the second floor. And 159 is a Coolcam smart plug also in the attic, pretty close to the multi sensor. 159 is directly connected to the controller, 158 is not.
Strange enough: if I move the multisensor to the second floor, it does work. As soon as I have it in the attic (where I have quite some more Z-Wave devices) it doesn't work.
How can I force it to use 159 only? I think that should solve the issue.

I am still struggling with updating the battery levels of the Fibaro Smoke detectors. They seem to be only updated after a restart of the Domoticz service or after a network heal. Any idea? Other devices also have a hard time updating the battery level, but the smoke detectors seem to be the worst.

Found out why the newer beta versions don't start the service: that is caused by the Domoticz Windows log file. As long as I don't set that I'm good to go. And currently I am on 13034

Posted: **Wednesday 03 March 2021 19:26**

Plantje wrote: ↑Tuesday 02 March 2021 21:54
I am still struggling with updating the battery levels of the Fibaro Smoke detectors. They seem to be only updated after a restart of the Domoticz service or after a network heal. Any idea? Other devices also have a hard time updating the battery level, but the smoke detectors seem to be the worst.

I’ve a FIBARO System FGSD002 Smoke Sensor+ which give a battery status of 100% for almost 2 years
Very energy efficient device or no updates

Posted: **Wednesday 03 March 2021 20:27**

I suspect the latter

Because it works the other way around as well: as soon as battery level IS reported and it is low and I replace the battery the level stays at the low level it had before replacing the battery.
Especially when the level was this low that it started beeping indicating a low battery level and I replace the battery, it stops beeping but the level stays as low as it was. So, it KNOWS it has a fresh battery, but it doesn't report that.

I do confess, I am using rechargeable batteries. I don't think it is an issue to replace the battery with a full charged one every so often. However, if the battery level is not reported correctly, it can happen (and did happen) that a smoke detector hasn't been working for days without me knowing it.

Posted: **Thursday 04 March 2021 8:32**

madpatrick wrote: ↑Wednesday 03 March 2021 19:26 I’ve a FIBARO System FGSD002 Smoke Sensor+ which give a battery status of 100% for almost 2 years
Very energy efficient device or no updates

Quite strange: I have 2 FGSD002 that reports battery level as expected. But not for every "sub-devices". If device zwave node ID is 0xNN for instance, on my side I use "sub-devices" 0000NN29 and 0000NN2C respectively for smoke and temperature alarms. These switches have battery level reports.

If you use those, maybe something to check with configuration or association groups (my devices groups 4 and 5, fire-alarm&tamper, are associated to node 1/controller, don't remember if this was done automatically at inclusion or by hand).

Posted: **Saturday 06 March 2021 15:05**

Interesting....Some weird stuff again...
Battery levels stay at 100% Then, all of a sudden, a device starts beeping and in Domoticz it is notified as 0%
Replace the battery and the beeping stops. However, the battery level in Domoticz stays at 0%

The devices start reporting temperature again and everything seems just fine! It's just that the battery level is not updated.

For another device this was 70% and currently it is on 70% for days

So, I am still looking for ways to push or pull the battery level of a 1st gen Fibaro smoke sensor. How can this be done?

Posted: **Wednesday 10 March 2021 14:26**

Well.... had some false positives on my smoke detectors. And still the issue that the batteries stick at 100% and then run to 0 in no time. Another question: why does that always happen at night?!?

I think enabling the nightly network heal may solve something there.

Related: yes, I am still very happy with the "Refresh node info" option as it seems to be the only thing that works so far. However.... after using it the node I used it on must be refreshed. If not....the only thing that helps is restart the Domoticz service or even the whole server. This seems to happen if I click the button for a node and then (before the node info is refreshed) click the button for another node. However, sometimes refreshing of the node info doesn't seem to start. What can be done about this?

Posted: **Thursday 11 March 2021 10:58**

Ok, currently I am on 13064 and I am seeing the same issue as with 13051 there is a sh*t load of messages like these coming along:
OpenZWave: Invalid counter value received

This is to a point where I think logging the errors starts hindering normal operation. I have some scripts that use values of a multi sensor, but the lights connected to the script just stay on. No matter what I change to the script.

I know this is related to "cheap Chinese nodes", but it is weird that all of a sudden it pops up and it may all of a sudden be gone again. Let's see if version 13034 doesn't throw those errors.

Posted: **Thursday 11 March 2021 11:03**

Plantje wrote: ↑Thursday 11 March 2021 10:58 Ok, currently I am on 13064 and I am seeing the same issue as with 13051 there is a sh*t load of messages like these coming along:
OpenZWave: Invalid counter value received

This is to a point where I think logging the errors starts hindering normal operation. I have some scripts that use values of a multi sensor, but the lights connected to the script just stay on. No matter what I change to the script.

I know this is related to "cheap Chinese nodes", but it is weird that all of a sudden it pops up and it may all of a sudden be gone again. Let's see if version 13034 doesn't throw those errors.

I have a lot of these messages:

Code: Select all

 Error: OpenZWave: Invalid counter value received!: (-21474770.000000) Node: 15 (0x0f), CommandClass: METER, Instance: 1, Index: 0, Id: 0xF4C8012

They are related to a neo coolcam z-wave powerswitch. I have multiple, but this one is a newer version, which randomly sends wrong data. It just the cheap ass Neo Coolcam that's doing this. Nothing wrong with the z-wave implementation in domoticz.

Domoticz

Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!

Re: Fixing Z-Wave for once and for all!