Unnamed nodes?

[ScheintodX]

Hi. First thanks for your work. It makes my life a lot easier!

As far as I can see an mqtt topic always consists of:

BASE_TOPIC / DEVICE_ID / node / subscription

e.g. brewery/fan1/motor/mode

and will be extended with "set" for setting it.

My problem now is that in order to fit with my other devices I would like to use something like:

brewery/fan1/motor/set on

This doesn't seem possible, or is it?

[marvinroger]

You don't actually set the motor to on, but you set its on property to true or false. Or you can set its state property to on or off, it's a matter of taste.

So in your case it would look like this: brewery/fan1/motor/state/set = on

I am not sure I understand your question though, if this is the case please provide what your motors can do (what is the mode, etc.)

[ScheintodX]

Hi Mavin, thanks for your quick reply. How are you?

If you wanted to answer "fine, thank you" than that's what I want my device to do, too ;)

I know that I can introduce another level (in fact two) to the mqtt topic in order to make it work. My question is, can I avoid it, because I don't need it. My device is a fan controller. In it's implest form I would be happy with:

brewery/fan1/set on ---> brewery/fan1/status = on

This I can't do because I need a node (and brewery/fan1 has to be configurable on device setup.)

My next try would be

brewery/fan1/fan/set on ---> brewery/fan1/fan/status = on (or motor or what ever)

But this I can't do (or can I? this is the question) because I need something to subscribe for

So currently I'm using

brewery/fan1/fan/mode/set on --> brewery/fan1/fan/mode/status

which is working but really much longer than I need it to be.

But of cause it's primary a matter of taste and in my case it's a matter of making it compatible with what I already have. My other controllers are currently not using homie so I'm not limited there but I'd like to port them over because I really like it. But then I would have to alter: The devices of cause and in addition my simulation software (used to develop the web app without hardware), the webserver/master-controller/bridge and the web-client. For multiple devices.

I could look into it and provide a patch if that's what is needed.

Thanks.

[marvinroger]

Well "fine, thank you" :innocent:

Unfortunately this project is tightly linked with the Homie convention. This framework works around the notion of devices, nodes and properties. It would be too complicated to change this (the Homie convention is already used in multiple production setups) and the outcome would be really tiny. Moreover, adding /mode to a topic is not too much of an issue I think, so I won't, sorry!

[jamesmyatt]

Is there also an issue that the status topic that the homie node publishes to and the command topic that it subscribes to must be different?

[marvinroger]

@Nzbuu this is not an issue, it's how it's meant to work. This provides pessimistic feedback from the device (you publish to the /set and the device "confirms" it received the new state by sending its new state back).

[jamesmyatt]

@marvinroger , I agree completely. That was the point I was trying to make by asking a "clever" question. I guess I meant the opposite of "issue".

If you had it so that both the homie node and the "command" nodes could publish to brewery/fan1/motor/state then you wouldn't know whether a message message is a command or feedback. In particular, the homie node would get it's own status messages back appearing as if they were commands!

[marvinroger]

@Nzbuu my bad! :wink:

[marvinroger]

Closing it as this would be a too heavy change for little to no benefits.