Fixing Z-Wave for once and for all!

[akamming]

Hi plantje, just read these messages.

1. I think problem 1 in your network is the use of a lot of neo coolcam. I myself also had a very unstable zwave network. Switched on debug logging and reported on openwave.com which was analyzed by the developers over there: Conclusion: if you have a few of these it will work fine, but they send way too much traffic, flooding the netwerk if you have more of them and causing all kinds of instability cause messages on the Zwave network get lost. This will also cause problems when doing an upgrade: Because the deivce config has to be recommunicated and a lot of messages will not reach their destination due to the flooding.

In my case my network got much stabler when i started replacing the neocoolcams ny more expensive hardware.

You would have had the same problem on OpenZwave 1.4 if you would throw away the cache file, then probably your network config never gets rebuilt completely, but probably never encountered this, cause this normally does not happen.

This also explains issues with parameters not set correctly in domoticz, cause messages get lost disturbing synchronisation.

2. what you could do as a workaround, till you got rid of the cheap chinese hardware: For every device which does not have a correct config in the hardware screen:
- Do a node refresh and wait a few minutes to see if the config is fixed. due to the probably flooding in your network you might have to do this a few times before they start working
- if the node is battery powered: after the "node refresh"
still: don't expect a very stable network, you have too much traffic on your network due to the many neo coolcams.

3. don't add/remove hardware to get it working: node refresh does the same thing and every time you reinclude you will add up the node number by 1 (and you only have 255 max). As an alternative you could do a factory reset on the node and do "replace failed node". This will also newly reinclude your device, but also reuse the same node number

Good luck!

[Plantje]

I am running 2020.2 in a recent beta and things seem pretty much ok as well. The suggestion that @roblom came with seems to be one of the first things that really work! This seems to be the "super reset" of a node that I have been looking for!
Just noticed that the "Refresh node info" is displayed as follows in the logging:

Code: Select all

2021-01-18 20:32:49.780 Status: OpenZWave: Node Removed. HomeID: 3833672857, NodeID: 182 (0xb6)
2021-01-18 20:32:59.842 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 182 (0xb6)

So, it actually removes and re adds the node!
As stated before: with previous versions there were also Z-Wave issues.
I have the nightly heal of the network enabled as well.

In general, I do see a lot of people pointing out that more expensive hardware seems to be causing less issues. Fortunately, that means it most likely can be solved. Unfortunately it most likely means it will be more expensive. And since the WAF is at an all time low....

@plantje, as stated above use ‘refresh node info’ instead of re-adding nodes again and again.

Yes, best suggestion so far!

Z-wave nodes are communicating not in real-time but using certain intervals depending on the device capabilities. Some nodes ‘sleep’ for an hour or even longer before they wake-up again and send signals or listen for incoming messages before going into sleep again.

The ‘refresh node’ is a message to a node to ask for a full report of config and data, so when receiving this message the node should send all its data and config. Normally it just sends some parts.

And it does so at the wake up interval.

And as some nodes can actually have multiple ‘sensors’/function that might even communicate in different intervals (for example, send temperature every 5 mins or only when a changes of 1 degree or more has been measures or send the battery status once a day,etc.). This is why you see that sometimes one ‘sensor’ is updated while others of the same node are not.

Yes, I am aware of that. So, I know that for example the heat or smoke detection of a smoke detector can be last seen on the moment I included the device (which is actually a good thing ) And the temperature detection can be seen minutes ago. And I am also aware that if you adjust the interval for reporting temperature to over an hour, Domoticz will show it as "not connected" or "in error", but it is just the setting.

Keep the above in mind when debugging issues. Things might work/behave differently than you might expect. That does not mean they do not work correctly.

What worries me here is for example when I set some parameter like the temperature to be sent every five minutes and with a temperature hysteris of 0.1 C and I see the device in the node list last seen a few seconds ago and the temperature is not being reported on at all.
Or a motion sensor that I have set to detect motion, I see it detect the motion and I see it reporting other values every 5 minutes, but the motion can be not sent to the Domoticz server for hours.

But you have a fair point... there have also been occasions where I thought things were not working correctly, but it was just me setting the wrong parameters. What doesn't help there is that I had numurous times where the parameters had been set to default without me touching them. I hope that is fixed with this beta!

Hmmmm.... there is one other thing I need to figure out: if I revive one node, select the next one and perform the same action, Domoticz becomes non responding. Let's see how this can be fixed.

Yeah, I've seen this, too. I was thinking of looking for the cause, but never got around to it, and since then I've just made it a habit to never do a "Refresh node info" on multiple nodes. Start it on one, wake up that node if it's battery powered, verify the result, then do the next one.

Unfortunately, I just had this again. I revived about 4 nodes correctly, then did a 5th one (checked if the 4th got online first) and the Domoticz machine got stuck again. Restarted the Domoticz service and that is now fixed, but it takes quite a while for all nodes to be initialized again! And now I can only hope the battery indication will return in a while as well!

Hi plantje, just read these messages.

Thanks! I really appreciate people reading through the messages and taking the time toe respond to things!

