A lot of wrong commands in commands_hpsu.json

[Chrischi-]

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"

[adieball]

do you have a reworked commands file?

[Spanni26]

Its not totally wrong. Vanni wtched the can bus and stripped this commands. So they can't be totally wrong. But they should be fixed, thats right. Perhaps I find some time to test and fix it this weekend. Btw: interessting are the explanations from juerg here: http://juerg5524.ch/data/Telegramm-Aufbau.txt

At the moment the pyHPSU is very simple: Send a command....read a command and fiddle out the values. If we will do it correct: Get the sender ID, the receiver, the wanted value and build the can command....and vice versa. Then, the pyHPSU could be used for all machines using the elster kromschroeder protocoll

[Chrischi-]

I'm not saying everything's wrong. But it's not all right either and should be fixed.

I don't use pyHPSU but develop my own project using ESP8266/32. A small WiFi box which can be stowed under the cover of the Rotex system and which passes the values to emoncms, mqtt etc.. I build and process the commands exactly as I described above. I thought this info would be very useful for pyHPSU users.

[Spanni26]

Do you have more infos about your project?

[Chrischi-]

Do you have more infos about your project?

I've been doing / running this for more than 12 months now and I'm currently thinking about doing this OpenSource or if it will stay ClosedSource.

I use an ELM327 for communication.

[ckohrt]

Hi, from which type of heating system are the commands taken? I have recognized that Rotex/Daikin is changing the hydraulic schema from model to model and from year to year. Could you please document the model numbers and years? Especially Vanni .. I would relly appreciate, because I am confused about the names and values even though they are copied from a Rotex manual. I have the Rotex HPSU Compact 516, 11KW, 2017. Thanks, Christian