0.30.2 - send_packet service call fails with 18:000730

[zxdavb]

I can’t get the send_packet service to work with any of the 0.30.x versions.

I’m trying to send a packet to turn on/off the BDR relay, using the example from the GitHub wiki, which was working most recently a couple of weeks ago on 0.28.

Essentially, I call send_packet, and nothing appears in the packet log and there are no errors shown in the HA log at the time of calling the service.

- service: ramses_cc.send_packet
  data:
    device_id: "18:000730"
    verb: I
    code: "0008"
    payload: "0000"

EDIT: Solution

The issue is mapping between a gateways actual address (e.g. 18:137610) and the sentinel address (i.e. 18:000730).

Note that:

• the actual gwy address should be in gwy._transport.get_extra_info(SZ_ACTIVE_HGI)
• the actual gwy type (HGI80 vs evofw3) be in gwy._transport.get_extra_info(SZ_IS_EVOFW3)

The solution here is:

• for addr0: if actual address, then substitute the sentinel address (not strictly required for evofw3)
• for addr1: any sentinel address substituted with the actual address
• for addr2: as above

[MuddyRock]

Sorry - I realised I missed some useful info on the HA forum post, so I'm adding a tiny bit more detail here - hope that's OK?
To be clear, this is on a evofwv3 usb dongle and not on an HGI80 and it didn't work in vanilla 0.28 - to get it working, I had to apply a patch #68 which was not implemented in 0.28 vanilla.
I'm still teaching myself Python so I can't claim any credit for the code in the patch - all I did was compare the code in older versions where send_packet worked with the changes made in 0.28 to work out what broke it for the dongle.
That said, I'm happy to help in any way I can - e.g. testing, sending packet or other logs, etc - please just let me know what I can do.

[zxdavb]

The challenge here is that a evofw3 and a HGI80 behave differently, and that ramses_rf couldn't tell which of the two you had.

It can now, so now we need to take the next step...

[zxdavb]

@MuddyRock You want to send to a 13:, right?

service: ramses_cc.send_packet
data:
  verb: I
  code: "0008"
  device_id: "13:000730"
  payload: "0064"

You're sending to 18:000730, and that won't do anything.

[MuddyRock]

Aha - progress!
The good news is that the system is definitely sending packets, if I pick a device_id of almost anything other than 18:000730.

Some further questions though:

• 18:000730 was copied directly from the Wiki page which says

Note for the service calls you must use the HGI80/SSM internal id (18:000730) for the destination. It will not work if you use any other id.

and this was working in 0.28.

• For the past few days, the BDR has had a flashing red light indicating it's lost comms with the previously bound nanoCUL. I've now sent several packets addressed directly to it via HA (example below from packet log) and the relay still hasn't stopped flashing. I'm not sure of the significance of the 000730, so I've tried sending to 13:000730 too, as per your example, and that hasn't worked either.

2023-11-23T18:41:25.304178 000  I --- 18:000278 13:086478 --:------ 0008 002 0000

I'm almost certainly doing something else stupid, but I can't figure out what!

[zxdavb]

I didn't write that wiki article... the chap who wrote it knows what he's doing, though. So I doubt its a mistake.

[zxdavb]

So, it should be:

service: ramses_cc.send_packet
data:
  verb: I
  code: "0008"
  device_id: "18:000278"
  payload: "00C8"

Where 18:000278 is the actual address of your gateway, and specifically not the sentinel value, 18:000730.

(for others, it is only a co-incidence that this actual gateway address starts with 18:000)

[MuddyRock]

Thanks for your help so far, but still no joy. Using your config as below in Home Assistant, sending to the gateway (18:000278 in my case) results in no packets appearing in the packet log. (And just to be clear, by "gateway", I'm assuming you mean the USB dongle, and not what I call the BDR controller below, which I've also seen referred to as a wireless gateway for the relay)

service: ramses_cc.send_packet
data:
  verb: I
  code: "0008"
  device_id: "18:000278"
  payload: "0000"

Sending works, because I can send to e.g. 13:086478 (my BDR controller) and a packet immediately appears in the log, but it's not picked up by the BDR controller which still has a red light showing.

I noticed you've added a solution to the above, referencing the three address fields in the packet. Does that mean a code change is needed?

[zxdavb]

OK, testing in 0.31.7, with an evofw3 dongle with id 18:006402.

Starting with this logging:

logger:
  logs:
    ramses_tx.transport: info

With this service call:

service: ramses_cc.send_packet
data:
  device_id: "18:000730"
  verb: I
  code: "0008"
  payload: "00C1"

In the home-assistant.log, I get:

16:54:56.704 ... [ramses_tx.transport] Tx:     b' I --- 18:000730 18:006402 --:------ 0008 002 00C1\r\n'
16:54:56.728 ... [ramses_tx.transport] Rx: b'000  I --- 18:006402 18:006402 --:------ 0008 002 00C1\r\n'

... this is as expected.

However, in the packet.log, I get nothing:

... this appears to be a bug!

[zxdavb]

Note that the (destination) device_id must be in the known list, otherwise, you'll see:

2024-02-04 16:49:57.085 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved:   
   ...
ramses_tx.exceptions.ProtocolError: QosProtocol(WantEcho, len(queue)=1): 
  Failed to send 1F09|RQ|01:123456: excluded by list

[zxdavb]

With this slightly different service call (note the device_id):

service: ramses_cc.send_packet
data:
  device_id: "18:006402"
  verb: I
  code: "0008"
  payload: "00C2"

In the home-assistant.log, I get:

17:00:12.165 ... [ramses_tx.transport] Tx:     b' I --- 18:000730 18:006402 --:------ 0008 002 00C2\r\n'
17:00:12.189 ... [ramses_tx.transport] Rx: b'000  I --- 18:006402 18:006402 --:------ 0008 002 00C2\r\n'

... this is as expected.

However, in the packet.log, I get nothing:

... this appears to be a bug!

[zxdavb]

So the issue is:

This packet has an invalid address set:

 I --- 18:006402 18:006402 --:------ 0008 002 00C2

... it should look like this for the I verb:

 I --- 18:006402 --:------ 18:006402 0008 002 00C2

The send_packet service would work fine with a RQ, RP (or even a W), like so:

RQ --- 18:006402 01:145038 --:------ 0008 002 00C2

... because that address set is valid for those verbs.

[zxdavb]

OK, this is a HACK-fix:

    async def async_send_packet(call: ServiceCall) -> None:
...
        if cmd.src.id == "18:000730" and cmd.dst.id == broker.client.hgi.id:
            try:
                pkt_addrs(broker.client.hgi.id + cmd._frame[16:37])
            except PacketAddrSetInvalid:
                cmd._addrs[1], cmd._addrs[2] = cmd._addrs[2], cmd._addrs[1]
                cmd._repr = None

        broker.client.send_cmd(cmd)