Tx topic should accept command packets as JSON and not string

[zxdavb]

I am using 0.3.6.

When I subscribe to /RAMSES/GATEWAY/18:017804/rx, I receive packets like so:

{
  "ts": "2024-02-07 08:12:00", 
  "msg": "000 RQ --- 18:017804 10:048122 --:------ 3220 005 0080010000"
}

But when I publish via /RAMSES/GATEWAY/18:017804/tx, I send strings like so:

RQ --- 18:017804 10:048122 --:------ 3220 005 0080010000

Instead, I believe that sent packets should be sent as JSON.

{
  "cmd": "RQ --- 18:017804 10:048122 --:------ 3220 005 0080010000"
}

Because: this will allow us to add meta-data to the command in future, for example:

{
  "cmd": "RQ --- 18:017804 10:048122 --:------ 3220 005 0080010000",
  "num_resends": 3
}

(I am not sure my example is a good one - I am using it only to demonstrate the point I'm making about JSON).

[ghoti57]

Not convinced about this, We can't ask the gateway to do anything that the HGI80 doesn't do ( it doesn't decide to resend by itself) so need a better example of how it might be used.

[zxdavb]

We ~can't~ [shouldn't?] ask the gateway to do anything that the HGI80 doesn't do

I agree that evofw3 shouldn't do anything a HGI80 wouldn't do (although this is not 100% the case, presently - e.g. the way it handles 18:730 in ADDR1, ADDR2).

Instead, I believe that sent packets should be sent as JSON.

The point is that ramses_esp is not evofw3 - it had additional capabilities and it will likely be used in ways we have yet to think of. For example, it could be used as a RF-RF relay.

This is only a suspicion: I can't think of a good example - hence my apology, 'am not sure my example is a good one'.

Regardless, this isn't a biggie - if we can add JSON support in addition to text at some time in the future?

[ghoti57]

I'm thinking of changing it to JSON to help debug the ramses_rf QoS issue. If the JSON includes the timestamp RF publishes the packet to MQTT we'll be able to get a handle on where things might be going wrong.

[ghoti57]

Fixed in v0.4.4