1. I think problem 1 in your network is the use of a lot of neo coolcam. I myself also had a very unstable zwave network. Switched on debug logging and reported on openwave.com which was analyzed by the developers over there: Conclusion: if you have a few of these it will work fine, but they send way too much traffic, flooding the netwerk if you have more of them and causing all kinds of instability cause messages on the Zwave network get lost. This will also cause problems when doing an upgrade: Because the deivce config has to be recommunicated and a lot of messages will not reach their destination due to the flooding.

Hmmm.... would they also be willing to analyze my data?
I do see a lot of these:
2021-01-18 20:24:23.353 Status: OpenZWave: Alarm received (Home Security: Motion Detected at Unknown Location), NodeID: 188 (0xbc)
which seem to be coming from the Coolcam PIRs. I am not sure how to disable that. If I disable motion detection, they stop detecting motion all together (obviously). I want them to detect motion, but not to send an alarm of that every few miliseconds!

And I do see a lot of these as well:

Code: Select all

2021-01-18 20:09:28.680 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 183 (0xb7)
2021-01-18 20:09:29.686 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 185 (0xb9)
2021-01-18 20:09:56.234 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 187 (0xbb)
2021-01-18 20:10:22.248 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 189 (0xbd)
2021-01-18 20:10:23.270 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 191 (0xbf)
2021-01-18 20:10:24.292 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 192 (0xc0)
2021-01-18 20:10:51.882 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 167 (0xa7)
2021-01-18 20:11:04.722 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 170 (0xaa)
2021-01-18 20:11:05.729 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 170 (0xaa)
2021-01-18 20:11:06.734 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 172 (0xac)
2021-01-18 20:11:07.758 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 172 (0xac)
2021-01-18 20:11:45.004 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 183 (0xb7)
2021-01-18 20:11:46.041 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 183 (0xb7)
2021-01-18 20:12:38.185 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 189 (0xbd)
2021-01-18 20:12:49.494 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 111 (0x6f)
2021-01-18 20:12:50.500 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 111 (0x6f)
2021-01-18 20:13:21.232 Status: OpenZWave: Received timeout notification from HomeID: 3833672857, NodeID: 122 (0x7a)

These come from all sorts and brands of devices! Aeotec, Fibaro, Coolcam, Greenwave, battery powered, not battery powered...

In my case my network got much stabler when i started replacing the neocoolcams ny more expensive hardware.

So, you only have Fibaro stuff now?

You would have had the same problem on OpenZwave 1.4 if you would throw away the cache file, then probably your network config never gets rebuilt completely, but probably never encountered this, cause this normally does not happen.

This I do not completely get.... what do you mean with "this" in the above context? Are you referring to the screen shot from my post on Friday 15 January at 21:42? That was just a one time occurrence. I have never had that. The other issues of my opening post occur way more often.

This also explains issues with parameters not set correctly in domoticz, cause messages get lost disturbing synchronisation.

This I can understand. I also have the impression that if Domoticz starts logging a lot of errors (for example because I have made a mistake in a script) the entire server goes south and a lot of stuff stops working properly. Still the machine has way sufficient resources left!

2. what you could do as a workaround, till you got rid of the cheap chinese hardware: For every device which does not have a correct config in the hardware screen:
- Do a node refresh and wait a few minutes to see if the config is fixed. due to the probably flooding in your network you might have to do this a few times before they start working

With "node refresh" you mean the suggestion that Roblom gave, right? (Select the node in the OZW control panel, select "Refresh Node Info" and click "Go")
Because, if you mean hit the "plus sign" ("herstel node" in my case) behind the node in the Z-Wave node list: that has never done anything for me.

- if the node is battery powered: after the "node refresh"
still: don't expect a very stable network, you have too much traffic on your network due to the many neo coolcams.

Funny enough: it is one Fibaro smoke sensor that doesn't seem to adhere to the "Refresh Node Info" process. It continous to display as "routing sensor"

3. don't add/remove hardware to get it working: node refresh does the same thing and every time you reinclude you will add up the node number by 1 (and you only have 255 max). As an alternative you could do a factory reset on the node and do "replace failed node". This will also newly reinclude your device, but also reuse the same node number

Euh.... and what will happen if I do reach 255? I'm currently at 192. Will it just not enable me to add a new node? Is there no way to reset this counter?!?

Good luck!

Thanks! Very helpful!

Wondering if everyone not having issues is only using more expensive devices and people with issues are using inexpensive devices.

Also wondering in what category Aeotec falls as it seems to be in between Fibaro and Coolcam.

[madpatrick]

Plantje,

I’m using Fibaro, Neo, z-waveme and Everspring.
Maybe lucky, but my system is running stable.
The message

Code: Select all

 OpenZWave: Alarm received (Home Security: Motion Detected at Unknown Location)

is alo in my logs
When google this, there no real solution. Therefor i ignore this

Hopely this will help you.
If you any specific info, let me know

[Plantje]

Thanks again!

Well... I just noticed the following buttons in my node list:

Refresh nodes.jpg (9.14 KiB) Viewed 3796 times

I guess that does the same...
Perhaps something new in my current beta as I have never seen it before.

[akamming]

Thanks again!

Well... I just noticed the following buttons in my node list:
Refresh nodes.jpg
I guess that does the same...
Perhaps something new in my current beta as I have never seen it before.

