Vera PushOver notification with image

[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.

[therealdb]

@pabla I'm not sure there's a luup method to delete objects beside calling it via HTTP, but it should be handy anyway with this script:

local yourID = put-here-your-master-id

luup.log('Starting...')
for k, v in pairs(luup.devices) do
	if tostring(v.device_num_parent) == tostring(yourID) then 
		luup.attr_set( "embedded", "0", k)
		luup.log("http://ip_address:3480/data_request?id=device&action=delete&device=" .. tostring(k))
	end
end
luup.log('Completed...')

You should be able to grab the URL from the logs and call them quickly. I could add a curl command locally, but if I remember correctly, it will reload between each delete anyway... so take your time and stay hyadatrated while you'll wait for reload...

[LibraSun]

Guys, I think I've pinned down the most likely candidate(s) for "Things that cause my Vera to restart", and it looks to be any Reactor routine that involves changing House Mode.

I know that seems a bit outlandish, and further pinning down is required... but I've definitely taken notice of the exact times of day when a Luup engine restart occurred, and it's usually in the same time span that House Mode was changed, almost without exception.

A puzzlement. And I could of course be wrong.

Anyone else experience such shenanigans?

[CatmanV2]

I've seen it happen with a device that Vera wasn't happy about changing state on a mode change.

C

[therealdb]

@librasun said in Vera firmware 7.32 beta:

A puzzlement. And I could of course be wrong.
Anyone else experience such shenanigans?

this is frequent if you have a lot of actions attached to a mode. I've transitioned to a staged function, where things get called in sequence (ie: in small groups of 5 decices) and it improved a lot.

[LibraSun]

@therealdb said in Vera firmware 7.32 beta:

this is frequent if you have a lot of actions attached to a mode.

I recalled you saying that, so I had checked to see WHAT actions were taking place in connection with the changing Mode, and basically nothing. In fact, I only let MSR change House Mode 15 seconds after any other reactions are done.

And none of Vera's built-in "House Modes" settings (from the Dashboard) make changes to any devices.

Hmm... I'll have to keep my thinking cap on some more.

[CatmanV2]

What happens if you change modes manually?

C

[LibraSun]

@catmanv2 said in Vera firmware 7.32 beta:

What happens if you change modes manually?

C

Never a problem, but I will certainly investigate. For instance, I have MSR Rules in place which (after a brief pause) cause my ecobee thermostat to match its mode to the new House Mode, and vice versa. Very thoroughly tested, but never 100% above suspicion.

[toggledbits]

You might also try using 3.9 stable branch Reactor. It's got some different job control features specifically for 7.32. I've run that combination on my house Vera for months now and have few reloads.

[Pabla]

@toggledbits if I have reactor installed from the marketplace can I grab the files from GitHub and upload those to update? I did this once I remember and everything got thrown out of whack

[toggledbits]

That works fine. Just follow the procedure:

1. Go to the stable branch for the project on Github: https://github.com/toggledbits/Reactor/tree/stable
2. Click the green "Code" button and choose "Download ZIP". Save the ZIP file to your local HD.
3. Unzip the file.
4. Open the Vera UI and go to Apps > Develop apps > Luup files
5. Select all of the unzipped files (not the folder, the files as a group) and drag them to the "Upload" button in the UI.

The system will reload when the upload completes. You'll want to hard-refresh your browser as usual.

[LibraSun]

Following up since I made the above changes last week, and am happy to report NOT A SINGLE LUUP ENGINE RESTART YET!
Having minimal plug-ins installed and periodically rebooting Vera by power cycling seems to be a wise regimen to follow. I'm past thinking the "random restart" problem was induced by House Mode changes and/or too many commands issued at once, etc.

[toggledbits]

Yeah, I think I know where their locking bug is that causes deadlocks.

[LibraSun]

Guy on the old forum says 7.32 coming out of beta, posted a download link, but company strangely mum about it.

[Pabla]

IMO this beta needs a few more releases before general release but whatever. 7.31 for me is still the best build

[tunnus]

Beta discussion (or more of a silence) doesn't look very promising... and as a banned user cannot participate if I wanted to.

They don't seem to publish a production release, so I guess I have to bite the bullet and go for the latest beta, but the link given (Vera Plus) in the first post does not work, so anyone know from where to download?

EDIT: Found beta 4, which seems to be the latest one. I guess this is as solid as Vera can ever be?

[toggledbits]

@tunnus said in Vera firmware 7.32 beta:

. I guess this is as solid as Vera can ever be?

I think we have to assume that's the case. Clearly, they are overrun with their other efforts. They are now over three years since acquisition, on their way to four, and as we all have experienced, the last 20% of any project can take 80% of the time and effort. Worse, by my product math, if they have 80% of the project 80% complete, they've done 64% of the work necessary (0.8 x 0.8), so I predict mid-2023. I think they're spread so thin trying to get everything done that they claim they will have that there's no bandwidth for Vera firmware on their radar, but if it's going to take that long for the new firmware to be feature complete and stable enough (regardless of how they describe the release... alpha, beta, candidate, etc... customers will decide what it is, as they are doing right now)., they may be forced into the position of doing another release of Vera firmware to try to preserve that customer base. If they don't hold the Vera customer base and get a significant migration of customers, the purchase of Vera was an unnecessary waste.

Everything I have left on Vera now runs on 7.32, and it's pretty stable. Still deadlocks, still reloads, still Vera. If you go to 7.32 and you're using the Reactor plugin for Vera, I recommend updating Reactor to 3.9, which is on Github, not in the App Marketplace. Updates for my other plugins are (and always have been) on Github as well. Decoupling does appear to make it more stable.