CLI sending message fails

[Onl1ne1373]

I try to send a packet with the cli (evofw3):

sudo python3 client.py execute /dev/ttyUSB0 -x "RP 18:262143 21:033620 01FF 0080802727D0000000143C80800000B40080800280FF80040000"

And get the following result:

client.py: Starting ramses_rf...
 - discovery is force-disabled
15:45:40.079 Best practice is exactly one gateway (HGI) in the known_list: []
15:45:40.079 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True

client.py: Starting engine...
15:45:40.680 The active gateway 18:262143: { class: HGI } (by signature) SHOULD be in the known_list
15:45:40.680 ||  18:262143 |  63:262142 |  I | puzzle_packet    |      || {'datetime': '2024-01-29T15:45:40.084', 'engine': 'v0.31.5', 'parser': 'v0.31.5'}

client.py: Engine stopped: ended without error (e.g. EOF)
 - finished ramses_rf.

I have a second HGI80 that is logging packets and I do not see the packets that I am sending.
What should I change in my bash call?

And is there documentation of the protocol to send packets directly with the serial port device?
I am trying to debug the flow of 01FF Spider protocol and would like to write a tool for RQ RP directly on serial.

[David Bonnes]

If it is installed properly:

client execute /dev/ttyUSB0 -x "RP 18:262143 21:033620 01FF 0080802727D0000000143C80800000B40080800280FF80040000"

The sudo is only needed if the current user is not a member of the dialout group.

The latest commit should address this - there's been a lot of mucking about with QoS recently.

[Onl1ne1373]

I tested sending with the serial monitor of Arduino and the evofw3 echos the command, but the message is not received by the HGI80.
So I think it is a hardware problem or evofw3 bug.

Updated evofw3 to latest version, but no luck. I tried swapping the nanocul and the hgi80, but the driver of hgi80 does not work on my Macbook M2, because of Apple Silicon.

[David Bonnes]

This works for me:

client execute /dev/ttyACM0 -x "RQ 01:145038 1F09 00"

and ...

client execute /dev/ttyACM0 --get-schedule 01:145038 01

[David Bonnes]

Importantly, this also works:

client execute /dev/ttyACM0 -x "RP 18:262143 21:033620 01FF 0080802727D0000000143C80800000B40080800280FF80
040000"

client.py: Starting ramses_rf...
 - discovery is force-disabled
16:51:47.301 Best practice is exactly one gateway (HGI) in the known_list: []
16:51:47.301 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True

client.py: Starting engine...
16:51:47.391 The active gateway 18:006402: { class: HGI } (by signature) SHOULD be in the known_list
16:51:47.391 ||  18:006402 |  63:262142 |  I | puzzle_packet    |      || {'datetime': '2024-02-03T16:51:47.305', 'engine': 'v0.31.6', 'parser':
16:51:47.411 Device 18:262143 is potentially a Foreign gateway, the Active gateway is 18:006402, alternatively, is it a HVAC device?, configure the known_list/block_list as required
16:51:47.460 ||  18:006402 |  63:262142 |  I | puzzle_packet    |      || {'datetime': '2024-02-03T16:51:47.411', 'impersonating': '01FF|RP|18:26
16:51:47.481 RP --- 18:262143 21:033620 --:------ 01FF 024 0080802727D0000000143C80800000B40080800280FF8004 < Payload doesn't match '^0[01][0-9A-F]{50}$': 0080802727D0000000143C80800000B40080800280FF8004

client.py: Engine stopped: ended without error (e.g. EOF)
 - finished ramses_rf.

[David Bonnes]

NOTE: The above packet is sent as expected.

The issue is that when the echo of the transmitted packet is received, it (like all packets that are received) is decoded by ramses_rf.

In this instance, the payload is - incorrectly - tagged as invalid.

That is addressed in another issue, #101, so this issue is closed.