New service actions on existing devices

brucehvn · July 9, 2014, 2:20am

This question came up in my CM11A thread, but I haven’t gotten a good answer, so I’m going to generalize the question here so maybe more eyes will see it since it’s not specific to any X10 stuff.

Let’s say I’m using some new great technology to control items in my house that’s not z-wave. Let’s call it y-wave for this example. I’ve created a plugin to talk to my y-wave controller and now I want to configure devices for it. The y-wave devices all do the same kinds of things as our normal devices. We have binary switches, dimmers, etc.

The only real difference is that I need to have my y-wave devices talk to the y-wave controller and the controller needs to call actions on the devices to update the status.

So, let’s take a binary switch as an example. I want to have the same device type as the normal binary switch (urn:schemas-upnp-org:device:BinaryLight:1) so that I don’t have to go around to all the remote developers and beg them to add my new device types to their apps. And since my binary switch device acts the same, it seems logical to use the same device type. But my device needs to do it’s own implementation to handle the requests and send them to the controller.

Ok, so now I can easily create a device in the UI that uses the same D_BinaryLight1.xml and specify a custom implementation file (I_YWaveBinaryLight1.xml). Garrett has already pointed out that if I create my own D_YWaveBinaryLight1.xml that uses the same device type, it will probably cause conflicts.

Here is my dilemma. The custom action interface between the y-wave devices and controller are put into S_YWaveDevice1.xml and S_YWaveController1.xml. I want people to be able to write their own custom implementations for their y-wave devices but they will all use the same service contract files to communicate with the controller and allow the controller to communicate with the devices.

Now without creating my own D_YWaveBinaryLight1.xml, it appears I cannot specify these S_YWave*.xml files for inclusion. Is that a problem? If in my I_YWaveBinaryLight1.xml, I have this:

  <actionList>
    <action>
      <serviceId>urn:upnp-org:serviceId:SwitchPower1</serviceId>
      <name>SetTarget</name>
      <run>
        switch_set_target(lul_device, lul_settings)
      </run>
    </action>
    
    <action>
      <serviceId>urn:foo.org:serviceId:YWaveDevice1</serviceId>
      <name>UpdateStatus</name>
      <run>
        update_status(lul_device, lul_settings)
      </run>
    </action>
  </actionList>

But I haven’t included the S_YWaveDevice1.xml which defines this:

<?xml version="1.0"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <serviceStateTable>
    <stateVariable>
      <name>ReceivedStatusFunction</name>
      <dataType>string</dataType>
    </stateVariable>
    <stateVariable>
      <name>ReceivedStatusData</name>
      <dataType>string</dataType>
    </stateVariable>
    <stateVariable>
      <name>ControllerDeviceNum</name>
      <dataType>string</dataType>
    </stateVariable>
  </serviceStateTable>
  <actionList>
    <action>
      <name>UpdateStatus</name>
      <direction>in</direction>
      <argumentList>
        <argument>
          <name>function</name>
          <relatedStateVariable>ReceivedStatusFunction</relatedStateVariable>
        </argument>
        <argument>
          <name>functionData</name>
          <relatedStateVariable>ReceivedStatusData</relatedStateVariable>
        </argument>
      </argumentList>
    </action>
  </actionList>
</scpd>

Will it still work? And if not, then what are my options?

Bruce

idefix · July 9, 2014, 6:34am

Interesting question.
I’m looking at something similar. E.g. how would I create a fan control device based on an existing device type - so it shows up in 3rd party apps - which will use HTTP post or IR commands to control the fan instead of zWave?

Your solution could give me an answer for my problem.

akbooer · July 9, 2014, 6:49am

If I understand correctly, then lots of plugins already do this. You use the actual device type but create it as a child of your plugin device. The implementation can be in the plugin - nothing to do with the original device code.

brucehvn · July 9, 2014, 9:11am

Hi akbooer,

If I understand what you are saying, then if the plugin includes those service files, the children will automatically inherit them and be able to use the actions within them?

My problem is that the parent/child relationship didn’t work for me because my plugin needs to use a serial port and whenever I tried to create a child device, for whatever reason, when the child’s parent was changed to be the controller device, vera was trying to open the same serial port for each child device and the conflict would keep all of the devices from working. I think I posted that problem in another thread but never was able to find a solution. I think the problem was related to the child devices also having their own implementation files though I did everything in my power to try and tell vera that those child devices did not use the serial port. It looks like in a normal parent/child setup, the parent implementation handles everything for the children as well. That requires the parent to have knowledge about all the various types of child devices and how they work. I wanted to abstract the controller from that.

My goal was to be able to let people add these devices without needing to do any modification of the controller code plugin or settings. A new device could be added and just by specifying the id of the controller in the new device (not as the parent though), it would register with the controller and start talking to it through a standard service interface. It wouldn’t matter if it was a binary light switch, or an industrial copper smelting overflow sensor (?!). That was one of the drawbacks of the old CM11A controller is that it only knew about a certain set of device types and if you wanted to control anything else, you had to modify the plugin code for the new type. I wanted to try and avoid that.

Bruce

akbooer · July 9, 2014, 2:36pm

If I understand what you are saying, then if the plugin includes those service files, the children will automatically inherit them and be able to use the actions within them?

That’s not quite what I’m saying. You define child devices of the required type (and that includes their usual services) without an implementation file. The parent device doesn’t need to reference the service at all.

I don’t know about the serial interface issue you describe.

brucehvn · July 9, 2014, 10:10pm

[quote=“akbooer, post:5, topic:181920”]That’s not quite what I’m saying. You define child devices of the required type (and that includes their usual services) without an implementation file. The parent device doesn’t need to reference the service at all.

I don’t know about the serial interface issue you describe.[/quote]

Ok, I think I have what you are saying now, but I still think it won’t work for me as the controller (parent) would still need to handle all the implementation for the child devices. I will experiment a bit with the devices using the standard D_.xml files and my implementation files and see if the controller can still do a call_action on them even though they have not included the S_.xml files.

Bruce