Subscription options

[FlyingDiver]

So, how best to specify subscribed topics?

I don't want to get into a complicated subscription management system, at least not at first. But I was thinking about a couple of actions - one to add a subscription to a broker, another to remove one.

[mreyn2005]

Yeah I've been starting to think about this as well. There are basically two schemas I'm considering currently.

1) /device/statusUpdate
This approach means I really only need a couple subscriptions/triggers... One for all Devices (one for all Variables, one for all Actions).
This requires more parsing and iterating logic to know which device needs to be acted upon.
This requires more algorithmic run time as we have to loop through all devices every time a message is received on this topic in order to find the matching device.

2) /device/12345 where 12345 is the device ID in Indigo.
This approach means I would want an autonomous way to create subscriptions for a set of all devices currently registered. Otherwise I'm creating a Trigger for every device manually.
This requires less parsing, we know what thing to act upon (we still have to look up the device from the ID)
This requires less iterating at run time, we just need to get the device by its ID... Is there getDeviceByID function in the internal Indigo plugin API?

I'm leaning towards number 1.

Matt

[FlyingDiver]

I've got the subscribe and unsubscribe code working, available either as an action (action groups, triggers, schedules, etc), and also as a menu item for manual ad-hoc changes. You should also be able to script (Python) a series of subscribe commands so that you have a way to reset everything.

What I don't have right now is a way to save the subscriptions and re-subscribe when the plugin or device is restarted. I've been thinking about how to do that. I'll probably have a solution for that tomorrow. I need to get that working because I need to remove the default '#' subscription from the code.

Once I have that working, I'll release 0.0.2 and then work on the connection/authentication code.

[FlyingDiver]

Got that code working, so 0.0.2 is released.

[mreyn2005]

I am still working on my schema, but the basics for now would be something like:

Code: Select all

{
   "deviceId": 12345,
   "deviceType":, "OUTLET|LIGHT|DIMMER|OTHER",
   "deviceValue":, "ON|OFF|0|25|50|75|100"
}

I could repeat this for variables and action groups, or I could make a generic schema object.
Something like

Code: Select all

{
   targetId, 
   targetClass,
   targetType,
   targetValue
}

Since I am leaning towards 3 topics, one for device, action, variable, then 3 similar schemas would be sensible enough considering each schema might have slightly different properties.

It might be worth looking at the GreenSkyMQTTBridge plugin to see how they're doing their parser logic? It has some parsing syntax sugar so you can specify things like

Code: Select all

data -> deviceId

or

Code: Select all

data -> deviceValue

Where the arrow function can access children from a parent. I believe it supports additional nesting arrow functions, such as :

Code: Select all

x -> y -> z.

This would allow any schema to be used.

Further down the road, I can imagine having 4 meta topic parent paths (homeautomation, environment, media, geolocation):

Code: Select all

/homeautomation
   /deviceUpdate
   /executeAction
   /setVariableValue
/environment
   /irrigation
   /sensor
      /reportSensorValue
   /weather
      /reportAirQuality
      /reportAltitude
      /reportBarometricPressure
      /reportHumidity
      /reportLightningDetected
      /reportLux
      /reportTemperatureInside
      /reportTemperatureOutside
      /reportPrecipitation
      /reportWindSpeed
      /reportWindDirection
/media
   /playMediaItem
   /mediaItemPlaying
/geolocation
   /reportItemLocation

This would handle all my planned use cases for the MQTT server side of Command and Control.

I purchased a SkyWeather station kit from SwitchDoc, so that is my main use for the MQTT server so far (for the weather section of the schema).
I am planning to put it on a remote property with cellular backhaul.
https://shop.switchdoc.com/products/sky ... -the-cloud

Matt

[jay (support)]

Just curious - has anyone out there attempted to define MQTT message payloads specifically for smart home devices? Might be worth some effort looking to see if there are any standardization efforts out there.

I would encourage anyone who's defining their own payloads to always add the following: a unique message type identifier (so there's enough information for the client to know what to do with the message without having to inspect the various data elements in the payload to infer it) and a version number (so if the payload needs to change, the clients can behave in a reasonable way). Having designed many APIs over the years, these two things will significantly minimize the headaches as more clients attempt to consume your information and as your API matures.

[FlyingDiver]

Here's an interesting post on the topic: http://www.steves-internet-guide.com/mq ... ign-notes/

