Oh the joy of pairing

[Crille]

@therealdb Ok, thank you. I’ll wait till that one is squished then.

[LibraSun]

Too bad Pabla and Crille (and I plus a dozen others) can't participate on the MCV forum where feedback like that would be invaluable. Are you both still on their Jira bug tracker, though?

[rafale77]

Classic...

For one minute I was thinking of testing it for kicks. well...

I have no idea why it is trying to reconfigure every device. There is no situation where this should ever be automated unless the database is wiped and even then it should be trying to get configurations from the devices, not configuring them. The logic is just broken. Vera at its best.

[Pabla]

@librasun Never joined the bug tracker, unfortunate for them. I can figure it out here though thankfully

[CatmanV2]

Same old?

C

[Pabla]

@rafale77 its all the same Zooz devices having this issue, weirdly this is the variable thats not configuring. Every time I try to delete it or set it to 0 after a reload it comes back. I have never even set this device config before either

[rafale77]

@pabla ... sigh. Sorry to see this. Though I am glad to never have to deal with this type of nonsense anymore, I am saddened by the absurdity of the vera device management. I suppose you see this problem at every luup reload then? The vera has hardcoded in its firmware that it is expected to see this configuration parameter for this device it recognized. The problem is that it is likely wrong. Thus the absurdity of the whole "device support list". They should just be supporting zwave by supporting all the command classes and representing them accordingly and stop trying to be smarter than the users. Worst case, if it is a very unusual device, let the user community create the virtual devices for them like hubitat does. Oh well enough of my ranting. There isn't an easy way I know of to get rid of this besides "hacking" the device registry file in the vera, which I have done in the past... This is hardcoded stupidity.

[therealdb]

There’s now a new flag to avoid children recreation. I’ve applied it and my system is rock solid. I updated 3-4 times for the beta. They even decoupled the engine and it’s updatable via opkg. can’t say Edward and his team aren’t working to improve things, but there are fundamental flaws for sure.

All that said, my system is quite perfect since the first build of this beta.

[Crille]

@librasun Yes, jira is now my only way to “communicate” beta feedback.

[LibraSun]

Don't think I've seen any 7.32 f/w - specific tickets opened up on the ezlo Jira system yet. Standing by... won't take the plunge until the coast is a bit clearer.

[therealdb]

@librasun as I’ve said, I’m running it since October, maybe. No problems at all, beside the one with the scene. Overall this beta rocks.

[LibraSun]

Anyone else notice a significant bump in Vera's resting CPU usage after upgrading to 7.32?
Mine is chugging along at 0.20 (according to System Monitor plug-in), peaking at 0.37(!), way up from around 0.06 at rest before the upgrade.
Thoughts as to why this 3-7x increase might be happening? Just curious.

At least "Available Memory" is improved from a base of 182k (with 8 Reactors active) or 192k (all Reactors disabled and removed) under 7.31, to a pretty constant 203k under 7.32.

UPDATE: I'll report back on this tomorrow, in case Vera is just busy downloading items in the background or shuffling around the file system somehow.

[Pabla]

@librasun my CPU usage has been normal and memory has been same for me too since updating

[therealdb]

@librasun yes. Plus, there's definitely some memory leaks after days of uptime. I was never able to experience it before, since I was barely able to get a full day. I wrote a watchdog to restart the luup engine in such situations.

[LibraSun]

On the morning of the second day, it appears that Vera has settled back down to an even lower CPU demand load than under the prior firmware. Now, I am showing a one minute rate of 0.05, which is more than acceptable. The available memory meanwhile is also holding firm at 200k. Overall this is a net improvement so I have no complaints.

[Pabla]

@therealdb said in Vera firmware 7.32 beta:

There’s now a new flag to avoid children recreation. I’ve applied it and my system is rock solid. I updated 3-4 times for the beta. They even decoupled the engine and it’s updatable via opkg. can’t say Edward and his team aren’t working to improve things, but there are fundamental flaws for sure.

All that said, my system is quite perfect since the first build of this beta.

Could you go into more depth about this? Will your code prevent multiple child devices from occurring? My VP is plagued with multiple child devices

[therealdb]

@pabla it will prevent children to be deleted and created after configuration. I've been lucky with that, but just run this code

-- 7.32 -- disable children delete on reconfigure
luup.log('disable children delete on reconfigure: start')
for k, v in pairs(luup.devices) do
	local var= luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "ChildrenSameRoom", k)
	if var ~= nil and v.device_num_parent == 1 then -- zwave devices with children only
		luup.log('children delete on reconfigure disabled: #' .. tostring(k))
		luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "DeleteChildrenOnReconfigure", "0", k)
	end
end
luup.log('disable children delete on reconfigure: end')

[Pabla]

@therealdb Hopefully this helps my system out, ever since 7.32 every reload/device config brings new child devices.

Is there any new way we can delete multiple child devices for a parent device?

[therealdb]

@pabla yes, but I think it's not easily automatable, unless they have all the same pattern in the name.

[Pabla]

@therealdb is it possible to run code based on the device number instead? I am at about 14 child devices, so wouldn’t mind deleting them one by one.