Changing _MQTT_TOPIC_PREFIX

[bigDvette]

I was able to set this to my custom topic prefix by changing the value in ratgoapi.py.  I have a lot of sensor going to a custom topic prefix I use in Home Assistant so would really like ability to use my open topic prefix via a config key:value.

After changing it, I am able to get the status and issue commands.  

Thanks for your work

 

[Goose66]

This comes down to design approach. In order to get it out quickly, the first version of the ratgdo plugin was based on the Tasmota plugin. The Tasmota plugin, like the ratgdo plugin, can support any number of devices. In order to simplify management of MQTT subscriptions for an arbitrarily large number of device, the Tasmota plugin relies on a top-down topic format, i.e., a broad topic prefix (in this case "tasmotans/") that supports a single subscription, and then narrowing topic segments for device ID and finally message type ("STAT", "CMND", "TELE"). Without this top-down topic format, you would have to create and manage separate subscriptions (and more specifically three distinct subscriptions) for each Tasmota device. If you were to have, say, 100 Tasmota devices in your HA system, you can see how this may get ungainly. The Tasmota plugin actually has a Custom Configuration Parameter for changing the broad topic prefix (though it's not documented), but allowing the full topic to be configured is not supported because of this top-level topic subscription limitation.

The ratgdo plugin, however, only really supports ratgdo devices, and this limits the total number of devices it would support, and thus the number of MQTT subscriptions that would be needed for each device to have its own subscription(s) (one command and one status topic per device). So getting rid of the need for top-down topic format is doable in this plugin. In fact, the HA discovery messages that are published by the ratgdo devices contain their command and status topics in the payload, thus no specific configuration of MQTT topics through Custom Configurations Parameters would be needed. As long as the topics you have configured work with Home Assistant and the HA discovery process, the ratgdo plugin should be able to get them in discovery and use them.

This is already on the roadmap for the plugin, and, while it's not a trivial change (the GDO nodes have to be coded to remember the topics and set their own subscriptions upon plugin restart), it should be included in the next release (3.1.x). It will mean you will have to delete your nodes and rediscover them when this release comes out, but all of your programs should continue to work.

 

Edited December 26, 2023 by Goose66

[bigDvette]

I don't know if I followed all that but for sure RATGDO allows you to set the topic prefix and you can change the discovery prefix. Mine is homeassistant for discovery as I didn't change it and  you use it as well.

The topic prefix is something you have to define in HA if you are using the MQTT plugin (UI discovery) with an external MQTT broker.  There you define and can only define a single Topic Prefix to listen for.    i had a bunch of other devices (weather, raspi stats) all using an external broker with a common prefix.  

It would seem that RATGO devices and your plugin support same format as tasmota.  In my case my topic prefix is JRD-Automation.  In HA i set that as the topic prefix and all devices show up under JRD-Automation as devices and their discovery definition are in home assistant.  

So in this case you have fixed the "broad topic prefix" to ratgdo/  under that are the devices  There is no reason you couldn't have actually left the broad prefix at tasmotans/ as long as you setup the device to publish to that topic it doesn't matter if there are other devices in that topic does it?  I changed the MQTT_TOPIC_PREFIX in the API.py file and discovery works just fine and only "Sees" the ratgo devices and adds them to the nodeserver.

Home assistant for their MQTT plugin only sees a single topic_prefix but you can have all kind of devices under that topic.  So in many ways the broad top level topic is arbitrary and is simply the thing that is subscribed to.  I don't think I was proposing a subscription per device which is what it sounds like you are thinking the change I requested would require.

So for clarity, I'm using the current plugin, changed it to use my existing top level prefix and it seems to see, find and report status for all the ratgo devices in that topic just as if that top level prefix had been what you had fixed at ratgdons/.

Now one thing the plugin doesn't do is get current state when the plugin starts up and simply shows unknown for door state, obstruction and lockout . After the doo is operated it sees the state changes and updates, but obstruction stays unknown because nothing has triggered a change.  You can see all states are set in the MQTT device data but the plugin still shows unknown in AC.

So I don't think you need to support multiple subscriptions unless people want you to talk to multiple brokers and then you can just install the plugin more than once.  As such (since I can see this is working), all that is needed is an ability to override the default top level prefix unless I am really missing something it would seem to be trivial, but as I said I didn't follow all of your response because some of it seemed to not make sense with what I see happening in the plugin already.  

Happy to beta test any work on this plugin. I have 3 RATGDO devices working with HA and in ISY now.

 

[Goose66]

If you restart MQTT explorer, do you still see all of those statuses? Or is it only after MQTT explorer has been running for a while that the all get values?

[bigDvette]

Those statuses are always there if I disconnect and reconnect MQTT Explorer even before any elements are updated in MQTT. This is the case for all topic / sub-topic items in JRD-Automation top level topic. I can confirm in HA it pulls in the current state in the MQTT device when it subscribes to the Broker as I have status even before any devices have been controlled.

[Goose66]

I’m not seeing that from my ratgdo connected to my Polisy MQTT broker.

[bigDvette]

Interesting, I am using a mosquitto service on my docker cluster.  Now I don't know if you are using it in dry contact mode or in version 1 or 2 mode, My gate is in contact mode and only shows availability and door values. I don't see anything in the json that indicates what mode it is in (for instance dry contact mode does not support a light or lockout.  My lockout in AC never changes from Unknown no matter how many times I operate the door even though I do have a lock and it is locked it always shows unlocked. That may be because my garage door is an 8500 and uses v1 protocol.

 

[Goose66]

Mine is dry contact mode and I never get light or lock status. But that’s not really germane to my point.

To the point of initial status, when you start the plugin, the initial subscription to the MQTT should cause any retained messages to be sent. For example the plugin gets the online status right away.

In my case, however, I don’t get a doorstate until the doorstate changes. And if IIRC, when I shutdown MQTT explorer and restart it, the door state is gone until the state changes. I can look at it when I return on Jan. 2. Moreover, there doesn’t appear to be an MQTT command I can send that forces the ratgdo device to update all states (e.g., as in the case of Tasmota), so we may have to log an issue with the ratgdo developer to either add such a command or change the retention of the state messages.

Edited December 30, 2023 by Goose66

[bigDvette]

I am getting states on startup.  I removed all nodes and started over.  If there is way to make the top level prefix configurable as it doesn't require a subscription per device, then I think it work well.  My states represent what I see in MQTT explorer with the contact sensor gate not getting values for lock or obstruction so makes sense they are unknown in AC.