smar000 / evoGateway

Python script for listening in and responding to evohome heating control radio messages
46 stars 17 forks source link

General questions including MQTT Message structure #56

Closed davidcreager closed 1 year ago

davidcreager commented 1 year ago

Hi,

Thanks so much for sharing this work. I have some very basic questions,

1) What do 'ctl_controller' and ''hgi_evo_gateway" refer to?

2) What is the design of the mqtt messages? One of my zones has the following topics

3) Another Zone evohome/evogateway/lounge/ctl_controller evohome/evogateway/lounge/hgi_evo_gateway This zone has a round thermostat and 3 x trvs. Slightly confused that the trvs or thermostat aren't appearing

4) Another zone, which I would have thought would have been identical to (2) above, ie it has a round thermostat and a trv. evohome/evogateway/dining/ctl_controller evohome/evogateway/dining/hgi_evo_gateway

Sorry if these are stupid questions, if I should be looking in a forum or wiki somewhere then please give me a pointer.

Thanks again

smar000 commented 1 year ago

Hi

  1. ctl_controller is your evhome screen unit (i.e. the main controller). hgi_evogateway is the nanocul device that the evogateway script is connecting to
  2. Not sure what you mean by the 'design of the mqtt messages'. If you mean how the topic is structured, it is by zone, followed by (a) devices registered to the zone and (b) the ctl_controllerand hgi_evogatewaydevices; ctl_controllerwill list data for that zone as transmitted by the controller, and the hgi_evogateway will list data that the nanocul device itself has picked up directly with its own radio.
  3. Again, not entirely sure what you mean. If devices are are not showing for a given zone, you may need to let the system search for a longer period to allow all devices to be fully discovered. Alternatively, you can manually add devices to their respective zones by editinig the schema file (if you have the device ID, this would be quicker - just follow the format of the other zones/devices).
  4. See answer to 2 above.
davidcreager commented 1 year ago

Thanks ....helps a bit.....By 'design' I am trying to understand what the messages mean and how the relate to any packet received.

I am looking at the Rames protocol from the wiki https://github.com/zxdavb/ramses_protocol/wiki at the start it refers to `The three main elements of any packet are:

the 3 device ids (e.g. 04:056057, 01:145038) for controllers, TRV, DHW relays, etc. the packet verb (I, W, RQ, RP) and code (e.g. 30C9, 10A0, and 0008) the payload (e.g. 0008310107FD0...), which can be decoded further`

I guess you translate the devices using the schema? and then depending on the verb/payload decode into one or more messages? What makes you produce multiple messages?

I also see lots of messages with the final part of the topic has '_ts' When are these sent?

Also, what is a _domain_FC_appliance_controller

smar000 commented 1 year ago

Yes, that is essentially it. As they come in, packets are interpreted and then published to an MQTT broker (i.e. in human readable form) such that the packet data can be used by other third party applications (e.g. in my case, such as openHAB). Multiple messages are produced if a given packet contains data for multiple zones. For example, the controller broadcasts a single packet containing the current temperature of each zone. My script takes this packet, and splits it into the individual zones before publishing to MQTT.

Anything with "_ts" is basically a timestamp of when that particular message was last updated.

_domain_FC_appliance_controller is a packet with its zone ID set as hex FC. This normally represents "appliance controllers" devices using the ramses_rf terminology.

davidcreager commented 1 year ago

Many thanks for the help