Adding ACK to a sketch, RelayActuator for example
-
I'm a little uncertain on how to add an acknowledgement to a sketch running on a sensor. In my specific case, I've modified the RelayActuator sketch a bit to control my pool lights (toggle a relay 3 times for ON, toggle once for OFF).
I'd like to add some sort of ACK to this so that Vera knows whether the command has been received (like the acknowledgement you get when you turn a light on or off), but I'm not sure exactly how to do this.
I see where ACK's can be enabled, but not sure if those are meant to work like the typical Z-wave device acknowledgements. And would this require modifying the ArduinoRelay1 json and XML files?
Guidance would be much appreciated, or maybe point me to an example that already does that. Thanks!
-
Vera automatically asks for ack when sending out command. If vera doesn't receive an ack, the state of the ON/OFF button won't change.
-
And that's what I see, the ON/OFF buttons don't change as they should, although the action I want (on or off) does happen as it should.
Do I need to add something to send the ack back to Vera?
-
Ok, then ack is lost when being sent from node. Probably powering issue of radio on the node.
-
Okay, I will check the voltage levels although I don't believe that will be it.
Is there any setting in an include file I should check? Or maybe a recently fixed bug (I noticed a few updates since I downloaded 1.5)?
-
Update if you have a repeater node in between.
And if you are missing capacitor on radio, add it.
-
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?
-
No repeater in my network. Also, I did use a capacitor on the sensor radio, but on my gateway I used a radio card with external antenna so I didn't use a cap.
-
@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)
-
@ericvdb I am powering the nRF from the 3.3V pin, so I'll try your suggestion and see if it helps. Thanks.
-
@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.
-
@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.