Yep, this is what it was referring to and also make sure a node is dead before you do a replace failed node.

i have bad experience using the ozw control panel, makes domoticz unstable.

Hmmm.... would they also be willing to analyze my data?
I do see a lot of these:
2021-01-18 20:24:23.353 Status: OpenZWave: Alarm received (Home Security: Motion Detected at Unknown Location), NodeID: 188 (0xbc)
which seem to be coming from the Coolcam PIRs. I am not sure how to disable that. If I disable motion detection, they stop detecting motion all together (obviously). I want them to detect motion, but not to send an alarm of that every few miliseconds!

And I do see a lot of these as well:

you could check over there, but probably get the same anwser i got., what you mention here is a typical example of the network flooding i was talking about. A PIR should not send messages every few milliseconds. you could try adjusting the config parameters of this node, see if it stops. If not. Replace the node
some timeouts can be there, but if you have a lot of them it is also an indication that not all message can be delivered (which might be causes by network flooding, so fix that 1st)

So, you only have Fibaro stuff now?

no i have a mix of several brands. a few neo coolcam still left. when i switch on debug logging i see there are still communicating a lot, but with only a few my network is not flooded. Will replace them in time.

brands which gave me problems were tkbhome, neo coolcam and heimann (although the smoke sensors seem to be ok, still have those)

This I do not completely get.... what do you mean with "this" in the above context? Are you referring to the screen shot from my post on Friday 15 January at 21:42? That was just a one time occurrence. I have never had that. The other issues of my opening post occur way more often.

No, what i'm referring to is the rebuilding of the ozwcache file. When domoticz has all the info in the cache, not a lot of messages are sent during startup (because it has all the node info in a cache). If the cache is not there, domoticz has to rebuild it. in a non flooded network with correct hardware rebuilding the cause no problems and even battery powered devices will have the correct config after several hours. So no manual work needed.
In a flooded network,messages get lost and this will fail cause problems.

I only know of 2 instances where the cache is rebuilt
1. Remove the ozwcache.xml file before start of domoticz
2. upgrade to 1.6

With "node refresh" you mean the suggestion that Roblom gave, right? (Select the node in the OZW control panel, select "Refresh Node Info" and click "Go")
Because, if you mean hit the "plus sign" ("herstel node" in my case) behind the node in the Z-Wave node list: that has never done anything for me.

no .. don't use ozwcp, this will make domoticz unstable. See mark remark above

Euh.... and what will happen if I do reach 255? I'm currently at 192. Will it just not enable me to add a new node? Is there no way to reset this counter?!?

as far as i know you have to factory reset your controller and start all over again. I am also already at 182, so if someone knows a better trick i'd like to hear it...

Also wondering in what category Aeotec falls as it seems to be in between Fibaro and Coolcam.

works fine in my network

[lost]

In my case my network got much stabler when i started replacing the neocoolcams ny more expensive hardware.

Take care that some Neo devices does not looks to have adequate battery management: I have 3 PIRs from them and I don't let them go under 30% reported battery.

Reason: All of them become "fool" between 20 and 30% and send messages almost constantly, even false movement detection. They are just running out of power (confirmed by battery voltage check) even if report still looks good & they does not just go offline until replacement but let their underpowered electronics go mad...

I also have 3 water flood detectors from them, but they were installed more recently so cannot say if they'll show same behavior. Anyway, if I have one reporting ~30% battery just before leaving home for some vacations I'll change the battery before!

[heggink]

Some of these neo pir's are indeed really bad to the degree that I decided to just throw away any of them that gave false alarms even after battery replacement. I have 1 or 2 left but suspect these will go soon as well. Shame. That said, I also have other brands that broke after a while (popp high power plug, everspring plug). The fact that the underlying technology is based on zwave (and associated price) by no means means that the quality is good...

Sent from my SM-G980F using Tapatalk

[ArnoutZ]

As some people seem to have less issues with Z-wave, are you guys running the latest offical Domoticz version 2020.2.11995 or a newer beta version?

[rgroothuis]

I'm running this Domoticz version (see below) with mainly (only) Fibaro devices and have no issues.

Screenshot 2021-01-19 at 11.48.41.png (130.25 KiB) Viewed 3738 times

[Plantje]

I am currently running 2020.2.0.12825 and it seems like a breeze. Especially with the option to refresh the node info!

[hestia]

I installed 2020.2 (build 12819) 2 weeks ago, it seems that my motion detectors are running better. Before I was losing them from time to time.
So it is better than ever
I need more time to be sure that my devices are not going to die or sleep to much...
But... I still have an old issue that annoy me
viewtopic.php?f=6&t=27607]XXX.silent no ... ve devices even if it seems that it is more a z-wave issue than a dzvents issue!
To summarize it, when I switch on a device in silent mode switchOn().silent() there is in fact a trigger, sometime!
The same with off!
Not only, there is a trigger, but sometimes in reserve: Off when On or On when Off
The scripts to tests it on your side

Code: Select all

local LIGHTS = {1310, 645, 1008, 478, 112, 453}
--to use w zTestTriggered

