If you write a Custom Device, that’s attached to one of the Serial/USB Ports, and that interface “happens” to be down during a reboot, the Parent Device’s startup() method is still called.
The problem is that, after startup, Vera will look at all “Child Devices” created during the startup processing. If these differ from the original set, created by previous startup actions, then any missing Child Devices will be formally removed… all Device-Scene associations will have their relationships to these [temporarily] missing devices cleared out. In cases like the GC100, and my Alarm Panel Device, they use the startup method to enumerate the device children using the Serial Port and/or Ethernet interface. When these are down, they build “no children”.
This can happen, for example, if you “move” Vera, and start it up before wiring it in completely to all of it’s previous Devices.
In this case, the Serial port is down, Vera runs your startup method, and proceeds to destroy all your previous Child devices, and their associations with Scenes.
It seems that, if the device is attached/registered (etc) to talk to a Serial Port, or to an IP Address/Port, then Vera should not fire the startup method until a “valid” connection can be made, otherwise data loss occurs.
This has happened with my Alarm Panel interface, and I suspect it’ll happen with the GC100 or anything else that might be “offline” during a Vera reboot and/or move.
The GC100 startup code should abort if it fails to get a valid response from the GC100 and should only remove child devices if it gets a valid response from the gc100 that there are no children. See L_GC100.xml:
if( incoming_data == nil or string.find(incoming_data,“endlistdevices”) ) then
if( incoming_data == nil ) then
luup.log(“didn’t get endlistdevices”)
lul_IsError=true
end
break
end
My argument is somewhat simpler, the startup() method shouldn’t be called on any Device if the attached/registered Serial Port, or IP/Port, connection cannot be established.
You’re guaranteed to run into problems in that case, since a device configured to depend upon connectivity cannot start (or at least I can’t think of one that should)
Can you give the logic for calling our startup methods when the defined connectivity isn’t possible and/or achieved?
I’ll check the details tonight, but last I recall, I wasn’t clear on how I’d instruct the Luup container, running my block, that I need to “fail”.
I’m running the 879 upgrade so I also have the latest versions of I_GC100.xml to compare against.
In 1.0.879, I can no longer Create a Luup Device.
I can upload the individual files, but the (Add device) at the bottom no longer works and reports a Browser alert with:
Not enough parameters to create the device.
after pressing the (Add Device) button.
For the testcase, I uploaded the individual files from my Weather plugin (zip attached in thread http://forum.micasaverde.com/index.php?topic=1435.0) and then goto the bottom and type:
D_Weather.xml
then press (Add Device)
I’ve upgraded twice, and still get this error. The last upgrade was also a “Restore to Factory Default” version.
It’s now possible to create Luup devices again in the 1.0.883 release, so testing continues on the other issue