Global Lua functions

Vera Controllers, Services & Devices Vera Controllers & Cameras
#21
- Obviously there is a bug in Vera, for not updating all variables upon scene event triggering. For example, when another device changes the state of a dimmer using Z-Wave associations, and that state change triggers a scene associated with the dimmer, it is expected to have LoadLevelTarget set to new value. But it's not.

I wouldn’t consider this a bug. Because you are having an actual device (not vera) control another device. Vera will only see the status of that device that was controlled via association via either instant status or polling. It will not know the target as vera did not control it. That is why you are seeing the LoadLevelTarget not being updated.

  • Garrett
#22

Ok, I’m still a little new with this, but it sounds like you want all the associated dimmers to sync immediately. I guess the devices would have to support instant status for this to work? Otherwise you would need a delay to allow the Vera to poll each associated switch, is that right?

#23

Hi,

Here is the promised code. This is the “library” file, which need to be uploaded:

ihDimmerList = {}
ihSwitchList = {}

function ihSetDimmers(slaveIds, value)
	for i, deviceId in ipairs(slaveIds) do
		luup.call_action("urn:upnp-org:serviceId:Dimming1","SetLoadLevelTarget", { newLoadlevelTarget = tostring(value)}, deviceId)
	end
end

function ihSetSwitches(slaveIds, value)
	for i, deviceId in ipairs(slaveIds) do
		luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget", {newTargetValue = tostring(value)}, deviceId)
	end
end

function ihFollowDimmer (lul_device, lul_service, lul_variable, lul_value_old, lul_value_new)
	ihSetDimmers(ihDimmerList[lul_device], lul_value_new)
end

function ihFollowSwitch (lul_device, lul_service, lul_variable, lul_value_old, lul_value_new)
	ihSetSwitches(ihSwitchList[lul_device], lul_value_new)
end

function ihInstallWatchers(dimmerList, switchList)
	ihDimmerList = dimmerList
	ihSwitchList = switchList
	
	for i,lst in pairs(dimmerList) do
		luup.log("Install dimmer watcher for: " .. tostring(i));
		luup.variable_watch("ihFollowDimmer", "urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus", i)
	end

	for i,lst in pairs(switchList) do
		luup.log("Install switch watcher for: " .. tostring(i));
		luup.variable_watch("ihFollowSwitch", "urn:upnp-org:serviceId:SwitchPower1", "Status", i)
	end
end

Yes, followXX functions can be merged in one, but MiOS guys made some things “nice” like newLoad_l_evelTarget, which corresponds to LoadLevelTarget, the need to have Target and Status here, etc. And also - variable_set() didn’t work for me. This is used by putting this in the startup code:

require("THE_LUA_FILENAME")

ihInstallWatchers({ [4] = {57, 71}, [49] = {60, 72, 18, 20} }, { [3] = {59}, [8] = {61} })

The idea is - [MASTER_DEVICE_ID] = {LIST_OF_SLAVE_DEVICE_IDS}. Not a big deal, indeed.

For this Target <-> Status not being a bug, Garett - yes, I understand you and why is this happening. My point was, that a change in this device - although controlled from elsewhere - DOES trigger a scene, so theoretically Vera can obtain that status-change and reflect it in its internal variables, like LoadLevelTarget, but it doesn’t.

joey52685, polling is not the only way for Vera to obtain data from devices, they can “push” their state to it and, to the best of my knowledge, it is done using same association mechanism. For example Fibaro dimmers/switches has a special association group (#3) for status updates, so every time a change happens, it notifies devices listed there. Actually, there can be ONE device, and Vera puts itself in that list. Other devices, like Vitrums that I need to get working with dimmer, have another association channels and concept of updates. That’s my understanding so far :slight_smile:

#24

Please do not cross post! It is considered rude.

  • Garrett
#25

Ok, sorry. I’ve deleted it.

#26

Thanks for the update.