Events in MQTT

[mnlipp]

In the UI, I can see a device's events (Node/Groups/OTA/Events/...) But I cannot find something corresponding to this in the MQTT explorer. The closest is .../node_notifications. But there's an awful lot of information there. All I need is a few decices' events as I can see it in the GUI. Is this somehow available over the broker?

Background: I have a battery driven wall switch. Propably due to this, the information about a button pushed etc. does not appear in a topic (as is the case for a switch connected to the power line, from which the information is available in a topic .../scene/001, 002).

[robertsLando]

All I need is a few decices' events as I can see it in the GUI. Is this somehow available over the broker?

Just enable Send Z-Wave Events in Gateway settings, then subscribe to events topic

[mnlipp]

I have enabled Send Z-Wave Events. Should there be a node specific topic under _EVENTS? All I see are the general ones (such as the initially mentioned .../node_notifications) which have this large payload. My question is if there are also "filtered" topics with only one node's events, as I can see in the GUI.

[robertsLando]

My question is if there are also "filtered" topics with only one node's events, as I can see in the GUI.

If you check linked docs them should be available by subscribing to <mqtt_prefix>/_EVENTS_/ZWAVE_GATEWAY-<mqtt_name>/node/<event_name>

[mnlipp]

"Problem" is: the event is a value_update. Here's what I see:

As far as I understand, I can get the information that I need from node_value_updated. Now, that's about 23 kbytes for each change. It seems a big waste of CPU cycles to subscribe to this topic and extract from this data (which also needs to be filtered by device -- I'm not interested in value updates from all devices) the information that is shown in the GUI "per device" and with only the required information (the actual change):

Wouldn't it be useful to have the information shown in the GUI in a topic such as .../<room>/<name>/_EVENTS_?

[robertsLando]

In case of a notificaiton it is published on a dedicated topic.

There is no reason IMO to have another topic for all node specific events as the informations you need are already published to MQTT and there would be lot of duplicated things around in that case, it could slow down network when running on slow devuces like Rpi and big networks. My suggestion is to simply subscribe to the things you need

[mnlipp]

I've taken a closer look at the payload of node_value_updated. It's an array of two objects, where the second seems to follow the structure that you have linked to. But the first seems to be a complete description of the current state of the device, including an event queue. This is what makes the payload so big. Out of interest, what's the use case for sending all this information together with a value change?

My suggestion is to simply subscribe to the things you need

Regarding the main topic (of this discussion): I've just found out that the battery powered wall controllers can be configured to either send direct commands to an association group or send the scene-information (as the power-line switch mentioned above does by default). That's why I haven't seen any messages in the device specific topics (.../scene/...) of the switch. Sorry, but the software I was using before somehow hid that difference, so I wasn't aware of it.

Nevertheless, this "direct control of associated devices" makes sense, because it works without a controller (fail-safe). If I want to preserve this behavior, subscribing to node_value_updated is the only way to go if I want to (additionally) receive the information directly. As an alternative I can, of course, subscribe to the topic of the device that is controlled by the wall switch, thus getting the information "indirectly". I'll have to think about this.

Thanks for your patience.

[robertsLando]

@mnlipp I still don't understand why you need to subscribe to that topic, that is a general topic used for events (that in most cases are not needed at all). Everything published under that topic is also published in a dedicated valueId topic that is like the one used to set values without the /set suffix. That's the way the MQTT Gateway should be used to read/write values

[mnlipp]

is also published in a dedicated valueId topic

Where is this valueId topic? I cannot find it (see screenshot above). Pushing the button triggers a message in node_value_updated. That's it.

[mnlipp]

Ah, sorry. I think you mean the .../scene/... topic. Well, as stated above, the wall controller doesn't send the events for updating this. It only sends a notification. See Configuration parameters 11-14, setting 1-3 vs setting 4 (the latter is what my other, power-line powered switch does by default).

[robertsLando]

It only sends a notification.

Notifications are treated as valueIds like I said in my previous comment so there must be a valueId for it

[mnlipp]

Okay, found it. Somehow I missed the change, don't really know why, maybe because there's so little to see or because I was expecting something completely different. It's actually in the second element of what I get from node_value_updated:

{
  "data": [
    { "[omitted]" },
    {
      "commandClassName": "Basic",
      "commandClass": 32,
      "property": "currentValue",
      "endpoint": 0,
      "newValue": 255,
      "prevValue": 0,
      "propertyName": "currentValue",
      "nodeId": 3
    }
  ]
}

What changes is X-32-0-currentValue (Basic), which makes sense. Pushing one button (of a pair) the currentValue is set to 255, pushing the other sets it back to 0. This is because the switch considers the controller (node 1) simply as some other device which it turns on or off (as mentioned above "direct control of associated devices" with "some bulb" and the controller being in the association group). And of course I can subscribe to X-32-0.

I've completely misunderstood how this switch works. Thanks for your time!

[robertsLando]

Glad you fixed it, mark this as answered if possible, thanks :)

[mnlipp]

Glad you fixed it, mark this as answered if possible, thanks :)

Had to move it to from "General" to "Q&A" in order to do this. And as our last exchange used replies and was started by me, it now says "answered by mnlipp". Sorry about that, but I don't see any way around this.