spanni26 / pyhpsu

Python Script to read and send commands to a Rotex HPSU

Using pyHPSU may cause damage to the heating system. The use of pyHPSU is at your own risk. The creator can not be held responsible for damage.

You may risk a loss of warranty and support from the manufacturer!!!!

This software is not supported by the manufacturer!!!!

Welcome to pyHPSU

pyHPSU is a set of python scripts and other files to read and modify the values of the Rotex® HPSU (possibly) also identical heating pumps from daikin®).

It is based on the idea and the work of Vanni Brutto alias Zanac

It is expandable via plugins to send data to other systems and databases. At the momeent, Emoncms, fhem, homematic, influxdb, mqtt, mysql and openhab are supported.

It works with SocketCan OR the elm327 based serial-can interfaces.
The advantage of SocketCan: it can handle multiple instances or programs talking over the same can interface or you can query multiple values with one command. Message queuing is done by the kernel. For serial can interfaces (like the Elm327) you need a server which handles the messages. To do this, pyHPSUd.py is there. It handles multiple pyHPSU.py session via rabbitMQ.

Hardware setup

1. Via Elm327 interface

• Most cheap china replicas will not work because the "AT PP" command is not implemented. A purchase recommendation is as follows: https://www.totalcardiagnostics.com/elm327 or ahermann86 is using https://www.amazon.de/dp/B06XJ6GQZX/ref=cm_sw_em_r_mt_dp_U_OLP.CbG0Z7YKR
• It is recommended to order a matching obd2 socket (16pol) to connect the can adapter
• Connect the CAN-High cable pin 6, the CAN-Low cable pin 14 and CAN signal ground pin 5 to the hpsu mainboards "J13" connector. (Power on the CAN-Side is not needed)
• look at your systems "dmesg" while connecting to get the device name

2. SocketCan

• connect the Pins from the HPSU mainboards "J13" connector to the pins of your can interface. Needed are canH, canL and ground.
• for debian (and other systems) and the following to /etc/network/interfaces:

  auto can0  
  iface can0 inet manual  
    pre-up /sbin/ip link set $IFACE type can bitrate 20000 triple-sampling on  
    up /sbin/ifconfig $IFACE up  
    down /sbin/ifconfig $IFACE down

Software setup

pyHPSU only runs on unix/linux based systems.

1. To run pyHPSU you need python3 and these python packages:

• python-can==3.3.4
• serial
• pika
• requests
• mysql.connector (used by the db plugin)
• urllib3 (used by the homematic plugin)
• paho-mqtt (used by the mqtt plugin)
• influxdb (used by the influxdb plugn)

2. git clone https://github.com/Spanni26/pyHPSU
3. cd pyHPSU
4. chmod +x install.sh
5. sh install.sh

Using pyHPSU

PyHPSU defaults

• can-device: SocketCan (Driver canpi, for elm327 specify the driver with -d canelm327 and the line with e.g. -p /dev/ttyUSB )
• OutputFormat: JSON (other formats or output devices can be specified with "-o", the usage via "pyHPSU.py -?")

To get a list of all available commands call:
root@rotex:# pyHPSU.py -h

To get a bit more information about a single command:
root@rotex:# pyHPSU.py -h -c <command>
e.g. root@rotex:# pyHPSU.py -h -c t_hs

To query a value (e.g. t_hs): root@rotex:# pyHPSU.py -c t_hs

The default setting is the output to the console in json format, so the output will look like this: [{'name': 't_hs', 'resp': '32.00', 'timestamp': 1544534667.414178}]

Output options ("-o <output>")

CSV

Output is send to console in CSV format (comma separated value)

DB

If a database should be used simply create a mysql DB with collation "utf8_bin", edit the pyhpsu.conf and select "DB" as output type Configure it in /etc/pyHPSU/pyhpsu.conf (look at the code of /usr/lib/python3/dist-packages/HPSU/plugins/db.py to find a template).

EMONCMS

Send the data to an emoncms instance (locally or the web version) Configure it in /etc/pyHPSU/pyhpsu.conf (look at the code of /usr/lib/python3/dist-packages/HPSU/plugins/emoncms.py to find a template).

FHEM

Send the data to a fhem instance. Atm only pushing the values via telnet to port 7072 is supported. Configure it in /etc/pyHPSU/pyhpsu.conf (look at the code of /usr/lib/python3/dist-packages/HPSU/plugins/fhem.py to find a template).

HOMEMATIC

Send the data to homematic. Therefore the xmlapi has to be installed on the ccu, a system variable has to be configured and the ise_id of this variable must be configured in the pyHPSU.conf (look ath the code of /usr/lib/python3/dist-packages/HPSU/plugins/fhem.py to find a template).

