Unable to pair MAX TRV

Hi,

I have homegear set up with just the MAX family module. It is connecting using CUNX to a MAX Cube that has been flashed with culfw. When I turn on pairing mode and then set the TRV to pair, I get a few messages in the log files, and the TRV leaves pairing mode, all suggesting that the pairing worked. The logs are

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

However, ls shows no paired devices, which suggests it didn’t work.

If I change the MAX! address of homegear (with the centralAddress config setting in /etc/homegear/families/max.conf ) and then try to pair again, I get a new message: Module MAX: Error: Pairing packet rejected, because this peer is already paired to another central. in the logs. This suggests, again, that the pairing worked.

I don’t know where to go next to debug this. Any pointers appreciated.

Hey, welcome to the forum.

Please do a complete factory reset of the MAX thermomast as described in the instructions.
After that try to pair again.

Cheers,
p

Hi, thanks! I should have mentioned, I already did a factory reset - several times, in fact.

A couple of other odd things: I find I frequently have to restart the homegear service (this is using the Ubuntu debs) in order to reproduce this logging behaviour. Without the restart, a factory restart may or may not result in this logging info. Following a restart, it always does.

Possibly related, I’m also seeing regular Module MAX: CUNX "Max-CUNX": Warning: Connection to client number [N] closed (3): Connection reset by peer, whenever I’m interacting with the Cube (I think).

You can change the debuglevel at runtime via the homegear console:

sudo homegear -r
dl 5

I’ve never used the Cube as CUNX, but you can use it as ordanary CUL via USB as well.
Maybe you can test this way if pairing is possible.

Which firmware for the Cube did you use?

Cheers,
p

1 Like

I used 1.26.04 of a-culfw.

I’m having more success with CUL. Pairing now works, but only once per session: I have to restart the homegear client between pairing sessions.

If I leave the client open, I can see the device that is attempting to pair is sending messages to homegear, but the debug message I see on success does not appear (Module MAX: Debug: Device 2: Access granted for packet X).

Hi @sebbacon,

sorry for the late replay. Probably the error is not in Homegear. But you can post a full log on loglevel 4 here showing the mentioned behavior. Maybe that helps identifying the issue.

Cheers,

Sathya