return {
    on = {timer   = { "every minute" },
         },
      logging =   { 	level = domoticz.LOG_INFO,
 },    

    execute = function(dz, item)
        _G.logMarker =  dz.moduleLabel -- set logmarker to scriptname  
        local LOG_LEVEL = dz.LOG_FORCE  -- LOG_INFO, LOG_DEBUG, LOG_ERROR, LOG_FORCE  - normal = LOG_INFO
        local zwaveDevice
        for i1, l1 in ipairs(LIGHTS) do
            zwaveDevice = dz.devices(l1)
            --dz.log(i1 .. ' Device '.. zwaveDevice.name .. " (" .. zwaveDevice.id .. ")" , dz.LOG_DEBUG)
            --dz.log(tostring(zwaveDevice.active) , dz.LOG_DEBUG)
            if not zwaveDevice.active then
                --zwaveDevice.switchOn().silent().afterSec(i1)
            dz.log('Device '.. zwaveDevice.name .. " : " .. zwaveDevice.id .. " : " ..  zwaveDevice.state .. " to ON", LOG_LEVEL)
            else
                zwaveDevice.switchOff().silent().afterSec(i1)
                dz.log('Device '.. zwaveDevice.name .. " : " .. zwaveDevice.id .. " : " ..  zwaveDevice.state .. " to OFF", LOG_LEVEL)
            end

            --dz.log('value of dz.LOG_MODULE_EXEC_INFO: ' .. tostring(dz.LOG_MODULE_EXEC_INFO),dz.LOG_FORCE)
            --dz.log('value of triggeredItem.lastUpdate.utils.LOG_MODULE_EXEC_INFO: ' .. tostring(item.lastUpdate.utils.LOG_MODULE_EXEC_INFO),dz.LOG_FORCE)
        end

    end
} 

and

Code: Select all

local LIGHT = {1310, 645, 1008, 478, 112, 453}
return {
    logging = {level = domoticz.LOG_DEBUG,
	},
	on = {
		devices = LIGHT
	},
	execute = function(dz, device)
    _G.logMarker =  dz.moduleLabel -- set logmarker to scriptname  
    local LOG_LEVEL = dz.LOG_DEBUG  -- LOG_INFO, LOG_DEBUG, LOG_ERROR, LOG_FORCE  - normal = LOG_INFO
    
    --dz.log('Device ' .. dz.devices(LIGHT).id .. ' ' ..  dz.devices(LIGHT).name .. '  '.. dz.devices(LIGHT).state .. ' ' .. dz.devices(LIGHT).deviceType, dz.LOG_ERROR)
	
	dz.log('Device TRIGGERED ' .. device.id .. ' ' ..  device.name .. '  '.. device.state .. ' ' .. device.deviceType, dz.LOG_ERROR)

	end
}

Code: Select all

21:29:00 dzVents: !Info: zTestOnOffSilent: Device Montage Test : 1310 : On to OFF
21:29:01 dzVents: Error: (3.1.0) zTestTriggered: Device TRIGGERED 1310 Montage Test  On Light/Switch

Am I the only one with this behavior?

[kiddigital]

As some people seem to have less issues with Z-wave, are you guys running the latest offical Domoticz version 2020.2.11995 or a newer beta version?

In the latest Beta’s a number of improvements regarding Z-wave have been made and I would suggest to use these latest beta’s when trying to solve Z-wave issues.

But as these are beta’s, there is always a risk that something is not 100%. Give it a try and it is always a good idea to have backups before you upgrade.

[poweredge]

just a short compliment for the topic - following it as well - here i -had- multiple issues with zwave / mix of qubino/aeotec/neocoolcam/eurotronic zwave...what helped here - moving the zwave stick (g5) 30cm ... now the platform runs (dm 2020.2 stable) almost perfect (i use a slave with the zwave stick to have it positioned centrally in the house, the master == the scene/programming hub).

[Plantje]

Thanks again!

Well... I just noticed the following buttons in my node list:
Refresh nodes.jpg
I guess that does the same...
Perhaps something new in my current beta as I have never seen it before.

Yep, this is what it was referring to and also make sure a node is dead before you do a replace failed node.

i have bad experience using the ozw control panel, makes domoticz unstable.

To be honest, I think the button in the bottom of the node list has somewhat the same effect as the trick in the OZW CP (if not exactly the same)

If I hit the button once and are unable to wake up the device or the device doesn't communicate with the controller, then I should not hit the button one more time, because then Domoticz becomes unstable as well.
This is still pretty tricky as it is hard to see if handling a trigger of the button is still in progress or not.

For example, at the moment I have one Aeotec multi sensor that I had revived using this magic button, but now it doesn't come back to life. I am not sure how long I should wait. I have pushed the button and next pressed the inclusion button on the device for 3 seconds.
Still it shows as "Routing Binary Sensor"
If I look at the diagram I see the following:

Diagram.jpg (60.38 KiB) Viewed 3639 times

This tells me the sensor (Zolder) is connected to two power plugs (159 and 158), that seems fine. However, neither of those two is connected directly to the controller!
To make things worse: 159 is connected to another power node that isn't directly connected to the controller as well.
158 finally is connected to another power node that IS connected to the controller.