INFLUXDB

Send the data to the InfluxDB Time Series database. Configure it in /etc/pyHPSU/pyhpsu.conf (look at the code of /usr/lib/python3/dist-packages/HPSU/plugins/influxdb.py to find a template).

MQTT

Send the data to an MQTT broker. Configure it in /etc/pyHPSU/pyhpsu.conf (look at the code of /usr/lib/python3/dist-packages/HPSU/plugins/mqtt.py to find a template).

OPENHAB

Send the data to openHAB. Create an item for every command you want to use. You have to use a Prefix like Rotex_ for all pyHPSU related item names. So pyHPSU will push every value to a item named [Prefix][command]. For example, if you want to send commands mode and t_dhw1 to openHAB, create those items in you openHAB item config.

Number Rotex_mode      "Modus [MAP(heatpump_mode.map):%s]"
Number Rotex_t_dhw1    "Temperatur im Warmwasserspeicher [%.1f °C]"

For commands like mode, which a number represents a state, you can use openHABs mapping feature to map state numbers to a textual description.

Point pyHPSU to your openHAB system in /etc/pyHPSU/pyhpsu.conf file. Also use Auto Mode and configure your commands in [JOBS] section.

[OPENHAB]
HOST = hostname_or_ip
PORT = 8080
ITEMPREFIX = Rotex_

[JOBS]
mode = 30
t_dhw1 = 60

Modes

pyHPSU.py can be run un different modes.

1. Standalone You can run the pyHPSU.py in standalone mode forom the command line.
   e.g. query the value of t_hs, output in CSV format, using an elm327 interface on port /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_-if00-port0
   root@rotex:# pyHPSU.py -c t_hs -d elm327 -p /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_-if00-port0 -o CSV
   e.g. ask the heating pump for an pending error, output in JSON format, using an SocketCan interface
   root@rotex:# pyHPSU.py -c error -o JSON -d canpi
   or simply (cause JSON and canpi are the defaults):
   root@rotex:# pyHPSU.py -c error

2. Auto Mode The pyHPSU.py can be run in "auto mode". You can define values which should be querried in different periods. This is done at /etc/pyHPSU/pyhpsu.conf.
   At the "jobs" section add the value and the period (as shown by the examples) and addopt the section "PYHPSU" to your needs. Then, run the pyHPSU.py with the parameter "-a"
   e.g.
   root@rotex:# pyHPSU.py -a

3. With Message Broker (only needed with serial intrerfaces like Elm327)
   A serial line can only be used by one process at a time. So, if you query more then one value at a time or you run multiple instances of pyHPSU.py you can run in errors.
   In this mode, every query from pyHPSU.py is sent to the pyHPSUD.py. This daemon deals with the message broker "rabbitmq" which sends one query at a time and sorts the answers to the correct sending process.
   For that, install the message broker "rabbitmq". You also have to configure the config file /etc/pyHPSU/pyhpsu.conf at section "PYHPSUD".
   Here, specify the driver, language and serial port to use.
   The pyHPSUD.py is started via systemd:
   root@rotex:# systemctl enable hpsud.service
   root@rotex:# systemctl start hpsud.service

Now, you can query multiple values or run multiple pyHPSU.py processes. Simply set as driver HPSUD ("CANTCP") via commandline or the config file (PYHPSU section) i.e. root@rotex:# pyHPSU.py -d HPSUD -c t_dhw_setpoint1

pyhpsu's Issues

pyHPSU on Rocon G1 (BeagleBone Black)?

Hi all!

Great work here!
I own a Rocon G1 and wonder if I can run the pyHPSU on its BeagleBone Black (incl. CAN interface) instead of using a second device?

update commands_hpsu.json

would you please update again the "commands_hpsu.json" with some not yet existing commands?
I updated my own local one with e.g. "comp_aktiv" and "pump_aktiv" from FHEM project and it works fine.

For me the current status (on/off) of the compressor and the pump is a very useful information and I think it would be a benefit for all others.

Thanks

query

Hi,

I'm using https://github.com/zanac/pyHPSU with latest versions of june 2018 and rote HPSU 508 , and I have detected some issue, not working daemon (as workaround using a script + sleep) and also receiving some errors like

