Fix pilight value as subject

[hugokernel]

Thank you for this project ;)

The Pilight gateway with the valueAsASubject parameter does not work (compilation problem).

This PR fixes this problem and closes the #408 ticket.

I also added a patch that allows to find a correct ID (in order to have a non null topic) because PiLight only reads ID and ignores the others fields.

One question, in the ZgatewayPilight.ino file, there are this line: RFPiLightdata.set("length", (char*)deviceID.c_str()); is it normal to set the length value from the deviceID value?

Thank you.

[1technophile]

Thanks for this PR!

One question, in the ZgatewayPilight.ino file, there are this line: RFPiLightdata.set("length", (char*)deviceID.c_str()); is it normal to set the length value from the deviceID value?

Seems strange, I think it should be removed.

[hugokernel]

One question, in the ZgatewayPilight.ino file, there are this line: RFPiLightdata.set("length", (char*)deviceID.c_str()); is it normal to set the length value from the deviceID value?

Seems strange, I think it should be removed.

Or replaced with the length of the payload ?

What is the purpose of the length field in general?

[1technophile]

Or replaced with the length of the payload ?
What is the purpose of the length field in general?

I think it is as an analogy with the length obtained by RCSwitch, which is the number of signal bits.

We would have the length with Pilight if receiving a pulse train (the raw signal) through setPulseTrainCallBack , the current data used with Pilight throught setCallback is at a higher level compared to RCSwitch , so I don't think we need it.

[hugokernel]

Or replaced with the length of the payload ?
What is the purpose of the length field in general?

I think it is as an analogy with the length obtained by RCSwitch, which is the number of signal bits.

We would have the length with Pilight if receiving a pulse train (the raw signal) through setPulseTrainCallBack , the current data used with Pilight throught setCallback is at a higher level compared to RCSwitch , so I don't think we need it.

👍

[hugokernel]

When a radio frame arrives, Pilight will test all the protocols he knows in order to parse the content in search of the right one.

It is therefore quite possible to obtain several protocols that match for the same frame.

The problem is that the same frame can return several different protocols but with the same ID, the frames being published with the corresponding ID in the topic, all the protocols are not visible.

It would be interesting to have an option to add the protocol in the topic, for example, instead of having:

home/OpenMQTTGateway/PilighttoMQTT/32342.

We would have:

home/OpenMQTTGateway/PilighttoMQTT/iwds07/32342

The patch is extremely simple and very useful with PiLight (I use it), maybe it would be a good idea to add a general option for that or add it at least when Pilight is configured?

If you want, I can submit my commit in this PR.

[1technophile]

The problem is that the same frame can return several different protocols but with the same ID, the frames being published with the corresponding ID in the topic, all the protocols are not visible.

Do you mean that they are not published but overwritten by the last one?

[hugokernel]

The problem is that the same frame can return several different protocols but with the same ID, the frames being published with the corresponding ID in the topic, all the protocols are not visible.

Do you mean that they are not published but overwritten by the last one?

Frame is published but overwritten by the last one.

[hugokernel]

I saw you have a RFBridge hacked with Pilight on it, if you want to try:

diff --git a/main/main.ino b/main/main.ino
index 3c222e7..1cf9403 100644
--- a/main/main.ino
+++ b/main/main.ino
@@ -245,8 +245,9 @@ void pub(char* topicori, JsonObject& data) {
 #ifdef valueAsASubject
 #  ifdef ZgatewayPilight
     String value = data["value"];
+    String protocol = data["protocol"];
     if (value != 0) {
-      topic = topic + "/" + value;
+      topic = topic + "/" + protocol + "/" + value;
     }
 #  else
     SIGNAL_SIZE_UL_ULL value = data["value"];

The patch is only applied when Pilight is enabled but I think it could be interesting to have this option which can be useful especially to avoid collisions of devices with the same ID but different protocols or simply to classify things more finely.

If you think it will be interesting, I can do a pull request about that.

[1technophile]

If you think it will be interesting, I can do a pull request about that.

I agree, it can be interesting and enables us to have a more detailed view of the signal received. Nevertheless, I'm not sure about the best way to do it more globally. I have also some thinking around 433mhz that I would like to mature before making you work on this.

Thanks for the proposal and the PR :-)