I have the impression that if I were able to steer this mapping more, I would be able to get a more stable Z-Wave network. Because now I have the idea that the multi sensor "thinks": "Well, that's nice, I am connected to 159, which is a continously powered device, that's where I am going to get my info!" But just like that the line from the controller to 159 might break as well

Hmmm.... would they also be willing to analyze my data?
I do see a lot of these:
2021-01-18 20:24:23.353 Status: OpenZWave: Alarm received (Home Security: Motion Detected at Unknown Location), NodeID: 188 (0xbc)
which seem to be coming from the Coolcam PIRs. I am not sure how to disable that. If I disable motion detection, they stop detecting motion all together (obviously). I want them to detect motion, but not to send an alarm of that every few miliseconds!

And I do see a lot of these as well:

you could check over there, but probably get the same anwser i got., what you mention here is a typical example of the network flooding i was talking about. A PIR should not send messages every few milliseconds. you could try adjusting the config parameters of this node, see if it stops. If not. Replace the node
some timeouts can be there, but if you have a lot of them it is also an indication that not all message can be delivered (which might be causes by network flooding, so fix that 1st)

I have Googled this a little bit and it seems that this is occurring for all sorts of motion sensors since people have switch to OZW 1.6

No, what i'm referring to is the rebuilding of the ozwcache file. When domoticz has all the info in the cache, not a lot of messages are sent during startup (because it has all the node info in a cache). If the cache is not there, domoticz has to rebuild it. in a non flooded network with correct hardware rebuilding the cause no problems and even battery powered devices will have the correct config after several hours. So no manual work needed.
In a flooded network,messages get lost and this will fail cause problems.

I only know of 2 instances where the cache is rebuilt
1. Remove the ozwcache.xml file before start of domoticz
2. upgrade to 1.6

And in OZW 1.6 the cache file is removed and rebuilt on every startup of the controller software? (Domoticz in our case...)
So, every time my Domoticz becomes unstable because I am fiddling to much around with the refresh node info option, I restart the Domoticz server and the file is completely rebuilt?

Euh.... and what will happen if I do reach 255? I'm currently at 192. Will it just not enable me to add a new node? Is there no way to reset this counter?!?

as far as i know you have to factory reset your controller and start all over again. I am also already at 182, so if someone knows a better trick i'd like to hear it...

Well let's wait and see. Factory resetting the controller would not be that bad after years of usage... For now I am not going to remove and re-add devices anymore.

Also wondering in what category Aeotec falls as it seems to be in between Fibaro and Coolcam.

works fine in my network

Good to hear!

Take care that some Neo devices does not looks to have adequate battery management: I have 3 PIRs from them and I don't let them go under 30% reported battery.

Reason: All of them become "fool" between 20 and 30% and send messages almost constantly, even false movement detection. They are just running out of power (confirmed by battery voltage check) even if report still looks good & they does not just go offline until replacement but let their underpowered electronics go mad...

I also have 3 water flood detectors from them, but they were installed more recently so cannot say if they'll show same behavior. Anyway, if I have one reporting ~30% battery just before leaving home for some vacations I'll change the battery before!

Thanks for the tip!

I installed 2020.2 (build 12819) 2 weeks ago, it seems that my motion detectors are running better. Before I was losing them from time to time.
So it is better than ever
I need more time to be sure that my devices are not going to die or sleep to much...

Currently they're on 12865 and although I can read the changelog it is hard to see what changed in what beta version. Is it possible to see somewhere what the difference between versions 12825 and 12865?

But... I still have an old issue that annoy me
viewtopic.php?f=6&t=27607]XXX.silent no ... ve devices even if it seems that it is more a z-wave issue than a dzvents issue!
To summarize it, when I switch on a device in silent mode switchOn().silent() there is in fact a trigger, sometime!
The same with off!
Not only, there is a trigger, but sometimes in reserve: Off when On or On when Off
The scripts to tests it on your side

Code: Select all

local LIGHTS = {1310, 645, 1008, 478, 112, 453}
--to use w zTestTriggered

return {
    on = {timer   = { "every minute" },
         },
      logging =   { 	level = domoticz.LOG_INFO,
 },    

    execute = function(dz, item)
        _G.logMarker =  dz.moduleLabel -- set logmarker to scriptname  
        local LOG_LEVEL = dz.LOG_FORCE  -- LOG_INFO, LOG_DEBUG, LOG_ERROR, LOG_FORCE  - normal = LOG_INFO
        local zwaveDevice
        for i1, l1 in ipairs(LIGHTS) do
            zwaveDevice = dz.devices(l1)
            --dz.log(i1 .. ' Device '.. zwaveDevice.name .. " (" .. zwaveDevice.id .. ")" , dz.LOG_DEBUG)
            --dz.log(tostring(zwaveDevice.active) , dz.LOG_DEBUG)
            if not zwaveDevice.active then
                --zwaveDevice.switchOn().silent().afterSec(i1)
            dz.log('Device '.. zwaveDevice.name .. " : " .. zwaveDevice.id .. " : " ..  zwaveDevice.state .. " to ON", LOG_LEVEL)
            else
                zwaveDevice.switchOff().silent().afterSec(i1)
                dz.log('Device '.. zwaveDevice.name .. " : " .. zwaveDevice.id .. " : " ..  zwaveDevice.state .. " to OFF", LOG_LEVEL)
            end

            --dz.log('value of dz.LOG_MODULE_EXEC_INFO: ' .. tostring(dz.LOG_MODULE_EXEC_INFO),dz.LOG_FORCE)
            --dz.log('value of triggeredItem.lastUpdate.utils.LOG_MODULE_EXEC_INFO: ' .. tostring(item.lastUpdate.utils.LOG_MODULE_EXEC_INFO),dz.LOG_FORCE)
        end

    end
} 