2019-04-14 07:52:26,515 - ERROR - RECV:bytearray(b'b\x10\xfa\n\x0c\x00/')
2019-04-14 07:52:26,516 - ERROR - msg not sync, timeout
2019-04-14 07:52:28,520 - ERROR - SEND:[49, 0, 3, 0, 0, 0, 0]
2019-04-14 07:52:28,521 - ERROR - RECV:bytearray(b'2\x10\x0e\x01\x87\x00\x00')
2019-04-14 07:52:28,522 - ERROR - SEND:[49, 0, 3, 0, 0, 0, 0]
2019-04-14 07:52:28,522 - ERROR - RECV:bytearray(b' \nR\x01\x00\x00\x00')
2019-04-14 07:52:28,524 - ERROR - SEND:[49, 0, 3, 0, 0, 0, 0]
2019-04-14 07:52:28,524 - ERROR - RECV:bytearray(b' \nV\x00\x00\x00\x00')
2019-04-14 07:52:28,525 - ERROR - SEND:[49, 0, 3, 0, 0, 0, 0]
2019-04-14 07:52:28,526 - ERROR - RECV:bytearray(b' \nW\x00\x00\x00\x00')
2019-04-14 07:52:28,527 - ERROR - SEND:[49, 0, 3, 0, 0, 0, 0]

My question is related with your version, is the same than zanac. can I use without compatibility issues? what are the differences?

Thanks

ELM not working

Hi, can anyone help me get started?

I bought the ELM that is linked in the readme,
"bbfly Forscan Elm327 ELMconfig USB VINT-TT55502 mit MS-CAN für Ford OBD2 Diagnose"
but cannot get it to work (actually I tried with two of these, to make sure it is not broken - bought from different vendors, but otherwise the same ). Both show the same problems. Also, my heat pump is Rotex HPSU compact ultra. I know the folks at FHEM use the same adapter and it works for them. My goal is to run pyHPSU in a docker and push info (both ways) via MQTT to homeassistant.

I usually get (but not always) when I run for the first time after connecting:
pyHPSU.py -d ELM327 -p /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -v 2 -c flow_rate
error - Error sending AT PP 2F ON (rc:AT PP 2F ONOK)

and when I run it a second time:
pyHPSU.py -d ELM327 -p /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -v 2 -c flow_rate
warning - sending cmd 31 00 FA 01 DA 00 00 (rc:NO DATA)
warning - retry 1 command flow_rate
(also when trying other commands)

I have a Raspberry Pi 4 B. Is the ELM working for anyone in this constellation? What ELM are you using?
Or do I need to get a PICAN hat? If so, does the PICAN 2 work on the Raspi 4?

Thanks for any help.

P.S. I connected to Rotex first from the female OBD 16 pin connector with 2m wire. Then, because I was unsure if wires are twisted pairs in that cable, I now use an ethernet cable with a twisted pair. Either way same result. Also, I run pyHPSU in a docker, but given that the ELM reacts I think that works fine. In the meantime, I will re-build that docker to be double sure that I am running the latest version but I built it just a couple of weeks ago.

Explanations for values of mode and mode_01

Hi

is there anywhere an explanation of the values of mode and mode_01?
The xls file with the list pof values is not helpful :-)

hyst_hp listed twice in commands_hpsu_xx.csv

hyst_hp is listed twice in commands files - with different description. I suppose this means two seperate commands.

other options not considered when -a is present

Hi all.
In automatic mode configuration file has priority over command line options

If my pyhpsu.conf has

[PYHPSU]
OUTPUT_TYPE = JSON

and I specify as command line options -a -o mqtt, result is that -a works but output is forced in JSON format and I consider this wrong because if I wanted JSON output I would have not set option -o mqtt

As far as I can tell this can easily be implemented adding a condition when reading the configuration file checking if options are already present, for instance output_type option can be managed in row 172 of pyHPSU.py

172:        if output_type=="" and config.has_option('PYHPSU','OUTPUT_TYPE'):
173:            output_type=config['PYHPSU']['OUTPUT_TYPE']

that in diff world is

172c172
<         if config.has_option('PYHPSU','OUTPUT_TYPE'):
---
>         if output_type=="" and config.has_option('PYHPSU','OUTPUT_TYPE'):

Same applies to other options, at least driver, port and language.

command for "error" seems to be wrong, no values pushed

I tried to get the values for "error", which is defined as value but without any value mapping. Today morning I had an error displayed at the unit itself which was not pushed by pyHPSU (the MQTT output switched from "0" to "")

