$type in node

[autolog]

Hi Kevin,

Does the $type have any significance to the MQTT App or does it just use $properties to determine the device's capability e.g. onoff, dim.

If it is significant, is there an approved list somewhere? I couldn't see anything in https://homieiot.github.io/specification/

I have just now got Indigo publishing devices for discovery, HE discovering them and changes in HE being reflected back to Indigo and vice-versa. :)

How soon will the beta-3e be released to a wider audience as my Indigo plugin is now dependant on it for this work. At the moment, I am working with @cesarvog on it but would like to expand my testing to a few other users. Thanks. :)

[GledholtHall]

I have to write the docs yet so that could take a few days. Pre25 is likely tonight. You may have to provide two different versions in the meantime although I have provided access for any of referrals from you to the beta so far.

The $type is sadly lacking in homie definition and the types I have used are somewhat arbitrary. I use that payload for knowing what 'supported' nodes to pull from homie currently for discovery but it is inherited from the types published by Homey (another controller supporting homie). Whilst you can (and for the homie spec should) use the $properties payload that has no clue to the overall compound device type e.g. a robot lawn mower probably exposes a $property= onoff,.... payload.

HA Device Types are extensive but in their event stream they omit them for some devices

see also https://github.com/GledholtHall/beta-3/issues/12#issuecomment-1021931397

[autolog]

I had done some investigation as when I set the $type to 'relay' (which is what Indigo knows an on|off as), when the device was discovered it got added as an unsupported device even though it had an onoff property set.

I found a list of types in the MQTT Driver (around code lines 720-780) which suggested that 'switch' or 'socket' would work.

I changed the $type to 'switch' and did a re-discovery. It took several reloads of the plugin and a reboot of the C7 to get the new device correctly recognised as a switch. At one point I had two copies of the device, that's despite having removed all devices and cleared the enabled drop-down list.

Is there some sort of caching that could be picking up old versions?

[GledholtHall]

Interesting .. there is no caching except for browser issues. HE will allow duplicate devices as long as their DNI’s are different. In the absence of other idents I create the DNI’s from the topic detail which by definition must be unique but it doesn’t track name changes so you can easily mess it up by renaming a device.

pre25 is better and…. you can add and enable devices on the fly, no reboots. We need to just have a pow wow about types and what should be supported. I am using the Homey ones as that was the first app released but I’ll likely use HA’s later. I’ll assemble a list of those when I get a moment

[autolog]

I will hold off reporting any other issues until after I have got access to and installed pre-25.

[GledholtHall]

homie inward is a very sparse discovery implementation as there were no publishers of data. So I just added rudimentary dim, onoff and sensor values I think - the latter likely appearing as text devices in HE, as long as you have my MQTT Text driver installed. I have been playing with HE<>HE recently as well as Homey<>He so there’s little excuse.

possibly $type should just represent the type of device in the source controller and we should handle mappings to the destination but having standardised types defined makes it much easier… something homie doesn’t address

[autolog]

Are you suggesting that using HA format for publishing and likewise Discovery from my plugin would work better with your App?

[GledholtHall]

Oh yes, most definitely it’s more complete in my code, and the device types are defined.

I don’t know how much you know about that format but essentially you can keep the homie structure that you have already, the payloads can be published anywhere and homie is a good a place and structure as anything and your implementation then supports both standards. HA MQTT just adds one config topic to this that details what info is available where .. that’s all it does, for example

switch type with state available on homie/deviceone/onoff and control available via homie/deviceone/onoff/set allowable values true|false.

I’ll post an example of the json config payload later when I get home, or you can just enable it in my app and you’ll see example payloads on a config topic, one for each device.

beta3d supports MQTT HA format config publishing but lacked the reverse into HE. beta3e adds discovery into HE as a new option. It still needs expanding but it’s way more capable than my homie discovery.

HA documentation is good on this too. If you implemented this as well then you could directly connect HA, OpenHAB and Indigo for example (plus others) so HE is just one of many controllers you’d support. Your code is growing though !

[GledholtHall]

Ohh… this should work directly with HE using my app already.. Indigo -> HE

https://www.indigodomo.com/pluginstore/233/

use pre25 +. though

[autolog]

Interesting, could make my plugin Redundant ;)

[GledholtHall]

Well, not really, yours can just use homie and is bidirectional …