[quote=“rigpapa”][quote=“Forzaalfa, post:88, topic:198289”]Is there any plans for releasing this for AltUI? I have an openluup system running without Vera, and would like one of these. 
I see that the thermostat shows up fine in AltUI on my Vera, so it should be just to release it in AltAppStore? Looks like it from here, i’m sure its more complicated…:D[/quote]
In the past, openLuup has not set luup.device in the watch and delay callbacks, which AVT likes to have. I’ll check the latest version. There are workarounds, as well. So, maybe.[/quote]
OK. So the short answer is now yes, it’s in the AltAppStore with a single “beta” version (from the Github stable branch). It has not been fully tested, but I expect it to work, and will be pleased to address any problems if not. If you’re interested in an openLuup version of AVT, please help me out by installing it from the AltAppStore and bashing on it.
Background, in case this helps anyone in future (and yes, I’m simplifying a few points here): there’s a key difference between Vera Luup and openLuup that was standing in the way as implemented. Vera Luup loads each module loaded by a plugin’s implementation in per-device context, so if you have three or four AVTs on your Vera, you have four separate copies in memory of its implementation and each of the modules required by the implementation. In contrast, openLuup behaves in a more “Lua-natural” way (IMO) and loads a module only once, so all uses of that module by the three or four AVT devices would share the single copy of the module. The effect of this difference is that certain elements of context on openLuup, such as [tt]luup.device[/tt], are available in the implementation per device, but not the loaded modules (they can’t be, it’s shared context between multiple devices). For AVT in particular, this meant that the watch callbacks being used to monitor temperature sensors and other devices could not discern which of the three or four AVT instances the callback was intended for (Vera neglected to define their callback functions to receive the handling plugin device; [tt]luup.device[/tt] is the remedy for this, but it’s not great style and should have been passed). The workaround was relatively simple once I reassured myself I could get enough context somewhere: rather than having the watch call the module function directly, I have it call a pass-through function in the [tt][/tt] section of the implementation file, which simply calls the module’s function (hence, pass-through), but also passes [tt]luup.device[/tt] as an additional argument to the module’s handler (which is in context and available in the implementation file functions on both Vera and openLuup).
By the way, this difference in module loading probably explains in large part why plugins are so memory-hungry on Vera. It could have all been avoided had they simply added one received argument for each of the callbacks.