"error" : { 
	"name" : "error", 
	"command" : "31 00 FA 13 88 00 00", 
	"id" : "190", 
	"divisor" : "1", 
	"writable" : "false", 
	"unit" : "",
	"type" : "value"

If I get the code right this leads to empty responses here

Does anyone know how the values for "error" look like so at least a definition of value_code would be possible? I saw that FHEM uses longint as type, not sure if that works.

Even better would be a code correction to just bypass the response in case no value_code is defined.

Any feedback is appreciated.

get value for state of backup heater

Hi,

I am using pyHPSU for quite a long time, everything is working fine.
But I found that it does not report when the backup heater is running. Based on the docs it should be the ehs value. But its reporting 0, even when the backup heater is active. And the value for qboh is increasing.

Is someone getting data for ehs?
Regarding to #24, maybe 31 00 FA C0 F9 is the wrong CAN command?

python-can==4.0.0 not working

Hi, for me the latest python-can 4.0.0 is not working. I am getting:

ERROR - Error opening bus can0 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/HPSU/canpi.py", line 23, in __init__ self.bus = can.interface.Bus(channel='can0', bustype='socketcan_native') File "/usr/lib/python3.9/site-packages/can/interface.py", line 101, in __new__ kwargs = load_config(config=kwargs, context=context) File "/usr/lib/python3.9/site-packages/can/util.py", line 192, in load_config bus_config = _create_bus_config(config) File "/usr/lib/python3.9/site-packages/can/util.py", line 211, in _create_bus_config raise CanInterfaceNotImplementedError( can.exceptions.CanInterfaceNotImplementedError: Unknown interface type "socketcan_native"

It does work with the version before: python-can-3.3.4

Anyone else experiencing this? It would be great to have a requirements file with the supported versions.

Running pyHPSU/support for pyHPSU

Hi,

I'm owner of a HPSU 508 and would like to use pyHPSU to visualize the different parameters in Edomi, unfortunately I have different problems:

pyHPSU is running as a Docker on my Timberwolf Server, the Elm327 interface is connected.
When trying to set the driver:

"pyHPSU.py -d ELM327 -p var/husky/devices/FTDI_FT232R_USB_UART_A52VL4UF"

I get back a lot of errors and warnings like:

"warning - sending cmd 31 00 FA C1 00 (rc:CAN ERROR)
warning - retry 1 command t_r1
warning - sending cmd 31 00 FA C1 00 (rc:CAN ERROR)
warning - retry 2 command t_r1
warning - sending cmd 31 00 FA C1 00 (rc:CAN ERROR)
warning - retry 3 command t_r1
warning - sending cmd 31 00 FA C1 00 (rc:CAN ERROR)
warning - retry 4 command t_r1
error - command t_r1 failed"

Can anyone help me ?

Thanks a lot

one_hot_water not implemented?

Hi! Thanks for your great work!

I tried to srite a value to one_hot_water but received the answer
root> pyHPSU.py -c one_hot_water:1 -d PYCAN -p /dev/ttyS0
error - type "value" not implemented since yet

Is it planned to be implemented?

Cheers
Christian

log improvement

Hallo.
My suggestion is to improve the logging.
Current problems are:

• Output log level cannot be controller via options, it is hardcoded
• "printd()" method mixes log, output message and has also dependency on it parent implementation, because of the "self.driver != "HPSUD"" check
• Developers are discouraged to add log because of how "printd()" is implemented, the risk of writing to stdout along command output is real; current code has no log at DEBUG or INFO level probably because of this
• Log is substantially absent
• Implemented log levels are not the usual ones, e.g. DEBUG level is missing
• Logging methods specify level using strings and this is prone to error and inhibits code auto-completion

I prepared a pull request solving all of this, it is really "big" because it removes printd() in favor of standard logging methods and this involves almost all of the python files.
I will submit the pull request so we can discuss on the technical decisions, if you are interested on.

value type

I am looking at value type implementation in CanPI.py.
At line 81-83 the value taken from commands_hpsu.json is fitted into a single byte (two hex nibbles)

            if cmd["type"] == "value":
                setValue = int(setValue)
                command = command+" 00 %02X" % (setValue)

this does not work with values bigger than 255.
For instance the command

$ pyHPSU -c anti_leg_day:friday

compose the message

32 00 FA 01 01 00 500

breking things, because friday equals 1280 (0x0500).

I tried to solve this with this code

            if cmd["type"] == "value":
                setValue = int(setValue)
                command = command+" %02X %02X" % (setValue >> 8, setValue & 0xff)

but further investigation is needed because I am not exactly aware of how different "value_code" maps to different message bytes.

I also tried merging the "value_code" fix from Spanni26:master in my current HEAD (segaura:logrevision).
This is for setting values and I also tried to implement the possible corresponding code for reading values.
What I experiment is that the value_code dictionaries are needed in the original order in the read operation.

I am talking of rows around line 500 in pyHPSU.py

if not setValue:
    response = n_hpsu.parseCommand(cmd=c, response=rc, verbose=verbose)
    resp = n_hpsu.umConversion(cmd=c, response=response, verbose=verbose)

    if c["value_code"] is None:
        arrResponse.append({"name":c["name"], "resp":resp, "timestamp":response["timestamp"]})
    else:
        arrResponse.append({"name":c["name"], "resp":resp, "timestamp":response["timestamp"],"desc":dict(map(reversed, c["value_code"].items()))[resp]})

this adds an additional desc field to output JSON for the value description, when applicable, like this

$ pyHPSU.py -c anti_leg_day 
[{'name': 'anti_leg_day', 'resp': '0', 'timestamp': 1616795897.625081, 'desc': 'off'}]

and with the inverted value_code dictionary you introduced

c["value_code"]
{'everyday': '2048', 'friday': '1280', 'monday': '256', 'off': '0', 'saturday': '1536', 'sunday': '1792', 'thursday': '1024', 'tuesday': '512', 'wednesday': '768'}

it is still necessary to have it reversed, like this

dict(map(reversed, c["value_code"].items()))
{'0': 'off', '1024': 'thursday', '1280': 'friday', '1536': 'saturday', '1792': 'sunday', '2048': 'everyday', '256': 'monday', '512': 'tuesday', '768': 'wednesday'}

given this, I think we can consider other things (e.g. readability? something else?) to decide which order is better, because this "set and read" use case works with any order and needs both orders ...so far I don't mind, both orders are equally fine for me.

I can add everything to my current pull request #44, but the new "desc" field in the output can be harmful for someone, maybe breaking automations: for this sake I only have included it in JSON output cases (e.g. the CLI output and the MQTT output when timestamp is added) and also wait for some discussion about this.

mqtt input

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)

