search

synman / OctoPrint-MqttChamberTemperature

1 stars 1 forks source link

More flexible MQTT Parsing #2

Open JohnHind opened 10 months ago

JohnHind commented 10 months ago

Nice work and much needed!

But this probably only works for people who have control over the format of the MQTT messages used by the hardware sensor and actuator. The following suggestions would make it more flexible:

  1. For each MQTT topic, have an additional field for a JSON key. If specified it would parse the corresponding value out of an arbitrary JSON message.
  2. For temperature control, make subscription to a state topic optional. If not selected, it would deduce it (i.e. if the temperature is below threshold and not rising, issue the turn on request, if it is above the threshold and not falling, issue the turn off request).
  3. Allow separate state on and state off strings to be specified for current state and requested state. This would allow JSON strings to be specified for the requested state.
andreasbrett commented 8 months ago

Agree. It would definitely help to provide a JSON key to extract temperature data from. Would massively improve user experience and allow easy setup in zigbee2mqtt and/or home assistant setups.

devbar commented 6 months ago

5 I made a shot

synman commented 6 months ago

I'll take a look at the PR this weekend and see about merging it.

I was also considering adding a regex match option.

synman commented 6 months ago

merged and bumped release to 0.0.3 ... will close this issue after it bakes for a couple weeks

synman commented 6 months ago

appears to be working fine .... something I did note post release was documentation updates are missing for this. it would have been good to have had readme updated to include the details.

andreasbrett commented 6 months ago

works for me. thanks to all involved.

JohnHind commented 6 months ago

Many thanks, @devbar and @synman. All it needs now for full flexibility is:

  1. The same JSON parsing capability for 'Current State Topic'.
  2. Separate definitions for the payloads strings of 'Current State Topic' and 'Requested State Topic'.

My system has a 'report' topic, payload a JSON string containing the current temperature and the current state of the heater relay, and a 'command' topic, payload a JSON string containing a 'channel' key one of which is the heater switch, and a 'value' key, 0 for off, 1 for on. While I have now written a broker which translates the topics, and @devbar change enabled me to retire the translation of the Temperature Monitoring topic, the changes above would allow this broker to be retired completely.