Motion Sensor

[ccoupe]

Hi, Are Motion sensors fully baked? (Most of my MQTT devices are motion sensors I built myself. I'm converting this one to be homie v3 compatible but motion sensors seems to be sort of unspecified.

Is this an acceptable homie layout?

Looking at the MQTT App code I see a comment that motion sensors don't have settable properties. Mine do! 'active_hold' which is the number of seconds after going active that it waits for another motion before sending an 'inactive'

[xAPPO]

Well - all virtual 'sensors' have no settable properties . I'm using the inbuilt virtual drivers and the HE one does not include active_hold so I'm afraid you will not be able to discover and automatically use this attribute. You would have to do it with your own device driver. What driver are you currently using that does support this ?

Maybe I could allow a device type switch to another device type like Omni/Multi that does support a settable attribute. I will have to think about how 'discovery' is currently handling a second property within a device. You might be able to use a 'virtual dimmer' as that has the two attribute, binary and level.

On the topic structure you have a homie top level device called 'family_motion1' and that has one $node that is called sensor. To flexibly add more sensors you should probably create multiple nodes and still have only one 'homie' parent device, so that is probably wrongly named - my app will only import from one homie device but will import any number of nodes.

In my import of a motion sensor I see I am using a $type=sensor , not motion and within that node I have a boolean $datatype which would normally be true|false (does yours have several reported states or just two ? ), you are also not reporting the $retained topic, although I do not use that anyway. Whether I should have a $type = motion I'm not sure. $types are a little vague in the homie3 spec and indeed how I use them. I am likely to add another topic to my exported homie devices that provides the HE driver name.

In the later active_hold property you are using an integer $datatype but do not have a $format topic or a $retained topic. I do use $format but only to establish the maximum level. However I may not currently discover this second property anyway, it certainly wouldn't be useful in the Virtual Motion Sensor.

An alternative approach... you could create one 'emulated' HA statestream advertisment for each sensor device and discover your sensors that way - you might find that less arduous than the homie3 protocol. I only use

device_class
friendly_name 
state

Each device must be presented in a suitable topic hierarchy of say (which I also use) hastatestream/binary_sensor/pir_twin_guest_motion/
There are other topics for categories instead of 'binary_sensor' for different types - some examples below.

Your settable 'active-hold' could be presented as an analog device - even a light

[ccoupe]

my app will only import from one homie device but will import any number of nodes.

That's an important detail. It makes sense if you're dealing with HA and the like. I have 3 esp32 devices. One motion sensor chip per device so three MQTT clients. I've got two pi's running a camera motion detector that I wrote so two more MQTT Clients.

$types are a little vague in the homie3 spec

Yes they are, re: my 'fully baked?' question. I've modified my device to do what your code accepts and my groovy driver to accept both 'true' and 'active' and the converse. As I mentioned on the Community board, It is now discoverable once I told it to only scan family_motion1

I don't need my active_hold property but it's conceptually consistent with motion sensors that do have settings (like the Hue sensor).

I'll look at the HA statestream - I'm certainly not tied to homie but it is close to working with you App & driver.

[Gledholt]

This is progressing but requires a few other pieces to be in place. In beta2 I support all attributes within one device having a different topic address and also using a JSON payload. I don't currently however support the same MQTT topic being used in different devices.

With JSON I end up with a many to many mapping requirement which is awkward and doesn't work well with my existing unique DNI based usage so that's being changed.

Now that's useful primarily for virtual devices but the homie discovery needs more for multiple properties but I haven't forgotten you..

[xAPPO]

Beta 3b is out and I believe pretty stable and feature complete. I'm going to be focusing on the homie structure a bit more now and in-particular the import to HE. In the longer term I will likely look to multiple homie device support and multiple MQTT brokers. Hopefully then this issue will go away.

Just wanted to keep you updated.