OUTPUT_TYPE is never read from config

pyHPSU/pyHPSU.py

Line 172 in 3e05656

if output_type=="" and config.has_option('PYHPSU','OUTPUT_TYPE'):

Code line 30 always initializes OUTPUT_TYPE to JSON:

output_type = "JSON"

This way

        if output_type=="" and config.has_option('PYHPSU','OUTPUT_TYPE'):
            output_type=config['PYHPSU']['OUTPUT_TYPE']

if always evaluates to false, and output_type is never taken from config.

re-connect at every mqtt command

Hi,

thanks for the great work! I noticed that my var log message file gets spammed with MQTT disconnect and new connect messages. The reason is in this function:

pyHPSU/HPSU/plugins/mqtt.py

Line 91 in e7a2b46

def pushValues(self, vars=None):

which connects for every single command, and I am querying the HPSU every few seconds with multiple commands. Shouldn't the connection be established one time in the beginning and then remains active? That is how my other devices behave.

auto mode, not all values are published with same timer

Hello,

I am using auto mode and configured many values with the same query time (60s). I found that most of the time only the last value is published.
Then I changed timers so no command is using the same time as all others. Now all values are published.
So it seems that only the last timer command is running. My Python skills are limited, but the thread part in HPSU.py looks good to me. But I dont know how the threads lib is working.

t_vbh = 60
tvbh2 = 60
t_r1 = 60
t_return = 60
tliq2 = 60
t_hs = 60

=> sends only t_hs (most of the time)

t_vbh = 58
tvbh2 = 59
t_r1 = 60
t_return = 61
tliq2 = 62
t_hs = 63

=> sends all values

My system runs on a Pi2 with PyCAN.

invalid mode: 'rU'

Fresh install with Python 3.11.2:

pi@pi-HPSU:~/pyHPSU $ pyHPSU.py -d ELM327 -h Traceback (most recent call last): File "/usr/bin/pyHPSU.py", line 338, in <module> main(sys.argv[1:]) File "/usr/bin/pyHPSU.py", line 223, in main n_hpsu = HPSU(driver=driver, logger=logger, port=port, cmd=cmd, lg_code=lg_code) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/HPSU/HPSU.py", line 53, in __init__ with open(commands_hpsu, 'rU',encoding='utf-8') as csvfile: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ValueError: invalid mode: 'rU'

Looks like mode 'U' is deprecated in 3.11. There are quite a few more errors when running 3.11

Reverting to 3.10 solved the problem.

MQTT sending commands not working

Hello guys.
When i try to send a command trough mqtt i can't get it to work;

service: mqtt.publish
data:
topic: ALTHERMA/command/mode_01
payload: "17"

The pyHPSU is running like this;
pyHPSU.py -a -o MQTT

If i do like that it changes it
pyHPSU.py -c mode_01:17

command list cleanup

Hallo.
While working on creating a DBC database with the HPSU commands, I've found some maybe quirks in commands_hpsu.json.

Easiest to fix are these on "screed section":

• these two commands are the same
  t_screed_day5 61 00 FA 0B BD 00 00
t_screed_day7 61 00 FA 0B BD 00 00
• and same for these two
  t_screed_day21 61 00 FA 0B CD 00 00
t_screed_day22 61 00 FA 0B CD 00 00

but looking at the progression of the values and also observing that 0x0BBD = 3005 and 0x0BCD = 3021 the correct ones should be

