You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to connect a custom client to Z2M and have noticed several inconsistencies in the API topics.
So I'd like to share my thoughts with you and welcome feedback on whether there's a pattern I haven't seen yet, or whether it has simply grown over time. Since MQTT is completely new to me, my view of this project may be very naive - so please don't judge me.
Bridge topics vs. device topics
I see the topic segments /bridge for the coordinator and Z2M config, but for devices it is /<device name>...
Will I run into a conflict if I name a device "bridge"?
Since the coordinator is also a node in the mesh, would it make sense to treat it in the same way? (What about multiple?)
/<bridge name> & /<device name> or use a different style which is more easy to subscribe like
/bridge/<bridge ident> & /device/<device ident>.
Bridge availability vs. device availability
It is confusing to me, that ...
/bridge/state seems the same like the /device/availability
/bridge/info is kinda /device/state
Transactions vs. requests vs. responses
It looks mixed here and I have problems to understand how to deal with the transaction topics:
Some use a /bridge/request + /bridge/response combo, while others use the request topic only.
The scene management is totally different than the rest and not possible to filter via path.
Device related vs. Bridge related topics
I know a lot of management technically happens in the coordinator/bridge. But does it make sense to always add the /bridge segment for mostly everything? I wonder if a more "RESTful" approach would help understanding the topics and get rid of request & response:
/device/<device ident>/availability
/group/<group ident>/devices
/bridge/<bridge ident>/devices
/scene/<scene ident>/recall
/network/open
I hope someone could explain some of the details to me and maybe, if it makes sense, we can improve some things in a future API v2 =)
I tried to build myself an index of all the topics, to help understand the patterns.
exporttypeTOPIC_DEFINITIONS='bridge/definitions'exporttypeTOPIC_DEVICES='bridge/devices'exporttypeTOPIC_EXTENSIONS='bridge/extensions'exporttypeTOPIC_GROUPS='bridge/groups'exporttypeTOPIC_LOGGING='bridge/logging'// ---------- Bridge ----------exporttypeTOPIC_BRIDGE_INFO='bridge/info'// should be bridge/state ?exporttypeTOPIC_BRIDGE_STATE='bridge/state'// should be bridge/availability ?exporttypeTOPIC_BRIDGE_CODE_ADD='bridge/request/install_code/add'exporttypeTOPIC_BRIDGE_NETWORK_OPEN='bridge/request/permit_join'exporttypeTOPIC_BRIDGE_OPTIONS_REQUEST='bridge/request/options'exporttypeTOPIC_BRIDGE_RESTART_REQUEST='bridge/request/restart'exporttypeTOPIC_EXTENSION_WRITE='bridge/request/extension/save'exporttypeTOPIC_EXTENSION_REMOVE='bridge/request/extension/remove'exporttypeTOPIC_BACKUP_REQUEST='bridge/request/backup'exporttypeTOPIC_BACKUP_RESPONSE='bridge/response/backup'exporttypeTOPIC_TOUCHLINK_IDENTIFY_REQUEST='bridge/request/touchlink/identify'exporttypeTOPIC_TOUCHLINK_IDENTIFY_RESPONSE='bridge/response/touchlink/identify'exporttypeTOPIC_TOUCHLINK_RESET_REQUEST='bridge/request/touchlink/factory_reset'exporttypeTOPIC_TOUCHLINK_RESET_RESPONSE='bridge/response/touchlink/factory_reset'exporttypeTOPIC_TOUCHLINK_SCAN_REQUEST='bridge/request/touchlink/scan'exporttypeTOPIC_TOUCHLINK_SCAN_RESPONSE='bridge/response/touchlink/scan'// ---------- Groups ----------exporttypeTOPIC_GROUP_CREATE='bridge/request/group/add'exporttypeTOPIC_GROUP_REMOVE='bridge/request/group/remove'exporttypeTOPIC_GROUP_RENAME='bridge/request/group/rename'exporttypeTOPIC_GROUP_EXTEND='bridge/request/group/members/add'exporttypeTOPIC_GROUP_REDUCE='bridge/request/group/members/remove'exporttypeTOPIC_MAP_REQUEST='bridge/request/networkmap'exporttypeTOPIC_MAP_RESPONSE='bridge/response/networkmap'// ---------- Devices ----------exporttypeTOPIC_DEVICE_AVAILABILITY= `${string}/availability`
exporttypeTOPIC_DEVICE_STATE= `${string}/state`
exporttypeTOPIC_DEVICE_STATE_QUERY= `${string}/get` // TODO: is polling required in some place?exporttypeTOPIC_DEVICE_STATE_WRITE= `${string}/set`
exporttypeTOPIC_DEVICE_CONFIGURE_REQUEST='bridge/request/device/configure'exporttypeTOPIC_DEVICE_INTERVIEW_REQUEST='bridge/request/device/interview'exporttypeTOPIC_DEVICE_REMOVE_REQUEST='bridge/request/device/remove'exporttypeTOPIC_DEVICE_RENAME_REQUEST='bridge/request/device/rename'exporttypeTOPIC_DEVICE_OPTIONS_REQUEST='bridge/request/device/options'exporttypeTOPIC_DEVICE_BIND_REQUEST= `bridge/request/device/bind`
exporttypeTOPIC_DEVICE_UNBIND_REQUEST= `bridge/request/device/unbind`
exporttypeTOPIC_DEVICE_OTAU_CHECK_REQUEST='bridge/request/device/ota_update/check'exporttypeTOPIC_DEVICE_OTAU_EXEC_REQUEST='bridge/request/device/ota_update/update'exporttypeTOPIC_DEVICE_ATTRIBUTE_WRITE= `${/*device*/string}/${/*attribute*/string}/set`
exporttypeTOPIC_DEVICE_SCENE_WRITE= `${string}/set`
exporttypeTOPIC_DEVICE_SCENE_RECALL= `${string}/set`
exporttypeTOPIC_DEVICE_SCENE_REMOVE= `${string}/set`
exporttypeTOPIC_DEVICE_DEFINITION_REQUEST='bridge/request/device/generate_external_definition'exporttypeTOPIC_DEVICE_DEFINITION_RESPONSE='bridge/response/device/generate_external_definition'
The text was updated successfully, but these errors were encountered:
I am trying to connect a custom client to Z2M and have noticed several inconsistencies in the API topics.
So I'd like to share my thoughts with you and welcome feedback on whether there's a pattern I haven't seen yet, or whether it has simply grown over time. Since MQTT is completely new to me, my view of this project may be very naive - so please don't judge me.
Bridge topics vs. device topics
I see the topic segments
/bridge
for the coordinator and Z2M config, but for devices it is/<device name>
.../<bridge name>
&/<device name>
or use a different style which is more easy to subscribe like/bridge/<bridge ident>
&/device/<device ident>
.Bridge availability vs. device availability
It is confusing to me, that ...
/bridge/state
seems the same like the/device/availability
/bridge/info
is kinda/device/state
Transactions vs. requests vs. responses
It looks mixed here and I have problems to understand how to deal with the transaction topics:
/bridge/request
+/bridge/response
combo, while others use the request topic only.Device related vs. Bridge related topics
I know a lot of management technically happens in the coordinator/bridge. But does it make sense to always add the
/bridge
segment for mostly everything? I wonder if a more "RESTful" approach would help understanding the topics and get rid ofrequest
&response
:/device/<device ident>/availability
/group/<group ident>/devices
/bridge/<bridge ident>/devices
/scene/<scene ident>/recall
/network/open
I hope someone could explain some of the details to me and maybe, if it makes sense, we can improve some things in a future API v2 =)
I tried to build myself an index of all the topics, to help understand the patterns.
The text was updated successfully, but these errors were encountered: