Open segaura opened 3 years ago
Very cool, with this we will be able to start water heating from remote. Thank you so much!
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
That container part is already done: https://hub.docker.com/r/pdcemulator/pyhpsu/ :-)
Sure, I know, I hope the Dockerfile will reside in this repository, ultimately
Latest commit on my repo includes some stabilization on this feature.
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
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.
Make a PullRequest and I will merge git so everyone can test it. :) Thanks for the contribution
Yes please. I'd like to volunteer to test it.
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'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
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.
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.mdProposed 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
https://github.com/segaura/pyHPSU/commit/8fc6ae2746bca6ef7a7648e8483f9c574dff7516
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: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)