t_screed_day7 61 00 FA 0B BE 00 00
t_screed_day22 61 00 FA 0B CE 00 00

Second group are these that are almost the same

t_flow_cooling 31 00 FA 03 DD 00 00
t_flow_cool 61 00 FA 03 DD 00 00

the first receives a 180#32 10 FA 03 DD 00 BE as answer and the second receives a 300#32 10 FA 03 DD 00 BE: is it correct to have them both listed?
I am considering of dropping the second one.

Third group is

quiet_mode 31 00 FA 06 96 00 00
aux_fct 31 00 FA 06 96 00 00

these are also listed as the same command, but after some dump and click I think that this is the correct value

aux_fct 31 00 FA 06 71 00 00

Last group is this, all three command are the same

outside_conf 31 00 FA 09 61 00 00
storage_conf 31 00 FA 09 61 00 00
pres_conf 31 00 FA 09 61 00 00

and this is correct, they are the same command, but the problem is with the values because they work on one or two bits each and not on one or two bytes like pyHPSU think.

Naming o the bit for outside_conf, s the bits for storage_conf and p the bit for pres_conf the last two bytes (data section 6th and 7th byte) are like this

0p10100000000sso

so, for instance

6804 = 0110100000000100

corresponds to

• outside_conf off (0)
• storage_conf sensor (4)
• pres_conf on (0x6800 = 26624)

and

2803 = 0010100000000011

corresponds to

• outside_conf on (1)
• storage_conf thermostat (2)
• pres_conf off (0x2800 = 10240)

issuing those three commands correctly requires reading the current value, altering the correct bits and sending it back as new value.
This is possible but I have no evidence that this ic currently managed correctly by pyHPSU.
Obviously these three are "less important" commands to control HPSU via pyHPSU so they will probably remain like they are for a while.
They are rather important for backup/restore feature, though, so they deserve some attention, in my opinion.

I have "fixed" first three group in my current development branch, if no objections emerge I can include that fixes in my next PR.

how to write/change variables?

Hello and many thanks to this (forked) project!

Reading (for example: "pyHPSU.py -h -c mode_01") is running fine at my raspberr with PiCan2.

But how can I change variables? I havn't any examples, comments or else.

