Development: adding homie

[psyciknz]

I want to add homie for mqtt (as well as mqtt). This supports discoverability for home assistant and openhab (2.4 mqtt).

So I think https://github.com/mjcumming/HomieV3 might be a good one to integrate...mostly because it's v3 which is what is needed.

I think the best way to do it, it to create a copy of the MQTT_Interface.py and modify it.

But the main thing that is needed, is a list of all the 'things' that can be utilised. If I can read the code properly, the MQTT_Interface is only called when there's a value change. Is there a global registry of zones/partitions etc, or will I need to update the main classes so that when reading the items labels from the panel that Homie_MQTT_Interface is called to create all the items so they can be advertised.

[psyciknz]

So in Paradox.py, is self.data the list of items (and states) and await self.panel.update_labels() is where it's updated (as part of connect_async).

So to me this would be the logical place that I should fire off an advertise items to the interface manager, where if the interface supports it, it will broadcast all the panel labels.

[jpbarraca]

I think this should be done in a dedicated interface.
Paradox.py can notify the interfaces that it finished loading all labels and properties. This will happen after the labels are loaded and the first round of status messages is received.

[psyciknz]

So when I'm looking at the things that an interface can do, I can see "change" and handle_change. Change seems to add stuff to a queue that is then triggered off and processed by handle_change.

Do I have that correct?

I'm thinking of doing the same, making an advertise_items which adds to a queue, then a handle_advertise_items that will then take all those items, create nodes for them (which will have to be stored in the interface for later use) to advertise their existence.

Then when a change state is called, use the stored node to post out an updated state.

So all interfaces will have some new methods advertise_items and handle_advertise_items. But only my new Homie_mqtt_interface will do anything with them

[jpbarraca]

The change method is called with the initial state, and with changes. You can use this to register new items for advertisement.
Probably this will be enough for your use case.

[yozik04]

Maybe we want to integrate this one?
jalmeroth/homie-python#47
It is not merged yet. But will be some day.

[yozik04]

I want to propose architecture change for PAI.
We should use publish subscribe model for interfaces. Core will produce events and interfaces will subscribe to them. Every interface would listen to the events it wants.

[jpbarraca]

agree :) 0MQ?
There is the issue that interfaces may consult the Paradox class for some things, or send messages to Paradox. Your change would imply an extended decoupling, and the Paradox class would also receive events. With the asyncio implementation that is possible to be done.

[psyciknz]

Re using the jalmeroth one. I did look at that, but that’s v2 home and there’s a pr open for 3 but it hasn’t been touched in months. So while I have used that one in the past the mjcunming one is active.

I also think it fits in better with pai as each device is independent. With the other one, it has to track its own loop.

That said if enough people are keen I can switch.

[yozik04]

I have not inspected any of them. Just saw a link from main homie repo. I am ok with your proposal :)

[psyciknz]

The change method is called with the initial state, and with changes. You can use this to register new items for advertisement.
Probably this will be enough for your use case.

So after reading the labels, would I just iterate over all items and call interfacemanager.change?

[blademckain]

+1 need homie

[jpbarraca]

@psyciknz you will get full knowledge of the properties after the first round of status messages.
The interfaces will be notified for every property and its value. You can receive these events and keep the structure private in the interface.

[yozik04]

I have tried https://github.com/mjcumming/HomieV3 with openhab 2.4 MQTT binding on a temperature sensor. Seems OKish.

The bad thing that thing status changes to: OFFLINE - GONE periodically. But uptime is updated properly every 60 seconds.