Domoticz

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)

kiddigital wrote: ↑Saturday 16 January 2021 11:09 @plantje, as stated above use ‘refresh node info’ instead of re-adding nodes again and again.

kiddigital wrote: ↑Saturday 16 January 2021 11:09 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.

kiddigital wrote: ↑Saturday 16 January 2021 11:09 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.

kiddigital wrote: ↑Saturday 16 January 2021 11:09 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.

thelbekk wrote: ↑Monday 18 January 2021 9:32

Plantje wrote: ↑Saturday 16 January 2021 13:22 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.

akamming wrote: ↑Monday 18 January 2021 17:54 Hi plantje, just read these messages.

akamming wrote: ↑Monday 18 January 2021 17:54 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.

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)

akamming wrote: ↑Monday 18 January 2021 17:54 In my case my network got much stabler when i started replacing the neocoolcams ny more expensive hardware.

akamming wrote: ↑Monday 18 January 2021 17:54 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.

akamming wrote: ↑Monday 18 January 2021 17:54 This also explains issues with parameters not set correctly in domoticz, cause messages get lost disturbing synchronisation.

akamming wrote: ↑Monday 18 January 2021 17:54 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

akamming wrote: ↑Monday 18 January 2021 17:54 - 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.

akamming wrote: ↑Monday 18 January 2021 17:54 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

akamming wrote: ↑Monday 18 January 2021 17:54 Good luck!

Plantje wrote: ↑Monday 18 January 2021 21:44 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.

Plantje wrote: ↑Monday 18 January 2021 21:44 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:

Plantje wrote: ↑Monday 18 January 2021 21:44 So, you only have Fibaro stuff now?

Plantje wrote: ↑Monday 18 January 2021 21:44 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.

Plantje wrote: ↑Monday 18 January 2021 21:44 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.

Plantje wrote: ↑Monday 18 January 2021 21:44 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?!?

Plantje wrote: ↑Monday 18 January 2021 21:44 Also wondering in what category Aeotec falls as it seems to be in between Fibaro and Coolcam.

akamming wrote: ↑Monday 18 January 2021 17:54 In my case my network got much stabler when i started replacing the neocoolcams ny more expensive hardware.

ArnoutZ wrote: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?

akamming wrote: ↑Tuesday 19 January 2021 8:58

Plantje wrote: ↑Monday 18 January 2021 21:44 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.

akamming wrote: ↑Tuesday 19 January 2021 8:58

Plantje wrote: ↑Monday 18 January 2021 21:44 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)

akamming wrote: ↑Tuesday 19 January 2021 8:58 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

akamming wrote: ↑Tuesday 19 January 2021 8:58

Plantje wrote: ↑Monday 18 January 2021 21:44 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...

akamming wrote: ↑Tuesday 19 January 2021 8:58

Plantje wrote: ↑Monday 18 January 2021 21:44 Also wondering in what category Aeotec falls as it seems to be in between Fibaro and Coolcam.

works fine in my network

lost wrote: ↑Tuesday 19 January 2021 9:43 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!

hestia wrote: ↑Tuesday 19 January 2021 20:57 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...

hestia wrote: ↑Tuesday 19 January 2021 20:57 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 wrote: ↑Wednesday 20 January 2021 7:16

ArnoutZ wrote: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 wrote: ↑Wednesday 20 January 2021 15:04 just a short compliment for the topic - following it as well -

poweredge wrote: ↑Wednesday 20 January 2021 15:04 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 wrote: ↑Wednesday 20 January 2021 22:40 2021-01-20 22:31:47.216 Status: OpenZWave: A Config File Failed to download

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

lost wrote: ↑Thursday 21 January 2021 13:00

Plantje wrote: ↑Wednesday 20 January 2021 22:40 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.

lost wrote: ↑Thursday 21 January 2021 13:00 => 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

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

Plantje wrote: ↑Thursday 21 January 2021 20:00 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

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?