I’m wondering how Luup works out how to sync existing children when using the chdev.start/append/sync functions. I assume it tries to correlate the parameters passed with existing child devices so that the device number stays the same (which is important).
However, if I pass specific parameters into the append function when the device is first created, and a user then changes them away from defaults, then what happens? Will they be reset to the defaults again, or does Vera try to correlate these somehow? Maybe it uses the “id” field to do this? It would be nice to know to avoid problems when adding more children.
I personally don’t think this is a very clean interface - I’d prefer to be able to create/delete child devices explicitly by device number. The existing interface may be fine for combined devices with a set number of children, but when this is being used to interface to a larger network of ad-hoc devices, it’s not very clean.
I suspect at some point they’ll have to change this, in order to support a “No Save Cycle” model for users interacting with Vera.
It also gets in the way with some of the larger devices that may not be able to prescribe all of their children “up front”… or where it’s time prohibitive on startup to do so, such as where there are intermittent devices, or just slow ones.
The current basically model assumes you know, or can know, all the devices “up front” as the start/append/sync model MUST list them all, as the delta’s get deleted. Some of the Plugins are jumping through hoops to make this work, but that often makes the configuration of these Plugins less automatic.
Also, there bugs where, occasionally, it’s possible to trash the device lists - requiring restoration from Backup.
Thanks guessed,
I’m in this exact situation where I potentially have a lot of child devices, and they are potentially all added at different times as new sensors are added. I’m specifically working on upgrading the one-wire plugin, and I need to add (multiple) new children when a new device is added without screwing up the ones that already exist…
I may end up storing a bit of extra data (variables) into the device when I initially create it to try and avoid problems later - I guess we’ll see if I’m successful.
Yeap, that’s basically the trick people end up having to use. Effectively keep a list of the keys (altid’s, etc) floating around in [persisted] state variables so that they can be picked up upon the next Save. There are variations, but they all take roughly the same form.
eg. The list of Zones pre-described (manually in the DSC and others)
eg. The list of Meters manually keyed into the Brultech
eg. The list of Zones “automatically” gotten from the Paradox (but any IO issue during this startup seq and you can lose Zones)
Do you know if it’s possible to get the device “variables” (if they are handled as variables) that show up in the advanced tab? Many (but not all) exist in the devices table, but I’m interested in getting hold of the ServiceId/DeviceID/Imp File strings, and they don’t appear in the luup.devices table. I was wondering if they could be read as variables with a default ServiceID?
I’ve only ever used a subset of the ones described in the Wiki. I wouldn’t be surprised if others exist, but you’d have to enum the [tt]luup.devices[luup.device][/tt] Table to see if there are extra ones.
Other than that, you’re stuck reading the JSON itself, which would get ugly.
I have used [tt]luup.attr_set[/tt] to change things like, [tt]description[/tt], after creation but there’s no corresponding [tt]luup.attr_get[/tt]
Thanks - I’ve tied itterating the table and it’s just the entries listed in the wiki I might have to stash them into another variable - just seems a shame given to store the same thing twice…
Is it working well with UI4 ? With UI5 1.5.254 ?
I notice that after syncing I can loose childs. Is it allowed to use the same id for two childs ?
I explained my scenario:
First I add one child of type temperature with ID TH7_15054 and one child of type humidity with same ID
=> ok, I get the two devices after automatic reload
I add one child of type temperature with ID TH1_47362 and one child of type humidity with same ID
=> not ok, after automatic reload I get only 3 child:
TH1_47362 of type humidity
TH1_47362 of type temperature
TH7_15054 of type humidity but with the name of lost temperature device
I’ve never tried, but generally you need the child ids to be unique so you can look them up later when events come in, or data needs to be dispatched.
Note that ALL children must be re-created within a single chdev.start/append/sync sequence. If that’s not done, then older child devices will definitely be removed.
I might have to stash them into another variable - just seems a shame given to store the same thing twice…