and

Code: Select all

local LIGHT = {1310, 645, 1008, 478, 112, 453}
return {
    logging = {level = domoticz.LOG_DEBUG,
	},
	on = {
		devices = LIGHT
	},
	execute = function(dz, device)
    _G.logMarker =  dz.moduleLabel -- set logmarker to scriptname  
    local LOG_LEVEL = dz.LOG_DEBUG  -- LOG_INFO, LOG_DEBUG, LOG_ERROR, LOG_FORCE  - normal = LOG_INFO
    
    --dz.log('Device ' .. dz.devices(LIGHT).id .. ' ' ..  dz.devices(LIGHT).name .. '  '.. dz.devices(LIGHT).state .. ' ' .. dz.devices(LIGHT).deviceType, dz.LOG_ERROR)
	
	dz.log('Device TRIGGERED ' .. device.id .. ' ' ..  device.name .. '  '.. device.state .. ' ' .. device.deviceType, dz.LOG_ERROR)

	end
}

Code: Select all

21:29:00 dzVents: !Info: zTestOnOffSilent: Device Montage Test : 1310 : On to OFF
21:29:01 dzVents: Error: (3.1.0) zTestTriggered: Device TRIGGERED 1310 Montage Test  On Light/Switch

Am I the only one with this behavior?

To be completely honest, this seems to be something pretty much different from what I am trying to discuss here.

As some people seem to have less issues with Z-wave, are you guys running the latest offical Domoticz version 2020.2.11995 or a newer beta version?

In the latest Beta’s a number of improvements regarding Z-wave have been made and I would suggest to use these latest beta’s when trying to solve Z-wave issues.

But as these are beta’s, there is always a risk that something is not 100%. Give it a try and it is always a good idea to have backups before you upgrade.

Yes, I am really happy I moved to the latest beta! It really seems to be a huge improvement! That combined with the "super reset" option of a node that has been explained to me.

just a short compliment for the topic - following it as well -

Well thank you! Hope this doesn't only help me, but other people as well!

here i -had- multiple issues with zwave / mix of qubino/aeotec/neocoolcam/eurotronic zwave...what helped here - moving the zwave stick (g5) 30cm ... now the platform runs (dm 2020.2 stable) almost perfect (i use a slave with the zwave stick to have it positioned centrally in the house, the master == the scene/programming hub).

I have my Domoticz server close to my smart meter, so not in an ideal central place in the house.

Currently what still seems to be causing some issues is the fact that some of the network routes are suboptimal. I am wondering if a dedicated Z-Wave amplifier/range extender would have advantages over buying some additional power plugs. Anyone an idea?

[Plantje]

One addition that I think is interesting...
So, I pushed the "super reset" (Refresh node info) for the multi sensor (ID 161) and tried to wake the device. Nothing seemed to be happening.
So after an hour or so, I pushed the button for a smoke detector in the garage (ID 185). And yes.... my Domoticz became unstable again!

This is the logging after a restart of the service:

Code: Select all

