Don't run CAYENNE_IN functions on program start


Is there a mechanism to not run the CAYENNE_IN functions on program start-up?



I don’t think so, but what are you trying to accomplish? I’m sure we can figure something out.

Hi Adam,

Just one note before I go on my long exposition below: I only allow Cayenne to interact with my control system via virtual pins. The idea is that the controller “owns” the process even if there is a loss of communication between the Cayenne server and the controller.

I have a valve (valve tag LV1111) which allows water into a reservoir based on level, and a pump (motor tag PUM112) which conveys water to my garden based on low soil moisture. Both devices have a operator hand-switch (HS) to allow the operator to energize and de-energize them. Both devices also have a maintenance override switch (MOS) which forces the main process to ignore the sensor setpoints (i.e. put their control loops in manual). I have some logic that dictates when their HSs are pressed their MOSs are also activated. This basically puts the loops in manual until the operator deems it appropriate to go back to Auto. With the CAYENNE_IN running on every connection their are a few undesirable events that can occur. See below for an example one of my CAYENNE_IN(HS) functions and one series of events that ultimately leads to one of these undesirable events:

int State_LV1111HS = getValue.asInt();

Mode_LV1111MOS = Manual; //MOS Activated

if (State_LV1111HS == 0){
State_LV1111 = RelayOff;
State_LV1111 = RelayON;

Possible Series of Events:

  1. Connection = Active, Mode = Auto, Reservoir Level = Low, Valve State = Energized
  2. Cayenne Connection Lost (i.e. Cayenne last known Valve State = Energized)
  3. Connection = Inactive, Mode = Auto, Reservoir Level = Normal, Valve State = Deenergized)
  4. Cayenne Connection Re-established, CAYENNE_IN(Widget_LV1111HS) Runs
  5. Connection = Active, Mode = Manual, Reservoir Level = Normal, Valve State = Energized
  6. Reservoir Overflows - Undesirable event!

Note: This is a Normally Closed (NC) valve.

I could have a pile of boolean values which try to avoid this event like IsFirstConnect, but I am looking for a more elegant solution (for example modifiying the header file(s) to only allow and initial syncall)



I would assume that it is “working as intended” since if the devices loses connection you would normally want it to initialize everything to again to have everything synced. My solution would be to do as you said and create a boolean IsFirstConnect variable. @rsiegel do you have any suggestions?

My initial thought is the same – that you could use some sort of tracking variable/logic in your code to know when you are on the first/a new run. I don’t think there is any built in mechanism to accomplish this that’s already been written and just needs to be set as a flag, at least.

That said, the code including all header files are open source so I imagine it is possible to dig down and redefine the way the core features work if you are a better developer than I am (read: actually a developer :slight_smile: )