Adding ACK to a sketch, RelayActuator for example
-
I don't want to create another topic as the subject is almost the same. I'm building a controller and ack is something important. For the GUI of the controller to work correctly, sensors need to follow standards. In case of an actuator, I thought the standard would only be to wait for an ack to update the GUI. But if you look at the Dimmer code, it also sends back its state (on/off, and %). So this is a double ack or something... Moreover, it's pretty obvious that when the percentage set is > 0%, the light is on (in the context of the sketch). Is there any kind of best practices guide somewhere?
-
I don't want to create another topic as the subject is almost the same. I'm building a controller and ack is something important. For the GUI of the controller to work correctly, sensors need to follow standards. In case of an actuator, I thought the standard would only be to wait for an ack to update the GUI. But if you look at the Dimmer code, it also sends back its state (on/off, and %). So this is a double ack or something... Moreover, it's pretty obvious that when the percentage set is > 0%, the light is on (in the context of the sketch). Is there any kind of best practices guide somewhere?
@Marvin-Roger Sending back a state is something I was looking at doing, in addition to the ack that I thought was supposed to happen. Thanks for pointing me to an example.
I suspect that the best practice is to do whatever works for you, but maybe hek can shed more light on this.
-
@Marvin-Roger said:
But if you look at the Dimmer code, it also sends back its state (on/off, and %).
Yes, you're right. Shouldn't need to be there! Strange that this has been there for so long. Might be an old residue from how vera behaves.
-
Okay, I was able to get it work properly when the sensor was close by, so this appears to be a combination of a reception issue, and if the sensor gets reset then it seems that I have to reset my ethernet gateway as well. Is that normal?
Is there a clean way to have the enet gateway auto-reset every 12 hours or so?
-
I'm developing a controller and I reset my sensor nodes all the time and the ethernet gateway keeps working as expected.
My advice: do not power your nRF from the arduino 3.3V pin, instead, take power from the 5V pin and step that down to 3.3V using a voltage regulator. (like LM1777 including caps) -
I'm developing a controller and I reset my sensor nodes all the time and the ethernet gateway keeps working as expected.
My advice: do not power your nRF from the arduino 3.3V pin, instead, take power from the 5V pin and step that down to 3.3V using a voltage regulator. (like LM1777 including caps) -
@Marvin-Roger said:
But if you look at the Dimmer code, it also sends back its state (on/off, and %).
Yes, you're right. Shouldn't need to be there! Strange that this has been there for so long. Might be an old residue from how vera behaves.
@hek said:
@Marvin-Roger said:
But if you look at the Dimmer code, it also sends back its state (on/off, and %).
Yes, you're right. Shouldn't need to be there! Strange that this has been there for so long. Might be an old residue from how vera behaves.
I use the "status reporting" in the gui to demonstrate the actual state of the dimmer. In case you have a slow dimmer it can take a while before the end state is reached. With blinds or curtains this is even more obvious. So the sent ask is in fact the mark of 'action accomplished'
-
@hek said:
@Marvin-Roger said:
But if you look at the Dimmer code, it also sends back its state (on/off, and %).
Yes, you're right. Shouldn't need to be there! Strange that this has been there for so long. Might be an old residue from how vera behaves.
I use the "status reporting" in the gui to demonstrate the actual state of the dimmer. In case you have a slow dimmer it can take a while before the end state is reached. With blinds or curtains this is even more obvious. So the sent ask is in fact the mark of 'action accomplished'
@AWI I did think about this, but don't you think this is a bit too much, sending, in case of shutters for example, each percentage reached? That's a lot of overhead, and it might be error-prone (if the user requests 100% and if the last message that sets the GUI to 100% fails somehow, the user will see 99% — but the shutters will actually be 100% —).
This is an interesting problematic as it is, in my opinion, essential that the sensors have a consistent behavior.
-
@AWI I did think about this, but don't you think this is a bit too much, sending, in case of shutters for example, each percentage reached? That's a lot of overhead, and it might be error-prone (if the user requests 100% and if the last message that sets the GUI to 100% fails somehow, the user will see 99% — but the shutters will actually be 100% —).
This is an interesting problematic as it is, in my opinion, essential that the sensors have a consistent behavior.
@Marvin-Roger I agree with you that sending each percentage close is a bit to much. But in the case of shutters it often occurs that the final position is not reached (shutter frozen, window open, etc.) So it isreporting only the value reached at actual stop.