MAybe you can explain with the example of changing heating programm (change "mode_01" from "12" [this is Auto 2] to "11" [this is Auto 1].

many thanks

How to set values

How can i set the mode Cooling?:
mode;Mode;Current mode of the heat pump: ---: No heating or cooling demand : Heating : Cooling : Domestic hot water generation : Automatic defrosting function active
=> I want to activate cooling in the summer when its hot

How can i set a value t_hs_set to 50?
=> i would like to use excess solar energy in the winter

My working read command is:
pyHPSU.py -c t_dhw -d elm327 -p /dev/ttyUSB0

value overflow qch - starting again at 0

Hello,

this is not an pyHPSU related issue, just a question to Rotex data.

The value for qch (or qwp a longer time ago) was above 32228 and is starting again at 0. So I suppose an internal numger range was overflowed but I didnt had a value logging active at this time. So I do not know the exact value to add to the current value to get the all time qch value in my system.

Has anybody an data logging active while one of his value get this overflow?

As an IT guy I would expect 32768, but I am not sure, so I am asking here for other experiences.
Thank you

Autostart after reboot

I‘d like to autostart pyHPSU after rebooting my Raspberry Pi. Can anyone help me with a working procedure?

regards Karl

Help needed (can0)

I use pyHPSU on a Pi with Canpi 2.
After the first setup it worked fine. But now I found that it stopped working. Don't know what I've done wrong.
Whenever I try to retrieve CAN data I get the following message now:

With "ifconfig" the can0 does not show up anymore!

With "dmesg" I find the following lines:

Any advice is highly appreciated!

Karl

t_room not working

Hallo.
I saw in issue#18 that a commant t_room has been added to pyHPSU

		"t_room" :{
			"name" : "t_room",
			"command" : "81 00 FA 00 11 00 00",
			"id" : "190",
			"divisor" : "10",
			"writable" : "false",
			"unit" : "deg",
			"type" : "float"
		}

I notice that this is giving me error all the times.
Reading issue#18 comments, my understanding is that the correct command is

31 00 FA 00 11 00 00

I don't have a Rocon U1 so I'm not sure reading this makes sense, anyway with this sequence I get this reading

2021-02-17 22:47:59,609 - DEBUG - CanPI, got:  32 10 FA 00 11 80 00
[{'name': 't_room', 'resp': '-3276.80', 'timestamp': 1613598479.611429}]

which is better than 45 retries and an error.

Is it correct to change 81 to 31?

Output Adapter MQTT

Hi

when using the new (Beta) MQTT Adapter, I get:

pi@can:~/pyHPSU/plugins $ pyHPSU.py -c water_pressure -o mqtt Traceback (most recent call last): File "/usr/bin/pyHPSU.py", line 335, in <module> main(sys.argv[1:]) File "/usr/bin/pyHPSU.py", line 275, in main read_can(driver, logger, port, cmd, lg_code,verbose,output_type) File "/usr/bin/pyHPSU.py", line 331, in read_can hpsu_plugin = module.export(hpsu=n_hpsu, logger=logger, config_file=conf_file) File "/usr/lib/python3/dist-packages/HPSU/plugins/mqtt.py", line 77, in __init__ if self.username: AttributeError: 'export' object has no attribute 'username' pi@can:~/pyHPSU/plugins $

A lot of wrong commands in commands_hpsu.json

Hi,

i think there are a lot of wrong commands in commands_hpsu.json and the project is using the constructor in the wrong way.

now:

		"t_ext" : { 
			"name" : "t_ext", 
			"command" : "61 00 FA 0A 0C", 
                        "id" : "310", 
                       ...
		},

should be

		"t_ext" : { 
			"name" : "t_ext", 
			"command" : "31 00 FA 0A 0C", 
                        "id" : "190", 
                       ...
		},

another example:

now:

		"t_return" : { 
			"name" : "t_return", 
			"command" : "31 00 16 00 00 00 00",
                        "id" : "190", 
                       ...
		},

should be:

		"t_return" : { 
			"name" : "t_return", 
			"command" : "31 00 FA 00 16",
                        "id" : "190", 
                       ...
		},

the constructor for heat generator 1 is always the same:

"get" : "0x190", "0x31", "0x00", "0xFA" + high byte + low byte
"set" : "0x190", "0x30", "0x00", "0xFA" + high byte + low byte
"answer" : "0x180", "0x32", "0x10", "0xFA" + high byte + low byte + answer

so the commands_hpsu.json should realy look like this (for Sender ID 190):

		"t_ext" : { 
			"name" : "t_ext", 
			"command" : "0A 0C", 
                                      |  |__________> low byte
                                      |_____________> high byte
                        "id" : "190", 
                       ...
		},

the constructor should than make this:
example with "t_ext":

         ┌────────────────────────> Sender ID (190)
         │      ┌─────────────────> get/set Cmd (31 00 FA)
         │      │     ┌───────────> High Byte (OC)
         │      │     │  ┌────────> Low Byte (0A)
         │      │     │  │
        ─┴─ ────┴───  ┴  ┴
"get" : 190 31 00 FA 0A AC

and the awaited answer is:

         ┌────────────────────────> Receiver ID (180)
         │      ┌─────────────────> answer to get/set Cmd (32 10 FA)
         │      │     ┌───────────> high byte (OC)
         │      │     │  ┌────────> low byte (0A)
         │      │     │  │   ┌────> answer (01 0E (hex), 275 (dec) / divisor = 27,5°)
        ─┴─ ────┴───  ┴  ┴ ──┴──
"get" : 180 32 10 FA 0A AC 01 0E

we end up with this:

heat generator 01:
"get" : "0x190", "0x31", "0x00", "0xFA" + high byte + low byte              // "190 31 00 FA"
"set" : "0x190", "0x30", "0x00", "0xFA" + high byte + low byte              // "190 30 00 FA"
"answer" : "0x180", "0x32", "0x10", "0xFA" + high byte + low byte + answer  // "180 32 10 FA"

heating Circuit 01
"get": "0x190", "0x61", "0x00", "0xFA" + high byte + low byte               // "190 61 00 FA"
"set": "0x190", "0x60", "0x00", "0xFA" + high byte + low byte               // "190 60 00 FA"
"answer": "0x300", "0x32", "0x10", "0xFA" + high byte + low byte + answer   // "300 32 10 FA"

heating Circuit Module 01
"get": "0x190", "0xC1", "0x00", "0xFA" + high byte + low byte               // "190 C1 00 FA"
"set": "0x190", "0xC0", "0x00", "0xFA" + high byte + low byte               // "190 C0 00 FA"
"answer": "0x600", "0x32", "0x10", "0xFA" + high byte + low byte + answer   // "600 32 10 FA"

Caution:
under some circumstances rapidly changing from Sender ID 190, heat generator, get 31 to Sender ID 190, heating Circuit, get 61 could turn the rotex into maintenance mode. After that i realized that Sender ID 190 seems to be the display / RoCon at the heat pump itself. The external RoCon that Rotex / Daikin sells uses Sender ID 69D.

Nearly all commands having a 31 equivalent and using 61 is not necessary.
e.g. "t_ext"

MQTT sending commands stops working after mosquitto restart

After my server running mosquitto reboots for software updates the raspberry running pyHPSU isn't able to send commands (for instance rotex/command/heat_slope) anymore. Reading values keeps working. After restarting the hpsu service sending commands works again. Nothing is mentioned in the logfile (LOG_LEVEL_STRING = WARNING).

Originally posted by @svde in #50 (comment)

pyHPSU and openHAB 3.0

Hi all.

I'm just migrating to OH 3.0 and found the following issue: When trying to send values to openHAB the log files fills with errors like
2021-02-06 21:16:38.810 [ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body reader has been found for class java.lang.String, ContentType: application/octet-stream

Appearently this is caused by a missing header. Changing openhab.py like this seems to resolve that issue:

        url = "http://%s:%s/rest/items/%s%s/state" % (self.openhabhost, str(self.openhabport), self.openhabitemprefix, item)
        try:
            headers = {"Content-Type": "text/plain"}
            r = requests.put(url, data=str(value), headers=headers)
        except requests.exceptions.RequestException as e:
            rc = "ko"
            self.hpsu.printd("exception", "Error " + str(e.code) + ": " + str(e.reason))

A quick test didn't show any problems with openHAB 2.5, so this might work for both versions.

Anyone who can verify this?

Regards
Martin

Getting lots of "msg not sync" messages

Hi

running pyHPSU in background, I get a low of the following error messages:

pi@can:~ $ pyHPSU.py -a &
[1] 651
pi@can:~ $ error - SEND:[49, 0, 250, 9, 32, 0, 0]
error - RECV:bytearray(b' \n\x0c\x00\xf0\x00\x00')
warning - msg not sync, retry: 1
error - SEND:[49, 0, 250, 193, 1]
error - RECV:bytearray(b' \n\x0c\x00\xf0\x00\x00')
warning - msg not sync, retry: 1
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'1\x00\xfa\xc0\xf6\x00\x00')
warning - msg not sync, retry: 1
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'1\x00\xfa\xc0\xf7\x00\x00')
warning - msg not sync, retry: 2
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'1\x00\xfa\xc0\xf8\x00\x00')
warning - msg not sync, retry: 3
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'1\x00\xfa\xc0\xf9\x00\x00')
warning - msg not sync, retry: 4
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'1\x00\xfa\xc0\xfa\x00\x00')
warning - msg not sync, retry: 5
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'1\x00\xfa\xc0\xfb\x00\x00')
warning - msg not sync, retry: 6
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'"\n\xfa\xc0\xf6\x00\x00')
warning - msg not sync, retry: 7
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'"\n\xfa\xc0\xf7\x00\x00')
warning - msg not sync, retry: 8
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'"\n\xfa\xc0\xf8\x00\x00')
warning - msg not sync, retry: 9
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'"\n\xfa\xc0\xf9\x00\x00')
warning - msg not sync, retry: 10
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'"\n\xfa\xc0\xfa\x00\x00')
warning - msg not sync, retry: 11
error - SEND:[49, 0, 250, 6, 108, 0, 0]
error - RECV:bytearray(b'"\n\xfa\xc0\xfb\x00d')
warning - msg not sync, retry: 12
error - SEND:[49, 0, 250, 192, 255]
error - RECV:bytearray(b'1\x00\xfa\xc0\xf6\x00\x00')
warning - msg not sync, retry: 1
error - SEND:[49, 0, 250, 192, 249]
error - RECV:bytearray(b'1\x00\xfa\xc0\xf7\x00\x00')
warning - msg not sync, retry: 1
error - SEND:[49, 0, 250, 192, 249]

MQTT

Have the following Error:
(paho-mqtt in /usr/local/lib/python3.5/dist-packages (1.5.0))

python3 /usr/bin/pyHPSU.py -c t_hs -o mqtt
Traceback (most recent call last):
  File "/usr/bin/pyHPSU.py", line 335, in <module>
    main(sys.argv[1:])
  File "/usr/bin/pyHPSU.py", line 275, in main
    read_can(driver, logger, port, cmd, lg_code,verbose,output_type)
  File "/usr/bin/pyHPSU.py", line 332, in read_can
    hpsu_plugin.pushValues(vars=arrResponse)
  File "/usr/lib/python3/dist-packages/HPSU/plugins/mqtt.py", line 94, in pushValues
    ret=self.client.publish(self.prefix + "/" + r['name'],payload=r['resp'], qos=self.qos)
  File "/usr/local/lib/python3.5/dist-packages/paho/mqtt/client.py", line 1247, in publish
    if qos < 0 or qos > 2:
TypeError: unorderable types: str() < int()

Is this a known issue?