Strange behaviour with "...:device:MotionSensor:1"

Developer's Corner General Dev Discussions
#1

If you create a own device of devicetype motionsensor

<deviceType>urn:schemas-micasaverde-com:device:MotionSensor:1</deviceType>

then you have to restart the lua engine to make it load correctly in the UI.

I invoke the “Reload” action within the plugins startup function.

lul_resultcode,lul_resultstring,lul_job,lul_returnarguments = luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","Reload",{},0)

Otherwise it is displayed without the red/green circle and the arm/bypass buttons.

#2

I mostly create [Child Device] instances of the existing [tt]D_MotionSensor1.xml[/tt] device defn in my Alarm Panel (one per Zone).

I only do this at startup, similar to how the GC100 Luup integration works.

Since Vera needs to “restart” every time I upload my Lua code changes, and the engine itself tends to “restart” the init processes when Vera detects child-differences after a call to [tt]luup.chdev.sync()[/tt], I’ve not seen the behaviour you describe…

Are you trying to create a new/different implementation of the existing DeviceType or what are you looking to do?

#3

At first I wanted to create a complete new devicetype, but I soon figured out, that you have no chance to get a “rich” UI that way.
I wanted to use the Arm / Disarm button and the indicator circle of the motion sensor, but there is no option to activate those desired elements in your own device. So I played around with the schemas of the devicetypes to work out what has to happen that the motion sensors UI will be displayed.

Well it’s not much. The MCV guys hardwired the UI of the motion to the devicetype schema of the motion sensor and the state variables of the buttons and the circle is also hardwired to the SecuritySensor1 service. :frowning:
So, if you want to have the UI functions within the topmost device, you have to define your device as schema type of an existing motion sensor/temperature/what ever … device.
That’s it. :smiley:

While in your cases (weather plugin, alarm plugin) you have more than one child device it’s okay to have a “wrapper” device. In my case (ping sensor plugin) I would have had only one child. Having a child device here would be like “code around” a shortcoming.

Long story short:
You can reload child devices with luup.chdev.sync() which already works well.
To reload the parent device itself to make it load the correct UI you have to execute the following line in the plugins initialization.

lul_resultcode,lul_resultstring,lul_job,lul_returnarguments = luup.call_action("urn:micasaverde-com:serviceId:HomeAutomationGateway1","Reload",{},0)

I think it would be nice to have something like luup.selfdev.sync() or so. So you don’t have to handle the results (if something goes wrong) on your own.

I hope I explained it detailed enough, so you know where I’m coming from. Otherwise: hit “Reply” :wink:

#4

Yeap, worked that out also. When I started with the Weather component it was a single [top level] device that implemented/listed both the Temperature and Humidity services… only to realize that the rendition isn’t keyed from the Service’s, but from the Device (doh!)

So I just ran with it, and bubbled up Child Devices, and a few extra Children for the High/Low Temperature settings (I figured I’d make the best of it)

In your case, if you wanted to do the same, you could support a “list of Poll URLs”, and have the parent monitor all of them (as embedded Child devices). Not perfect, but works within the limitations of the existing [UI/Rendition] model.

I wish that the UI/Renditions were also Luup components, and that they rendered based upon “any” characteristics of the Device. The existing ones could then continue what they do today, but new ones could render based upon Services (etc), and components could “hint” how they wanted to be rendered or there could be some sort of “override” model where folks could upload renditions that changed the default behavior.

eg. [tt]R_TemperatureSensor1.xml[/tt] - a Rendition for Temperature Sensors, written in Luup