Open sebbacon opened 5 years ago
These instructions worked, although I used minicom for flashing from Linux.
This puts culfw on the cube. This implements a protocol of its own, so you need something to speak that protocol. The flavours are CUL (via serial port / USB) and CUN (via ethernet).
Homegear claims to implement both flavours. The walkthrough listed above covers homegear as well as the flashing parts. pimatic appears to do at least the serial flavour.
I had to edit /etc/homegear/rcpservers.conf
so that all the lines started interface
were interface = 0.0.0.0
I used the homegear commandline interface for pairing:
$ sudo homegear -r
Connected to Homegear (version 0.8.0-3064).
Please type >>help<< to list all available commands.
> ls
ID │ Name
──────┼───────────────────────────────
4 │ MAX!
254 │ Miscellaneous
──────┴───────────────────────────────
> families select 4
For a list of available family commands type >>help<<.
Family 4> pairing on
Pairing mode enabled.
I had to factory reset the TRVs (remove batteries; reinsert while holding down all the buttons), as I was seeing a log message that they were already paired with something else (the old Cube).
When I attempt a pair, this homegear debug log shows some activity and the TRV stops its paring countdown, which all suggests something was successful; but ls
shows no connected peers.
08/30/20 18:12:25.511 MAX packet received (Max-CUNX, RSSI: 0x4E): 170004001A75E7FD8D58001101A14F455131303339353735
08/30/20 18:12:25.511 Module MAX: Creating SAVEPOINT PacketQueue1734119_0
08/30/20 18:12:25.612 Module MAX: CUNX "Max-CUNX": Info: Sending (Max-CUNX, WOR: yes): 0B060001FD8D581A75E70000
08/30/20 18:12:28.551 Module MAX: Sending from resend thread 0 of queue 0.
08/30/20 18:12:28.652 Module MAX: CUNX "Max-CUNX": Info: Sending (Max-CUNX, WOR: yes): 0B060001FD8D581A75E70000
08/30/20 18:12:31.552 Module MAX: Sending from resend thread 1 of queue 0.
08/30/20 18:12:31.652 Module MAX: CUNX "Max-CUNX": Info: Sending (Max-CUNX, WOR: yes): 0B060001FD8D581A75E70000
08/30/20 18:12:35.619 Module MAX: Debug: Deleting queue 0 for peer with address 0x1A75E7
08/30/20 18:12:35.620 Module MAX: Releasing SAVEPOINT PacketQueue1734119_0
A further to think it was successful is that if I change the MAX! address of homegear (with the centralAddress
config setting in /etc/homegear/families/max.conf
) and then try to repair, I get
08/30/20 18:21:04.743 MAX packet received (Max-CUNX, RSSI: 0x43): 170004001A75E7FD8D58001101A14F455131303339353735
08/30/20 18:21:04.744 Module MAX: Error: Pairing packet rejected, because this peer is already paired to another central.
If I factory reset the TRV and then pair again, I get exactly the same apparent success.
Using CUL module (serials over USB) I get a successful pairing for one of my TRVs. The logs look like this
08/31/20 19:39:00.822 MAX packet received (My-MAX-CUL, RSSI: 0x38): 170004001A75E7000000001101A14F455131303339353735
08/31/20 19:39:00.823 Module MAX: Creating SAVEPOINT PacketQueue1734119_0
08/31/20 19:39:01.016 Module MAX: CUL "My-MAX-CUL": Info: Sending (My-MAX-CUL, WOR: yes): 0B000001FD07BD1A75E70000
08/31/20 19:39:02.075 MAX packet received (My-MAX-CUL, RSSI: 0x36): 0E0002021A75E7FD07BD0001190028
08/31/20 19:39:02.075 Module MAX: Popping from MAX! queue: 0
08/31/20 19:39:02.075 Module MAX: Message now at front: Message type: 0x2 Message subtype: 0xFFFFFFFF
08/31/20 19:39:02.175 Not loading XML RPC device translation /etc/homegear/devices/4/l10n/en-US/BC-RT-TRX-CyN.xml: Translation not found.
08/31/20 19:39:02.176 Not loading XML RPC device translation /etc/homegear/devices/4/l10n/en-US/BC-RT-TRX-CyN.xml: Translation not found.
08/31/20 19:39:02.177 Module MAX: Added peer 0x1A75E7.
08/31/20 19:39:02.177 Module MAX: Popping from MAX! queue: 0
08/31/20 19:39:02.177 Module MAX: Packet now at front of queue: 0F010003FD07BD1A75E700141F52A727
08/31/20 19:39:02.177 Module MAX: CUL "My-MAX-CUL": Info: Sending (My-MAX-CUL, WOR: no): 0F010003FD07BD1A75E700141F52A727
08/31/20 19:39:02.246 MAX packet received (My-MAX-CUL, RSSI: 0x35): 0E0102021A75E7FD07BD0001190028
08/31/20 19:39:02.247 Module MAX: Popping from MAX! queue: 0
08/31/20 19:39:02.247 Module MAX: Message now at front: Message type: 0x2 Message subtype: 0xFFFFFFFF
08/31/20 19:39:02.247 Module MAX: Popping from MAX! queue: 0
08/31/20 19:39:02.247 Module MAX: Info: Queue 0 is empty and there are no pending queues.
08/31/20 19:39:02.326 Module MAX: Debug: Deleting queue 0 for peer with address 0x1A75E7
08/31/20 19:39:02.516 Module MAX: Releasing SAVEPOINT PacketQueue1734119_0
Compare with a TRV that won't pair:
08/31/20 19:56:02.576 MAX packet received (My-MAX-CUL, RSSI: 0x48): 170004001A77CD000000001101A14F455131303430363736
08/31/20 19:56:07.576 MAX packet received (My-MAX-CUL, RSSI: 0x4A): 170004001A77CD000000001101A14F455131303430363736
08/31/20 19:56:12.576 MAX packet received (My-MAX-CUL, RSSI: 0x43): 170004001A77CD000000001101A14F455131303430363736
08/31/20 19:56:17.576 MAX packet received (My-MAX-CUL, RSSI: 0x43): 170004001A77CD000000001101A14F455131303430363736
08/31/20 19:56:22.134 IPC Server: Info: Client number 1 is calling RPC method: lifetick Parameters:
08/31/20 19:56:22.134 IPC Server: Response:
(Boolean) 1
08/31/20 19:56:22.576 MAX packet received (My-MAX-CUL, RSSI: 0x44): 170004001A77CD000000001101A14F455131303430363736
08/31/20 19:56:27.576 MAX packet received (My-MAX-CUL, RSSI: 0x44): 170004001A77CD000000001101A14F455131303430363736
Seems like I can get a TRV to pair if I stop and restart the homegear
client.
Next steps:
Put Arm 32-bit HF version of Zulu Java (must be version 8) in /usr/lib/jvm/zulu/
; updated /usr/lib/systemd/system/openhab2.service
with this so the PATH is set correctly:
ExecStart=/bin/bash -c 'PATH=/usr/lib/jvm/zulu/bin/:$PATH exec '/usr/share/openhab2/runtime/bin/karaf ${OPENHAB_STARTMODE}
Next steps:
I've found the VS Code OpenHAB extension quite useful for managing the config files. It talks to the RPC server to get items, things etc
Struggling with setting temp.
This works. I think it shows front living room thermostat
rc $hg->setValue("OEQ1040676", "SET_TEMPERATURE", "18");
rc print_v($hg->getParamset(1, 1, "VALUES"));
Family 4> ls
ID │ Name │ Address │ Serial Number │ Type │ Type String │ Firmware │ Unreach
─────────┼───────────────────────────┼─────────┼───────────────┼──────┼───────────────────────────┼──────────┼────────
│ │ │ │ │ │ │
1 │ "living room front" │ 1A77CD │ OEQ1040676 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
2 │ "living room back" │ 1A75E7 │ OEQ1039575 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
3 │ "kitchen" │ 150A88 │ MEQ1821372 │ 01A0 │ BC-RT-TRX-CyG-3 │ 1.0 │ No
4 │ "study" │ 1A7592 │ OEQ1039499 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
5 │ wall thermometer │ 1930F0 │ OEQ1447059 │ 03FF │ BC-TC-C-WM-4 │ 1.0 │ No
6 │ guest bedroom │ 1A752F │ OEQ1039384 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
7 │ beth bedroom │ 1A158C │ OEQ1041021 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
8 │ master bedroom │ 1A7602 │ OEQ1040288 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
9 │ samuel bedroom │ 1A75A8 │ OEQ1039491 │ 01A1 │ BC-RT-TRX-CyN │ 1.1 │ No
─────────┴───────────────────────────┴─────────┴───────────────┴──────┴───────────────────────────┴──────────┴────────
Where I'm up to is
> rc $hg->setValue("OEQ1040676:1", "MAX_TEMPERATURE", 15);
PHP Fatal error: Uncaught Homegear\HomegearException: No answer from device. in /var/lib/homegear/scripts/inline.php:7
Stack trace:
#0 /var/lib/homegear/scripts/inline.php(7): Homegear\Homegear->__call('setValue', Array)
#1 {main}
thrown in /var/lib/homegear/scripts/inline.php on line 7>
Somewhat sure this is the correct way of doing it but it's all guesswork, I can't find any useful documentation...
IN fact, this appears to work even though the error message suggests otherwise
469 homegear -e 'rc $hg->setValue("OEQ1040676:1", "MAX_TEMPERATURE", 15);'
470 homegear -e 'rc print_v($hg->getParamset(1, 1, "VALUES"));'
No - it's not working. Clearly the homegear server keeps a database of values it's expecting to see. I think nothing is making it to the TRVs.
Have struggled around with FHEM to see if I get the same issues.
It is easy to read from the devices, but writing to them seems not to work.
I get Send Queue missing ack from MAX_1a75e7 for SetTemperature, removing from queue
when I attempt to set the temperature.
I think, given this doesn't work in any implementation, there's something going on with the firmware. Though that also seems unlikely. Possibly I can try using the CUL commands directly over the serial line... I want the Z messages...
If I run minicom -D /dev/ttyACM0
, and type V
, the firmware is reported as:
V 1.26.04_nocredits a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Changed to this firmware, same problems
V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
OK. Getting into the protocol via a python implementation.
Debugging notes: my cube currently has address 0xfdbe51
and the thermostat next to the dining room table has address 0x1a75e7
When I change the temp on that thermostat using the physical interface, I see the following messages:
DEBUG:maxcul._io:Received new moritz message: Z0F0004601A75E70000000019641700A72D
DEBUG:maxcul._communication:Received message <ThermostatStateMessage length:f counter:0 flag:4 group_id:0 sender_id:1a75e7 receiver_id:0 raw_payload:19641700A7 mode:manual dstsetting:0 langateway:1 is_locked:0 rferror:0 battery_low:0 desired_temperature:11.5 valve_position:64 measured_temperature:16.7> (45)
DEBUG:maxcul._communication:Sending message <AckMessage counter:0 sender_id:fdbe51 receiver_id:1a75e7 group_id:0 flag:4>
thermostat_update {'device_id': 1734119, 'measured_temperature': 16.7, 'desired_temperature': 11.5, 'mode': 'manual', 'battery_low': False}
DEBUG:maxcul._io:Writing command Zs0A000002FDBE511A75E700
Using that library, I can see the Moritz message to set temp to 5.5 on that thermostat is Zs0BB90040FDBE511A75E7004B
; and 17.5 is Zs0BB90040FDBE511A75E70063
when I send that using minicom, I get a response Z0EB902021A75E7FDBE51000119000B2D
, and it worked!
Confirming this is version 1.26.04_nocredits a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
of firmware.
Homegear is a bridge that talks the "eQ-3 Homematic Solution" protocol for which there is an openhab binding.
To install homegear we needed to configure /etc/homegear/families/max.conf
.
To get onto RPi:
ssh seb@raspberrypi
http://raspberry:8080/start/index
Reset openhab: sudo apt -o Dpkg::Options::="--force-confmiss" install --reinstall openhab2
OK now I have it working via homegear:
$ sudo homegear -e 'rc $hg->setValue("OEQ1039575:1", "SET_TEMPERATURE", 10);'
I had to:
centralAddress = 0xFDBE51
in /etc/homegear/familes/max.conf
/dev/ttyACM0
to a+rw
homegear
daemonPer this comment in German it appears there's some kind of group permissions issue relating to the raspian udev settings. It recommends updating /lib/udev/rules.d/50-udev-default.rules
with:
KERNEL=="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="homegear"
a-culfw
here; it describes how to manage it via HomeGear. Another tutorial here.