2021-01-20 22:31:14.382 Status: Domoticz V2020.2 (build 12825) (c)2012-2021 GizMoCuz
2021-01-20 22:31:14.382 Status: Build Hash: 5befa3819, Date: 2021-01-06 08:22:38
2021-01-20 22:31:14.382 Status: Startup Path: C:\Program Files\Domoticz\
2021-01-20 22:31:15.120 Status: PluginSystem: Started, Python version '3.8.6'.
2021-01-20 22:31:15.167 Status: WebServer(HTTP) started on address: :: with port 8080
2021-01-20 22:31:15.231 Status: WebServer(SSL) started on address: :: with port 443
2021-01-20 22:31:15.231 Status: Camera: settings (re)loaded
2021-01-20 22:31:15.231 Status: TCPServer: shared server started...
2021-01-20 22:31:15.247 Status: RxQueue: queue worker started...
2021-01-20 22:31:17.262 Status: P1 Smart Meter: Using serial port: COM7
2021-01-20 22:31:17.262 Status: RFXCOM: Worker started...
2021-01-20 22:31:17.277 Status: (deConz) Started.
2021-01-20 22:31:17.277 Status: P1 Smart Meter: Worker started...
2021-01-20 22:31:17.277 Status: Tesla: Using Domoticz home location (Lat 52.48552, Lon 6.10474) as car's home location.
2021-01-20 22:31:17.277 Status: (Toon) Started.
2021-01-20 22:31:17.277 Status: Tesla: Worker started...
2021-01-20 22:31:17.277 Status: NotificationSystem: thread started...
2021-01-20 22:31:17.277 Status: EventSystem: reset all events...
2021-01-20 22:31:17.292 Status: EventSystem: reset all device statuses...
2021-01-20 22:31:17.605 Status: PluginSystem: Entering work loop.
2021-01-20 22:31:17.764 Status: OpenZWave: using config in: C:\Program Files\Domoticz\Config/
2021-01-20 22:31:17.982 Status: OpenZWave: Starting...
2021-01-20 22:31:17.982 Status: OpenZWave: Version: 1.6.1528.gafc0ecc0.dirty
2021-01-20 22:31:18.283 Status: RFXCOM: Using serial port: COM6
2021-01-20 22:31:20.071 Status: P1 Smart Meter: Meter reports as DSMR 4.2
2021-01-20 22:31:21.153 Status: P1 Smart Meter: Found gas meter on M-Bus channel 1
2021-01-20 22:31:22.270 Status: Tesla: Car awake detection: Car awake
2021-01-20 22:31:24.013 Status: Tesla: Executing command: Get All states
2021-01-20 22:31:25.143 Status: (deConz) Entering work loop.
2021-01-20 22:31:25.143 Status: (deConz) Initialized version 1.0.15, author 'Smanar'
2021-01-20 22:31:33.341 Status: (Toon) Entering work loop.
2021-01-20 22:31:33.341 Status: (Toon) Initialized version 1.3.1, author 'John van de Vrugt'
2021-01-20 22:31:33.466 Status: Python EventSystem: Initalizing event module.
2021-01-20 22:31:33.466 Status: EventSystem: Started
2021-01-20 22:31:33.466 Status: EventSystem: Queue thread started...
2021-01-20 22:31:44.955 Status: (deConz) Firmware version : 0x26350500
2021-01-20 22:31:44.955 Status: (deConz) Websocketnotifyall : True
2021-01-20 22:31:45.048 Status: (deConz) ### deCONZ ready
2021-01-20 22:31:45.048 Status: (deConz) ### Found 14 Operators, 3 Sensors, 4 Groups, 0 Scenes and 0 others, with 0 Ignored
2021-01-20 22:31:45.048 Status: (deConz) ### Device GROUP_All(deConz - All) Not in deCONZ ATM, the device is deleted or not ready.
2021-01-20 22:31:45.048 Status: (deConz) ### Device 14:b4:57:ff:fe:68:5a:0a(deConz - TRADFRI motion sensor ) Not in deCONZ ATM, the device is deleted or not ready.
2021-01-20 22:31:45.111 Status: (deConz) Launching websocket on port 8088
2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.233 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.233 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.234 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.234 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.234 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.234 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.234 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.249 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.376 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.533 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:47.533 Status: OpenZWave: ManufacturerSpecificDB Ready
2021-01-20 22:31:55.448 Status: OpenZWave: Driver Ready
2021-01-20 22:31:55.526 Status: SendSwitchIfNotExists: Device '111.instance.1.index.256.commandClasses.113' (Previous Event Cleared) with DeviceID '00006F00' matches '111.instance.1.index.0.commandClasses.48' (Sensor). Domoticz will use the Dimmer (and hide the Switch).
2021-01-20 22:31:55.526 Status: SendSwitchIfNotExists: Device '111.instance.1.index.2.commandClasses.156' (Carbon Monoxide) with DeviceID '00006F2A' matches '111.instance.1.index.2.commandClasses.113' (Carbon Monoxide). Domoticz will use the Dimmer (and hide the Switch).
2021-01-20 22:31:55.526 Status: SendSwitchIfNotExists: Device '111.instance.1.index.4.commandClasses.156' (Heat) with DeviceID '00006F2C' matches '111.instance.1.index.4.commandClasses.113' (Heat). Domoticz will use the Dimmer (and hide the Switch).
2021-01-20 22:31:55.573 Status: OpenZWave: Value_Added: Warning: OpenZWave returned ValueLabel "Unknown" on Node: 167 (0xa7), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.573 Status: OpenZWave: Value_Added: Unhandled Label: Unknown, Unit: , Node: 167 (0xa7), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.698 Status: OpenZWave: Value_Added: Warning: OpenZWave returned ValueLabel "Unknown" on Node: 181 (0xb5), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.698 Status: OpenZWave: Value_Added: Unhandled Label: Unknown, Unit: , Node: 181 (0xb5), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.698 Status: OpenZWave: Value_Added: Warning: OpenZWave returned ValueLabel "Unknown" on Node: 181 (0xb5), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 129
2021-01-20 22:31:55.698 Status: OpenZWave: Value_Added: Unhandled Label: Unknown, Unit: , Node: 181 (0xb5), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 129
2021-01-20 22:31:55.729 Status: OpenZWave: Value_Added: Warning: OpenZWave returned ValueLabel "Unknown" on Node: 183 (0xb7), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.729 Status: OpenZWave: Value_Added: Unhandled Label: Unknown, Unit: , Node: 183 (0xb7), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.745 Status: OpenZWave: Value_Added: Warning: OpenZWave returned ValueLabel "Unknown" on Node: 184 (0xb8), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.745 Status: OpenZWave: Value_Added: Unhandled Label: Unknown, Unit: , Node: 184 (0xb8), CommandClass: SENSOR MULTILEVEL, Label: Unknown, Instance: 1, Index: 0
2021-01-20 22:31:55.776 Status: SendSwitchIfNotExists: Device '188.instance.1.index.256.commandClasses.113' (Previous Event Cleared) with DeviceID '0000BC00' matches '188.instance.1.index.0.commandClasses.48' (Sensor). Domoticz will use the Dimmer (and hide the Switch).
2021-01-20 22:31:55.792 Status: SendSwitchIfNotExists: Device '190.instance.1.index.256.commandClasses.113' (Previous Event Cleared) with DeviceID '0000BE00' matches '190.instance.1.index.0.commandClasses.48' (Sensor). Domoticz will use the Dimmer (and hide the Switch).
2021-01-20 22:31:55.839 Status: SendSwitchIfNotExists: Device '192.instance.1.index.256.commandClasses.113' (Previous Event Cleared) with DeviceID '0000C000' matches '192.instance.1.index.0.commandClasses.48' (Sensor). Domoticz will use the Dimmer (and hide the Switch).
2021-01-20 22:31:55.839 Status: OpenZWave: New Node added. HomeID: 3833672857, NodeID: 161 (0xa1)
2021-01-20 22:31:55.839 Status: OpenZWave: New Node added. HomeID: 3833672857, NodeID: 185 (0xb9)

