No announcement yet.

Problem trying to restart my HS machine via Ocelot

This topic is closed.
  • Filter
  • Time
  • Show
Clear All
new posts

    Problem trying to restart my HS machine via Ocelot

    I added some relays and logic to detect that my power is off to the HS machine. When that happens, it starts a timer. After 5 minutes, it is supposed to 'press' the power button to turn the HS machine back on. This is in case the UPS is dead (which it is now).
    When the Ocelot is plugged into the serial port of the HS machine, this does not work. I plugged the Ocelot serial into my laptop to watch the timers and it worked just fine, restarting the HS machine.
    Does the powering on of the HS machine and its serial ports somehow cause the Ocelot to restart and not activate my timers?


    Where is the logic that is controlling this reset located? Is it in a CMAX program running on the Ocelot or is it in HomeSeer? If its in HomeSeer and you're trying to reset the HomeSeer machine, then that is your problem.

    If the logic is all within a CMAX program, then where the serial cable is plugged shouldn't matter...

    What are you using to control the power button on the PC? An SECU16? An X10 Universal Module?

    Below is a CMAX snippet that will do what you suggest, assuming you're trying to do this with an SECU16. Program is triggered on Variable #1 becoming 1 (which will then press the power button for 5 seconds and then release it):

    <pre class="ip-ubbcode-code-pre">
    IF Variable #1 becomes = 1
    AND Timer #1 is = 0
    THEN Variable #1 = 0
    THEN Module #1 -SECU16 Relay #8 Turn ON
    THEN Timer #1 = 1

    IF Timer #1 is &gt; 5
    THEN Module #1 -SECU16 Relay #8 Turn OFF
    THEN Timer #1 = 0

    Of course the trigger could be anything other than the Variable changing, ie: X10, trigger based on other input, etc.

    If you paste your code and let us know a bit more about how you are controlling the power switch. Then we should be able to move forward and help out.


      <pre class="ip-ubbcode-code-pre">
      0058 - IF Module #3 -SECU16-I Proteus_Power_Detect Turns ON // clears settings as HS back on
      0059 - THEN Variable #30 = 0 //
      0060 - THEN Timer_Proteus_ISOFF = 0 //
      0061 - ELSE Variable #30 = 1 //
      0062 - IF Module #3 -SECU16-I Proteus_Power_Detect Turns OFF //
      0063 - THEN Timer_Proteus_ISOFF = 1 //
      0064 - IF Timer_Proteus_ISOFF becomes &gt; 300 //
      0065 - OR Timer_Proteus_ISOFF becomes &gt; 600 //
      0066 - OR Timer_Proteus_ISOFF becomes &gt; 900 //
      0067 - OR Timer_Proteus_ISOFF becomes &gt; 1200 //
      0068 - THEN Timer_Proteus_PWRPressed = 1 //
      0069 - THEN Module #1 -SECU16 Proteus_Main_Switch Turn ON // press power switch
      0070 - IF Module #3 -SECU16-I Proteus_Power_Detect Is OFF //
      0071 - AND Timer_Proteus_PWRPressed is &gt; 0 //
      0072 - AND Module #1 -SECU16 Proteus_Main_Switch Is ON //
      0073 - THEN Timer_Proteus_PWRPressed = 0 //
      0074 - THEN Module #1 -SECU16 Proteus_Main_Switch Turn OFF // stop pressing power switch
      0075 - THEN Timer_Proteus_ISOFF = 0 //
      0076 - THEN Timer #3 = 1 //


        <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Where is the logic that is controlling this reset located? Is it in a CMAX program running on the Ocelot or is it in HomeSeer? If its in HomeSeer and you're trying to reset the HomeSeer machine, then that is your problem.

        My code is all CMax for this. It watches a relay and when it changes, power went off. The CMax then switches it back on via timers and SECU16 settings.



          Haven't had a chance to look over your code, hopefully will be able to later today.

          In general, external events do not update status in the Ocelot except between passes (this includes things like updates from external devices like SECU16 analog and on/off updates, variable reads from a slave device, reception of new X10 or IR). This means that in your program you can GENERALLY assume that the value of a variable or timer (as long as your CMAX program itself does not change it) or of a status is CONSTANT throughout the current loop of the program. In GENERAL...

          The exception is if you have a device talking to the Ocelot over the serial port that may change one of these variables or timers directly (such as HomeSeer). Consider the case of the Ocelot being in the middle of a program. If it receives a command over the serial port to change the value of a variable, or timer, then, depending on your program, unexpected results could occur.

          Consider the following (admittedly do-nothing-useful) code:

          <pre class="ip-ubbcode-code-pre">
          001 IF Variable #1 = 0
          002 THEN Variable #2 = 1
          004 IF Variable #1 = 1
          005 THEN Variable #2 = 5
          007 IF Variable #1 &gt; 1
          008 THEN Variable #2 = 9

          So, now let's say that we enter this loop with "Variable #1" being equal to 1. Thus, the first test fails, and program proceeds onto line 3.

          Let's say now while the interpreter is at line 3 a serial command is received to change "Variable #1" to be equal to 7. This could be over the standard binary protocol (as used by HomeSeer) or over the ASCII protocol (ie: someone sent +V010007 over the serial port).

          Then when line 4 comes around to be executed, it is based on the fact that Variable #1 is now 7... This can lead to some very unpredictable results in your program if you don't take into account that this can happen...

          Thus, if you have a HomeSeer script changing a variable and a timer on a regular basis, you could have problems...

          What I do, is use the concept of a "command" variable... Basically this is a variable that my program only ever checks for once during a pass, usually at the top of the loop. This is the variable that HomeSeer or anything over the serial port will change. As soon as my program checks this variable, it will immediately copy it to another variable and never touch the original again. Thus I can ensure that my copy will NEVER change in the program after the initial line, and thus my programs can be predictable. ie, something like this:

          <pre class="ip-ubbcode-code-pre">

          0001 IF Command-Request is NOT = Current-Command
          0002 THEN Current-Command = Command-Request
          ... Rest of your program that does NOT touch Command-Request, except below line
          0900 IF Command-Request = Command-Request // Always
          0901 THEN Command-Request = 65535 // Unknown command
          0902 THEN Current-Command = 65535 // Since we've already processed it...
          0903 End Program

          Where Command-Request is the one that HomeSeer is allowed to modify and Current-Command HomeSeer will not touch... Lines 1, 2, 900, and 901 are the ONLY ones in the program that then touch Command-Request... Thus I can ensure by using Current-Command that it will NEVER change within the program, unless my program itself changes it (though you also have to ensure you never do this in your HomeSeer program).

          Anyways, I haven't looked at your code much, and frankly would need to know what you're doing on the HomeSeer side as well, but considering what you described, I think this is most likely the case, ie: that HomeSeer is changing a variable or timer that your CMAX program isn't expecting to be changed mid-loop in the program...

          I've run into this a lot before doing my "command" type approach and this solved my issues. In fact, this also means that there are a LOT fewer variables to have to sync and change between the two.

          Only downside to doing this type of approach is that your "commands" can only be sent once per program loop. Which usually is not a problem as the Ocelot executes about 2000 lines a second on average. If your program (without taking skips into account) is over 2000 lines, then that might be more than a second though...

          If you tell me a little more now about what your HomeSeer script is changing, that also might shed some light on things.

          BTW - These details on when statuses, etc change in the Ocelot is documented fairly well in the Leopard II documentation (avaiable online). I believe the Ocelot docs have also been greatly enhanced with this info (note that the old docs talking about CMAX 1.x did not have all this info in it).


            <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Anyways, I haven't looked at your code much, and frankly would need to know what you're doing on the HomeSeer side as well, but considering what you described, I think this is most likely the case, ie: that HomeSeer is changing a variable or timer that your CMAX program isn't expecting to be changed mid-loop in the program...

            HS is not doing anything in this case. The only thing that can trigger this code is the change of state of a contact closure when the HS PC loses power and shuts off. The contact closure in the SECU16 triggers the timer to start a countdown of 5 minutes. When 5 minutes are up, it closes an SECU relay that 'presses' the HS PC power button via a relay. A second timer is tested and when over 0, turns the button press off and resets the countdown timer to 0. Now maybe the only thing getting me in trouble is that the button press is too quick for the HS PC to detect it and it runs the code but the button press was too quick to work. I will add a variable to count how many times the HS PC power button was pressed and check that. Maybe that works sometimes and not others......


              I'd definitely use a timer to hold the button depressed for a few seconds, say 3, to ensure it was really down long enough...

              ie: I'm make line 71 read:

              <pre class="ip-ubbcode-code-pre">
              0071 - AND Timer_Proteus_PWRPressed is &gt; 3

              Instead. This will allow, on average, the button to be depressed approximately 3 seconds (ie: from a count of 1 to 4). Though sometimes it will be a little less than 3 seconds (ie: approaching 2) and sometimes a little more (approaching 4) due to the resolution of the timers (ie: all timers are updated in sync regardless of when you start them, so technically I can set a timer to 1 and the next loop (much less than 1 sec later) it might go to 2 based on the RTC in the Ocelot.

              What you have now with &gt; 0 will IMMEDIATELY, in the SAME PASS, make it turn off the relay. In fact, I'm not sure, but the Ocelot (or SECU16) might be smart enough not to toggle the relay at all since both commands to turn on and off the relay will be sent in the same cycle - wouldn't be surprised if the SECU16 just ignores it - though even if it didn't, the relay probably would only be on for a small fraction of a second and thus the PC power supply probably won't detect this.

              If this is the case, changing that 0 to a 3 will most likely solve your problem...

              However, if this happens and during those 3 seconds the power really does come back on (ie: condition on line 70 is NOT satisfied), the code will then not turn the relay back off after it is on... I'd remove the condition entirely...

              Basically once the relay is ON (depressing the button), the ONLY thing you care about is waiting a few seconds to turn it back off - it is irrelevant with anything else (unless you ever want to have it depressed forever, don't knwo why you would).

              I'd just change lines 70-76 to read:

              <pre class="ip-ubbcode-code-pre">
              IF Timer_Proteus_PWRPressed &gt; 3
              THEN Module #1 -SECU16 Proteus_Main_Switch Turn OFF
              THEN Timer_Proteus_PWRPressed = 0

              You really don't care if the relay is on or not (thus you don't need an AND to check that) as you'd end up in the same state anyway. Don't know what the purpose of Timer# 3 on line 76 is, so you might still want to have that (assuming it didn't depend on the status of Proteus_Power_Detect being OFF - if so, I'd have a separate IF with this condition).

              Key is on an SECU16, when you're turning on a relay for whatever purpose, even simply signalling like this, you always need to leave it on for a few seconds to ensure it "does its job".

              For instance, I have a relay pressing my garage door button, if I do this for less than a 2-3 second delay (meaning checking for &gt; 2 or &gt; 3), (ie: 1 second), 90% of the time it won't recognize the button press. About 10% of the time using only a 2 second delay ( &gt; 2) would cause it not to work. the 3 second delay has worked 100% for me...

              If you have an application where you REALLY need something to only be on for sub seconds (which I imagine a PC power switch is NOT a case) - then ADI does have a firmware for the SECU16 that will automatically allow it to turn a relay OFF after it has been turned ON after a certain number of milliseconds as specified by a parameter setting (which I think would then apply to all the relays on the SECU16. However, I don't think this is what you want...

              Hope this helps! Luckily though, it looks like you can easily fix this with a few changes in your code. I should have looked a bit more closely at it first before responding with the serial stuff (was on a conference call at work while responding the last time so I was distracted). :-)


                <BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>See the attached snippit for a copy of my WatchDog.

                It sets a Variable in the Ocelot, which HS monitors, every 20 minutes, it then waits five minutes for HS to change the variable, if HS dosen't then a relay is closed shorting out the RESET switch on the HS computer. It also allows ADIOcelot to shut off the the watchdog for maintenence and keeps a record of how many reboots have occured.

                Yep, I do this too. This new code was to ensure that the HS PC would be turned on in the event that the UPS failed (which it has) and power has returned. I still need to add AC power detection.


                  I tried setting my button press on to 3 seconds. It actually presses it too long. The PC will turn on and then immediately turn off. I will have to check and see if there's something in the bios I can change for that. I know the code was hit as I have added an incrementing variable.


                    I found in the App Dig forums on their site that there is a new pic chip for the SECU16. I am assuming I don't have it anyway. It allows you to set a parm that will control how long a relay is on in 13millisecond increments.
                    I need to call them Monday and see if this is true.
                    So far setting my relay to on for anything higher than 1 will occasionally keep the relay on too long and the pc turns off. Or, it never turns it on.
                    There's no setting in the bios to counter this either.



                      If the firmware upgrade doesn't work (and I can't remember if it requires ALL outputs to then be momentary which could be a big downside), then youg might be able to use something called a "oneshot" circuit.

                      This could then provide a much shorter duration press...

                      The other thing you can try to do (which still won't guarantee that the button would be pressed for any time less than 1 second though), would be instead of using a timer, to count the number of times through the loop. Then after it gets to a certain value (say 100) unpress the button (turn off the relay).

                      On average, and Ocelot can execute 2000 lines per second. So if you program is 200 lines, it will loop 10 times per second on average (skip statemetns will change that). Thus you could count for about 5 loops or so if you want to try to get the button depressed for only 1/2 sec...

                      This being said, it still may be depressed for longer - there's no guarantee that the Ocelot and SECU16 will respond quick enough, especially if there are other devices on the ADNET bus, and especially if you're doing things like syncing variables between the Ocelot and another slave (ie: Leopard, another Ocelot, etc).

                      So, the two best ways would be:

                      1. One shot circuit attached to the SECU16 relay
                      2. The firmware you mentioned, assuming it can be set to only make one relay momentary.


                        I called App Dig and they did say that the PIC would change all the relays on the board. Bad idea. I have relays in use that won't work this way.

                        So I finally took the time to build a 555 timer based circuit that powers the relay for just under a second. The relay in the SECU16 triggers this and I don't care how long it holds the 'button' down. It's worked every time....

                        Now I can turn off all power, let the UPS's die and then power up and watch everything restart. Finally!



                          Can you post a schematic for you 555 circuit? Would love to see it...

                          Was thinking of eventually doing something like this for another application I'll be working on shortly.


                            I purchased THIS Elk timer for monitoring my dryer because I needed a longer contact closure so my SECU16 could pick it up.

                            This thing is great and it even has its own internal relay and variable setting for "ON" time.

                            Just be aware that it does require a DC voltage (power supply) to operate, but then again so would any 555 solution. And this beats getting parts, bread boarding, adding a relay the 555 could drive, acquiring additioal components, etc...

                            I'm not saying that SteveP's solution isn't a good one, just showing another (lazy man's) approach (this would also be a little more expensive.)
                            **** Do You "Cocoon"? ****


                              That Elk timer is really nice. I would have done it except I have only seen it for 25bux. That would be plus shipping. I got about 6bux in parts in it. At 15bux including shipping, I would have bought it. Building one was SO cheap that I just couldn't buy one.