I've been googling, but have not found anything like a standard message schema.

[mreyn2005]

Just got v0.0.4 installed and working.

Could you post a sample script to parse a simple incoming schema?

Code: Select all

{
   "deviceId": 12345,
   "deviceType": "OUTLET|LIGHT|DIMMER|OTHER",
   "deviceValue": "ON|OFF|0|25|50|75|100"
}

I want the script to:
Find device by ID,
Update device state based on deviceValue.

I'll poke around in the mean time and see if I can find some sample scripts that I could modify.

Matt

[FlyingDiver]

I removed a couple of stray commas from your sample message.

Code: Select all

import json

input = '{"deviceValue": "ON", "deviceType": "OUTLET", "deviceId": 12345}'.   
data = json.loads(input)
device = indigo.devices[data["deviceId"]]
type = data["deviceType"]
value = data["deviceValue"]

And now we're stuck, because there's no way to update an arbitrary state in any random Indigo device from a script. Which is why both of the previous MQTT plugins had their own device types.

I'm looking at how I want to handle that now. It'll probably be a few days before I get to that. I want to get a little more done on the broadcast side first.

[jay (support)]

A couple of ideas here that don't require any further plugins or development by FlyingDiver:

• For simple on/off devices, use a Virtual On/Off device with action groups that don't do anything (or perhaps log or something) and just update the state variable defined by them directly. This would also have the benefit that if this plugin defines actions to publish information on a topic, you could use the actions in the action groups for on/off/toggle. So, Indigo controlling the device directly would provide a 2-way mechanism with MQTT.
• For dimmers (or on/off devices), you can create an X10 device (using the Lamp Module type), then just control the device using the standard Indigo dimmer commands (on/off/dim/brighten/set brightness) - you don't need to enable any X10 or Insteon interface. The device will show up in red in various places if there isn't an X10 capable interface enabled. If you want to avoid that, you can put "- sample device -" (without quotes) in the Notes field for the device and Indigo will show the device as if it had the interface enabled. This same technique would work for sprinklers

There are various 3rd party plugins that may also enable "pseudo" device types which will work in these scenarios.

I've added an item to our feature request list to think about how best to provide these kinds of shim devices directly in Indigo in the Virtual Devices interface. This would likely greatly simplify plugins like this that provide a general communication channel.

[FlyingDiver]

Jay - I am correct in thinking that any random plugin cannot modify state for another plugin's devices, right?

[jay (support)]

Jay - I am correct in thinking that any random plugin cannot modify state for another plugin's devices, right?

You must use the facilities provided by Indigo or the plugin. Any built-in device type can be manipulated by using the standard Indigo commands (which may or may not work as expected based on what is providing the specific device instance and how those are handled by the interface/plugin). For plugins that define custom device types, the plugin itself has to provide actions to manipulate states if that makes sense in their context. A plugin of course could also provide actions for directly modifying built-in states.

We intentionally prevent external write access to device states/properties/configs which would present both a security risk and the possibility that the device would become inoperative based on another plugin/script manipulating it's states...

[FlyingDiver]

We intentionally prevent external write access to device states/properties/configs which would present both a security risk and the possibility that the device would become inoperative based on another plugin/script manipulating it's states...

Yeah, just what I remembered. The Masquerade plugin does some fancy footwork using defined actions, but those are all coded for specific use cases. I really don't want to do that here.

There really does need to be some sort of virtual (or shim) devices with the capability for all standard device types, just for this scenario. I'm pretty much resigned to implementing another set for MQTT, because a generic solution is a long way off.

[mreyn2005]

Is calling the local REST web API an option from within the python script?

Code: Select all

input = '{"deviceValue": "ON", "deviceType": "OUTLET", "deviceId": 12345}'.   
data = json.loads(input)
device = indigo.devices[data["deviceId"]]
type = data["deviceType"]
value = data["deviceValue"]

// psuedo code:
http.get('localhost:8176/devices/' + urlEncode(device.name) + '.json?isOn=' + urlEncode(value) + '&_method=put')

It's only a little trickier with Digest auth turned on, but still pretty straight forward...

Thanks,
Matt

[FlyingDiver]

Is calling the local REST web API an option from within the python script?

I suspect it would work, for things you can do via that API, but boy is that ugly.

The question still remains, what kind of device would you create that you would control this way? An actual device you want to mirror from the topic? Or a virtual device you want to represent in Indigo?