mqtt input

[segaura]

Now that mqtt output plugin is present and working very well, I missed a lot the possibility to send mqtt input to pyHPSU, also.

I implemented a simple MQTT Daemon.
By now it is an option of pyHPSU.py, --mqttdaemon, only this code file has been modified.
This is the excerpt from the mode section of the new README.md

4. MQTT Daemon mode
pyHPSU starts in daemon mode, it subscribe an MQTT topic and listen forever waiting for commands.
MQTT coordinates are specified through configuration file: the same property used by mqtt output plugin plus an additional COMMANDTOPIC.
The daemon subscribe to the topic

  PREFIX / COMMANDTOPIC / +

e.g.
  configuration file (e.g. /etc/pyHPSU/pyhpsu.conf)
  ...
  [MQTT]
  BROKER = 192.168.1.94
  PREFIX = myhpsu
  COMMANDTOPIC = command
  ...

  root@rotex:# pyHPSU.py --mqttdaemon

  user@anothersystem:# mosquitto_pub -h 192.168.1.94 -t "myhpsu/command/t_flow_day" -m 29

  set the parameter t_flow_day to 29°C

Proposed code is on top of the branch with the revised log management (logrevision branch in segaura repo, testing in Spanni26 repo), this is the latest commit

segaura@8fc6ae2

Coding is not complete, --mqttdaemon can't live along other "command/output" options, like -a, -c, -o, ..., it has been tested alone only, so far.
Moreover, as with previous commits, I tried to stick with existing code setup, avoiding refactoring wherever possible: this is not ideal but I think it is the correct "first step".
Other changes included:

• code prevents writing to a readonly HPSU parameter and exit(9) while logging an error
• additional debug and info log lines has been added to code

NOTE: current implementation is dedicated to "write" commands, in the next commit I plan to enable "read" command (mqtt daemon publish) and also to enable automatic read after write (e.g. mqtt daemon receives a write command in the subscribed topic, executes it, read the changed value back from hpsu and publish it on mqtt)

[pdcemulator]

Very cool, with this we will be able to start water heating from remote. Thank you so much!

[segaura]

Thank you, after code stabilization I'd love to see this containerized by someone :-)

Now I added the possibility to read, also (too stupid I did not included it before), this is the modified README.md section

4. MQTT Daemon mode
pyHPSU starts in daemon mode, it subscribe an MQTT topic and listen forever waiting for commands.
MQTT coordinates are specified through configuration file: the same property used by mqtt output plugin plus additional COMMANDTOPIC and STATUSTOPIC.
The daemon subscribe to the topic

  PREFIX / COMMANDTOPIC / +

and publish to the topic

  PREFIX / STATUSTOPIC / <hpsu-command-name>

publishing to COMMANDTOPIC with value '' or 'read' results in property red from hpsu and published to STATUSTOPIC
publishing to COMMANDTOPIC with another value results in pyHPSU trying to change that value on specified hpsu property

e.g.
  configuration file (e.g. /etc/pyHPSU/pyhpsu.conf)
  ...
  [MQTT]
  BROKER = 192.168.1.94
  PREFIX = myhpsu
  COMMANDTOPIC = command
  STATUSTOPIC = status
  ...

  root@rotex:# pyHPSU.py --mqttdaemon

  user@anothersystem:# mosquitto_pub -h 192.168.1.94 -t "myhpsu/command/t_flow_day" -m 29

  set the parameter t_flow_day to 29°C

e.g.
  same config 

  root@rotex:# pyHPSU.py --mqttdaemon

  user@anothersystem:# mosquitto_pub -h 192.168.1.94 -t "myhpsu/command/t_dhw" -m read

  publish the current value of t_dhw red from hpsu into this topic

  myhpsu/status/t_dhw

new commit is here

published values on mqtt are retained to simplify dashboard creation, but current format does not include timestamp so it is not known how old is a retained topic ...definitely an area to improve after feedback gathering

[pdcemulator]

That container part is already done: https://hub.docker.com/r/pdcemulator/pyhpsu/ :-)

[segaura]

Sure, I know, I hope the Dockerfile will reside in this repository, ultimately

[segaura]

Latest commit on my repo includes some stabilization on this feature.

• mqttdaemon publishing to a special "status" topic is both not necessary and probably wrong, the same topics of mqtt output plugin can be used
• after a write an new read+publish is automatically issued
• configuration for QOS, RETAIN and ADDTIMESTAMP have been added, so far they are used only in mqttdaemon mode, not in mqtt output plugin ...ADDTIMESTAMP=False write only the parameter value into the topic, as mqtt output plugin does, ADDTIMESTAMP=True write a JSON like the JSON output does, including name, resp and timestamp properties
• mqttdaemon mode can be used along all other modes, specifically automatic mode and more specifically automatic mode with mqtt output
• mqttdaemon mode present itself with a specific client name to the mqtt broker, to avoid being disconnected by the mqtt output plugin (a "-mqttdaemon") suffix is added to the configured client name

4. MQTT Daemon mode
pyHPSU starts in daemon mode, it subscribe an MQTT topic and listen forever waiting for commands.
MQTT coordinates are specified through configuration file: the same property used by mqtt output plugin plus additional COMMANDTOPIC and STATUSTOPIC.
The daemon subscribe to the topic

  PREFIX / COMMANDTOPIC / +

and publish to the topic

  PREFIX / <hpsu-command-name>