There are some things that stand out for me...
2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download
2021-01-20 22:31:55.839 Status: OpenZWave: New Node added. HomeID: 3833672857, NodeID: 161 (0xa1)
2021-01-20 22:31:55.839 Status: OpenZWave: New Node added. HomeID: 3833672857, NodeID: 185 (0xb9)
And these are the two nodes that are still "off"

[harrykausl]

Would it be possible to implement, that the zwave cachefile would not be deleted (as in ozw 1.4).

[lost]

2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download

You've got several ones logged and then (as a consequence I imagine), some "unknowned" nodes, maybe because they are associated but no config files matching their IDs (among those that failed to download) could be loaded.

=> IMO, check Config directory looks good. For any set of manufacturer/device IDs in manufacturer_specific file, you should have a matching file present in the corresponding manufacturer subtree. IMO, for the nodes that are logged "unknown", you'll not find these devices config files.

As these files were probably there at Domoticz setup, they were probably lost after. If this is not some error from you, this may be the top of the iceberg of some more global filesystem issue making the whole system behavior unstable.

You may also check /var/log/syslog (and other logrotated .1 .2.gz suffixed) for errors related to storage/file-systems:

Code: Select all

zgrep -i 'error\|fail' /var/log/syslog* | more

[Plantje]

2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download

You've got several ones logged and then (as a consequence I imagine), some "unknowned" nodes, maybe because they are associated but no config files matching their IDs (among those that failed to download) could be loaded.

Well, that would mean that they cannot be found at all. After starting up and after a few minutes the whole table of Z-Wave nodes is filled again. And currently all of them except one Aeotec multi sensor are recognized and displayed correctly. Most of the battery powered devices also have a battery level indication. But let's fix things one thing at a time!

=> IMO, check Config directory looks good. For any set of manufacturer/device IDs in manufacturer_specific file, you should have a matching file present in the corresponding manufacturer subtree. IMO, for the nodes that are logged "unknown", you'll not find these devices config files.

As these files were probably there at Domoticz setup, they were probably lost after. If this is not some error from you, this may be the top of the iceberg of some more global filesystem issue making the whole system behavior unstable.

You may also check /var/log/syslog (and other logrotated .1 .2.gz suffixed) for errors related to storage/file-systems:

Code: Select all

zgrep -i 'error\|fail' /var/log/syslog* | more

I don't think there is a need to do this as these errors only occurred on one instance of these devices. Other devices of the same make and model do get recognized, don't give an error etc.
What I wanted to point out here is, that the removal and recreation of the two devices had been queued and a restart of the Domoticz server was needed to make this effective.

And something like this

Code: Select all

zgrep -i 'error\|fail' /var/log/syslog* | more

wouldn't work on my Windows machine anyway

[lost]

Well, that would mean that they cannot be found at all. After starting up and after a few minutes the whole table of Z-Wave nodes is filled again.
(...)
And something like this

Code: Select all

zgrep -i 'error\|fail' /var/log/syslog* | more

wouldn't work on my Windows machine anyway

Looks this is indeed OZW that now tries to keep config files up2date, so no relation to possible FS issue, this may be remote down or some network/domoticz-ozw startup dependency not enforced:
https://github.com/domoticz/domoticz/issues/4372

Was not aware of this... Hope this can be deactivated on a system that proved OK.

For sure, this'll not work on a windows machine! And windows untidy logging rarely helps finding issues: Forget it.

[poweredge]

I have my Domoticz server close to my smart meter, so not in an ideal central place in the house.

Currently what still seems to be causing some issues is the fact that some of the network routes are suboptimal. I am wondering if a dedicated Z-Wave amplifier/range extender would have advantages over buying some additional power plugs. Anyone an idea?

so i had a discussion with a smarthome shop in NL here about this - wether range extender would be beneficial ... theyre argument was - a plug vs a repeater only function is no difference, only sacrificing an another outlet ... so i went with normal plugs... a plug is just a repeater in itself - with a plug.. i opted originally for an aeotec repeater but that is only limited functionality thus for me ..