OK, I'm lazy...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • John Winter
    Automated Home Sr Member
    • Dec 2007
    • 56

    OK, I'm lazy...

    Second one for tonight - I was just checking out another thread, regarding reflex fallback functionality. If my Cortex PC was to fail, right now I'd have no fallback (the DRB's and SLD's) would not work.

    Is there a simple set of reflex programming commands (a walkthrough perhaps) that I could follow, to allow programming of basic reflex funtionality to my lighting modules? (ie. on/off toggle, dim up/down).

    Secondly, assuming this programming is done, would it then screw with say, macros I have programmed to be triggered by buttons on the modules?

    I'm sure all of this reflex programming business is much easier than I am fearing, but just a few pointers are perhaps all I need to get started!

    John
    --------------------------

    www.nodeone.blogspot.com
  • Paul_B
    Automated Home Legend
    • Jul 2006
    • 608

    #2
    John,

    The modules basically have two modes basic and advanced. When Cortex is running then they operate in advanced mode so your macros work as they do now and Reflex has no effect. However, when Cortex fails AND the modules are reset then the modules fallback to basic mode and operate the Reflex operation.

    I've highlighted the word AND above because it is very important. If a module has been running against Cortex and Cortex fails but the module is NOT reset it won't operate in reflex mode. You might ask yourself, so what is the point. The point is Reflex provides basic operation after a power-cut. You can also configure a watchdog type facility whereby if Cortex doesn't reset the countdown the network will reset automatically and fall into Reflex mode.

    As for exmples have a look at David's most excellent blog:



    For a specific example have a look at this:



    HTH

    Paul
    Last edited by Paul_B; 14 May 2008, 09:12 AM. Reason: Wrong reference

    Comment

    • Gumby
      Moderator
      • May 2004
      • 437

      #3
      Jon?

      Also have a look back through threads in this forum because as I recall there are at least two discussing this topic. I'll add it to the FAQ at some point ...
      ----------------------
      www.gumbrell.com

      Comment

      • Karam
        Automated Home Legend
        • Mar 2005
        • 863

        #4
        Just to clarify a bit at the detailed end:

        In the modules (and individual subfunctions of) there are generally two types of Reflexes: A User defined Reflex (UDR) and an 'Auto-Response' Reflex (AR). Either of these is gated by its on flag and can be enabled/disabled at any time. When a module is reset it loads in the various working parameters from EEprom and thereafter works from the RAM based copy which can obviously be modified dynamically if required.

        Generally speaking when Cortex starts running a network it disables the UDR functions in all modules and enables the ARs (which are signal state reporting Reflexes). This is so that UDRs do not conflict with Cortex's own automation decisions. For example you could have a UDR which directly switched a light from a button. If this ran concurrently with Cortex automation there could be a loss of synchronisation between what state Cortex thinks the light is in and what it actually is (though this could be notionally circumvented by the button reflex also telling Cortex what it has done directly), but also there could simply be a conflict of decision eg. user presses the button to turn light off but Cortex automation is registering that light level is low, user in room etc. and so turns light back on again. No doubt there can be methods dreamt up to get around this too - its an interesting research exercise - but for the present its easier to disable the UDRs during Cortex network run.

        So again generally speaking the way the fallback is handled is by ensuring the modules are reset in the event of a Cortex or mains power failure for example. This is typically achieved by having one or more modules acting as watchdogs such that if they don't receive a 'hearbeat message' from Cortex they initiate the network wide reset. Upon reset the modules load in the EEprom stored parameters in which the desired UDR flags are enabled and hence the network now runs under UDR control.

        HOWEVER there is nothing to stop you running UDRs and ARs at the same time and while Cortex is running the network if you so wish and understand the possible consequences. To do this you'd simply enable the required UDR flags after Cortex network startup (via the associated event and a macro containing the appropriate command packets). There are other permutations too - for example you can have a module on the network which is 'network disabled' insofar as Cortex is concerned. This module will therefore always run any UDRs it has been programmed with since Cortex will not touch it upon network start up. You could even for example enable and disable UDRs upon Cortex generated events - though to what purpose I have yet to dream up

        One word of warning to all Reflex programmers though: it is strongly advised that any Reflex programming is done with the network stopped AND the modules in question having the their output states in the desired startup values, since the prevailing output states are saved as startup up states during reflex programming. For example if you have a relay module which happens to have output 1 ON and output 2 off during Reflex programming then the next time you reset that module it will initilaise the outputs to those states. You can of course change this with a second round of Reflex programming but it may save you some hours of hair pulling to understand this

        As regards the Reflex programming process itself .. Cortex provides a utility which perhaps appears unintuitive at first in the sense that Reflex actions tend to be associated with target modules rather than the module which is issuing the command. For example a Relay switching Reflex will be associated with the target relay switching module rather than the button module which you are programming to actually create the action. There are good reasons for this which I won't elaborate on here, suffice it to draw your attention to it.

        As David has suggested perhaps walking through a couple of examples will make it a bit clearer. I can't say that its a trivial task, particularly for more elaborate conditional Reflex programs but we'll be happy to help where we can.

        Karam

        Comment

        • John Winter
          Automated Home Sr Member
          • Dec 2007
          • 56

          #5
          Guys - thanks for the comprehensive input on this one. I did forget that Gumby had a detailed walkthrough on his blog, so I'll have a go at following that one, and feedback on my (slow and erratic) progress. Only problem for me now is, I don't have a MFP to trigger a reset if Cortex goes down. Is that the only option?
          --------------------------

          www.nodeone.blogspot.com

          Comment

          • Paul_B
            Automated Home Legend
            • Jul 2006
            • 608

            #6
            John,

            No it isn't. I don't have an MFP but Karam very kindly sent me instructions on how to use a temperature sensor to act as the watchdog timer. I'm sure Karam will fill you in later. But if not I'll try and dig it out.

            Paul

            Comment

            • Paul_B
              Automated Home Legend
              • Jul 2006
              • 608

              #7
              David,

              All I can say is that I am sorry it was late, I was tired and I am an idiot!! Now corrected.

              Comment

              • Karam
                Automated Home Legend
                • Mar 2005
                • 863

                #8
                Originally posted by John Winter View Post
                Only problem for me now is, I don't have a MFP to trigger a reset if Cortex goes down. Is that the only option?
                No, as Paul suggested you can in fact use the less sophisticated timers present in most sensory modules (such as DTS). But Cortex does not have this option 'pre-canned' (as David would put it ) as yet so here is my usual long winded explanation of the method, extracted from an earlier reply on the subject:

                You use the reflex programmimg utility to set up two user defined responses for the timer trigger in the DTS module. The first response should be a broadcast network reset and the second response a self reset (I think the former is provided as a default packet in the Cortex Reflex utility, but if not then just follow same procedure as for MFP in help to define these two packets). You should not enable the timer trigger in the DTS Reflex menu's Temperature Mode options. In fact don't actively enable any of these unless you had done so for other functions.

                Next you need to set up the scheduler to send a packet to the DTS at regular intervals to set the timeout value. For example say you choose a watchdog timeout value of 30 seconds then the scheduler should perhaps send a packet to re-set the timer every 14 seconds (so you get at least two chances to reset the timer - to reduce risk of missing a reset due to some pause in Cortex). The packet to send will be of the form: FA,90,xx,yy,44,00,12,07,06,time, where xx,yy is NID of DTS, time is the timeout value in hex eg. 20 gives you 32 seconds. (Commas only for clarity don't inclyude in actual command packet)

                Then you need to prime the timer and enable the timer trigger and user defined response on the DTS only after a Cortex start up. To do this you first need to create a macro (Watchdog enable). In this macro you place two network packets of the form:

                FA,90,xx,yy,44,00,12,07,06,time (sets the watchdog timer as in scheduler)
                FA,90,xx,yy,44,00,12,07,10,28 (enables timer trigger and UDR)

                Now you visit the World Connections menu and add the Macro name to the 'After start and initialisation complete' box.

                You can also create a second macro (Watchdog disable) with a single entry of:

                FA,90,xx,yy,44,00,12,07,20,28 (disables timer trigger and UDR)

                This macro can be added to the 'Before network stop' World connection and its purpose is to prevent the watchdog causing a system reset if you have manually stopped Cortex. (You can still test the watchdog using the newtwork pause button)

                Ok so in summary here is what happens:

                When Cortex is started and after it has initialised the modules to its required state your first macro will additionally prime the DTS timer and enable the timer trigger and associated UDR.

                Some seconds later the scheduler will send a packet to the DTS to reset the timer value thus preventing a timeout response and this carries on regularly.

                If the network is paused/Cortex crashes or such, then the DTS timer will eventually trigger the UDR. This in turn will send out a broadcast packet to reset all network modules and will then reset the DTS itself. Since the state of the Temperature mode byte in a reset DTS does not have the timer trigger enabled you will not get further timer based UDRs. So this is why I said you should keep this check box clear when you Reflex program the DTS. It is however possible for other triggers to be enabled such as for high/low temperature triggers and that the UDR is enabled as well. The thing to understand here is that you can enable a trigger in working memory (ie. after a module has initialised) but this is not the same as saving that condition such that it occurs automatically after a module reset.

                Anyhow if Cortex then starts running the network again the whole watchdog process will of course be restarted.

                If you manually shutdown Cortex then the Watchdog dsiable macro will be executed before network stop and this will disable the timer trigger and UDR on the DTS.

                Apologies once again for the long winded answer ...

                Karam
                Last edited by Karam; 17 June 2008, 10:46 AM. Reason: Correction to timer enable/disable packets

                Comment

                • Viv
                  Automated Home Ninja
                  • Dec 2004
                  • 284

                  #9
                  I would only add that a timer value of 32 seconds I would consider a little short.
                  Whilst Cortex uses multiple threads where possible, some requests of the operating system could stall e.g. email collecting and a non responsive site or connecting a Network camera. Whilst I would not expect it to take 30+ seconds if a significant time had been taken many packets could have been received from the Idranet during that time. These would then get serviced as a priority and further delay the process of updating the timer.

                  Personally I would set the module timer to 4 minutes i.e. F0 hex and have Cortex re-set the timer every minute.

                  Viv

                  Comment

                  • John Winter
                    Automated Home Sr Member
                    • Dec 2007
                    • 56

                    #10
                    Karam, Viv,

                    Thanks for your input on this one. I have succesfully programmed the reflex functionality of some of my modules now and I'm happy with the results. Only thing I can't get working is the watchdog function - is the information you gave above good for PLH modules? Do the IFN's differ?

                    John
                    --------------------------

                    www.nodeone.blogspot.com

                    Comment

                    • Karam
                      Automated Home Legend
                      • Mar 2005
                      • 863

                      #11
                      Originally posted by John Winter View Post
                      Karam, Viv,

                      Only thing I can't get working is the watchdog function - is the information you gave above good for PLH modules? Do the IFN's differ?

                      John
                      In my example the timer+UDR enable/disable packets were missing the IFN (Internal Function Number) - which is 07 for the temperature function (there is an independent timer associated with each analogue signal subfunction, so 3 such timers on a PLH).

                      My earlier post has now been corrected. However you still won't be able to get this to work properly because there appears to be a bug which prevents the execution of a module self reset - meaning it would keep reseting the network but not itself! We'll try and get you a firmware fix for this as soon as we can. If anyone else needs this quickly please let us know otherwise it will appear via a Cortex based firmware upgrade in due course.

                      It looks likely that this bug might affect some other modules of similar family eg. PLT, LTH etc. If in doubt and you have an urgent need then please contact us directly.
                      Last edited by Karam; 17 June 2008, 11:02 AM. Reason: typo

                      Comment

                      Working...
                      X