publishing to COMMANDTOPIC with value '' or 'read' results in property red from hpsu and published to mqtt (same topics used by mqtt output plugin)
publishing to COMMANDTOPIC with another value results in pyHPSU trying to change that value on specified hpsu property and than re-reading the same property and publishing the obtained value

e.g.
  configuration file (e.g. /etc/pyHPSU/pyhpsu.conf)
  ...
  [MQTT]
  BROKER = 192.168.1.94
  PREFIX = myhpsu
  COMMANDTOPIC = command
  ...

  root@rotex:# pyHPSU.py --mqttdaemon

  user@anothersystem:# mosquitto_pub -h 192.168.1.94 -t "myhpsu/command/t_dhw" -m read

  publish the current value of t_dhw red from hpsu into the following topic

  myhpsu/status/t_dhw

e.g.
  (with same config)

  root@rotex:# pyHPSU.py --mqttdaemon -a -o mqtt

  user@anothersystem:# mosquitto_pub -h 192.168.1.94 -t "myhpsu/command/t_flow_day" -m 29

  set the parameter t_flow_day to 29°C, meanwhile pyHPSU is running in automatic mode and publishing periodically to the appopriate mqtt topics

  myhpsu/status/t_dhw

[segaura]

I have reached a decent milestone, code is functionally complete, although inherently bad in terms of modularization and object orientation.
I'm also not happy of having changed it a lot, probably making it difficult for who is accustomed with previous versions.
Anyway it works, I am using it consistently since many days, with auto mode posting to influxdb and mqtt and with mqttdaemon active so I am able to send mqtt command forcing new values and getting immediate feedback of the modification.

In case someone's interested or can give me further suggestions, it starts at boot time with systemctl with a service defined like this

$ more /etc/systemd/system/hpsu.service
[Unit]
Description=HPSU in auto mode with output to influxDB and MQTT plus MQTT Daemon mode activated
Requires=canable.service
After=canable.service
After=network-online.target

[Service]
Type=simple
ExecStartPre=
#EnvironmentFile=/etc/pyHPSU/pyhpsu.conf
ExecStart=python3 /usr/bin/pyHPSU.py -a -o influxdb -o mqtt --mqtt_daemon --log_level WARNING --log /tmp/pyHPSU.log
ExecReload=
ExecStop=
Restart=on-failure
WorkingDirectory=/root
User=root

[Install]
WantedBy=multi-user.target
#Alias=hpsu.service

where canable.service is another custom service that brings up my can0-friendly-dongle.

The commit I am talking about is here and it can be maybe merged on the testing branch if decided it is the right thing to do.

[Spanni26]

Make a PullRequest and I will merge git so everyone can test it. :)
Thanks for the contribution

[martinbischofff]

Yes please. I'd like to volunteer to test it.

[svde]

I've been testing it over the last week. I've actually updated to https://github.com/segaura/pyHPSU. It has been working fine.

Needed to adjust hpsu.service as follows:

-EnvironmentFile=/etc/pyHPSU/pyhpsu.conf
-ExecStart=/usr/bin/pyHPSU.py -a
+ExecStart=/usr/bin/pyHPSU.py -a -f /etc/pyHPSU/pyhpsu.conf --mqtt_daemon -o MQTT

The EnvironmentFile doesn't seem to do anything.
In ExecStart:

• I needed to specify the configuration file (it doesn't automatically use a default configuration file)
• It doesn't take the MQTT output from the configuration file, needed to put "-o MQTT" into the service file

I'm looking into controlling heat_slope, t_dhw_setpoint1 and t_room1_setpoint from my home automation system.

Q: Does anyone have experience which values are accepted for t_dhw_setpoint1 and t_room1_setpoint? The app allows for temperatures with half a degree difference (20.0, 20.5 for t_room1_setpoint). Did somebody try sending values like 20.1 (one decimal) or even 20.25 (2 decimals)?

I noticed another hpsu project on github: https://github.com/weltenwort/py-hpsu-monitor

[segaura]

I also commented the EnvironmentFile row because it is useless now. Default configuration file path is hardcoded in pyHPSU.py and can be overridden by cli option.
Default value is exactly the same you are excplicitly setting so you can omit it, for instance my corresponding row is this

ExecStart=python3 /usr/bin/pyHPSU.py -a -o influxdb -o mqtt --mqtt_daemon --log_level WARNING --log /tmp/pyHPSU.log

As of today, it is the systemd unit file that has been hammered to work with pyHPSU more than pyHPSU designed to conform with systemd.

I confirm the [MQTT] section of the configuration file is meant to provide MQTT related details in case -o MQTT is specified as a cli option. If [MQTT] configuration file section is not present, default pyHPSU.py hardcoded values are used (localhost, 1883, ...).

On segaura/pyHPSU I am a few commits ahead exactly because I am trying to solve issues regarding use with systemd.
Main problem is that pyHPSU sometimes stops working and systemd is not able to detect it and restart it automatically.
No success both specifying Restart=always or Restart=on-failure in the [Service] section of hpsu.service file. I tried setting Type=simple to monitor main thread, or Type=forking to make systemd consider the additional mqttDaemon thread exists, both without success.
I can open a dedicated issue with details if someone else is willing to look at this, let's say an "improve systemd integration" issue.

Regarding accepted values for t_dhw_setpoint1 and t_room1_setpoint parameters I usually stay on the safe side, mimicking main unit fron panel capabilities, which means I personally use only integer values and can't help you.

For everything you think you can improve, I encourage you to submit a pull request.