I understand following:
Data can be requested of the path ‘N//…’ sending a request on ‘R//…’
This can be perfectly demonstrated with for example MQTT-Explorer with topics emerging on that path.
Requests are made on the ‘DBus’. I don’t know what this actually means, but it sounds like a way to describe the internal implementation.
For 3rd party applications it is possible to introduce application specific ‘non Victron’ topics. Those topics do not exist on the DBus. It looks like making requests on those specific topics useless.
What is the correct way to deal with user or application specific topics? How to request ‘retained’ data on user specific topics?
I am the author of dbus-mqtt-devices, the protocol I designed for this uses a set of new topics under Devices top level namespace. These topics do not appear on the dbus and seperate from anything Victron are doing. This approcah works absolutely fine
I read the introduction of the library. As far as I understand it takes an additional prorocol to obtain values by the client on making a connection or an additional subscription. Please tell me if I understood well.
I managed to get non-dbus topics this way as well. But it shouldn’t not be like this. The standard mqtt protocol can do this vy itself.
Leaving out retaied data is causing the inability for the client to get data by the regular subscibing only.
Would you still call it the mqtt protocol if such essential part of it is not implemented?
I’m not sure I understand your issue. In my case MQTT is the just the transport by which a registration is processed. I gave you this link as an example of a 3rd party library that uses it’s own topics on MQTT broker runing on the GX device. In this use case retained messages would not help.
Is it the R, W, N topics that Victron uses for their dbus api that you don’t like? Or are you sayig that the MQTT broker does not support retained messages?
I understood that, to get information on the N mqtt-topic-path (path=namespace?), one needs to request on the R path.
To avoid lots of requests, topics are regularly updated, even if the value does not change. Downside is lots of trafic, but in this case for me no problem, but that is a problem it this trafic is send over expensive media (like a mobile network).
Just by connecting a client with property ‘clean session set’ Cerbo does not send retained messages. To be able for the client to get info on certain topics immediately a request must be send. I think that is not according to mqtt specification. It needs to request those needed.
But what I see is a client starting a ‘clean session’ cannot do requests on propriety paths, like it can do on the R path. This requires for a standard client and the broker special behaviour. Do I get that right?