Jimini

Thanks, larryllix, for confirming that. I will make use of that.

Thank you for your comments and suggestions, larryllix and kclenden. I did forget to add to my comments that the variable $.Top_of_Hour must be a state variable, but I did include in my opening comment to the program 'Start Top of Hour Clock' that it must be set to auto start at start up. Other than that comment, I don't know how I should have indicated that in my listing. You are correct that as written the "Top of Hour Clock" must either be kick-started by manually starting its THEN clause or reboot ISY. The point is that once kick-started it will restart when ISY reboots for some reason. Making the variable $.Top_of_Hour a state variable and leaving the 'IF $.Top_of_Hour > 0' in the program 'Note Top of Hour' is so that other programs, in particular my original program that I want to run at each Top of Hour, will do so, which was my original question to start this thread. I guess that goal was lost along the way. I do now see the purpose of the 'Init To' statement in that it preserves the value of a variable across ISY reboots which can be reported in the email message at startup. That would be useful. However, the statement setting it to zero after reporting its value will trigger a start of all programs waiting for a 'Top of Hour', which will produce one extra run of each prior to a real top of hour. I think that statement needs to be left out and $.Top_of_Hour then contains the number of hours integrated over all ISY reboots with the email reports the trail of how that increments. Or I guess, I could introduce another integer variable to replace what receives the 'Init To' and what is zeroed after reporting its value in the startup program. Question: does that statement '$.Top_of_Hour Init to $.Top_of_Hour' create a trigger for programs waiting for a change of that variable if the variable is a state variable? I would think not, but just asking to be sure.

Got it, kclenden. Thanks for the delineation of what would cause a program to restart. It is very helpful to get these little details understood. If this is written in the manual somewhere I missed it. I've put together what I think will be my final set of programs for this adventure unless others point out a problem or a more efficient way to accomplishing the goal. I realize that efficiency of execution or of memory space may not be terribly important for ISY programming but I still don't have a feel for how tight either may be. I have noticed one thing that may be relevant to that. When I only had my four little programs that each activated once a day to control lights and wrote no reports to an ISY webpage or email back to me, the dark blue or purple light on my ISY glowed very steady and bright. Since adding my temperature controlling programs that only operate once per hour, that ISY light flickers a lot pulsing as in time with some data transfers. I may have left some program artifacts running that I cannot see, but otherwise, it seems odd for this light to be flickering so nearly always. In any case, I decided to combine much of what I learned from the above thread and put together a sort of hybrid of several ideas. The resultant code is here: Start Top of Hour Clock - [ID 000A][Parent 000D] If // No need for an IF clause, the THEN clause must be set to // auto start on startup of ISY, i.e. reboot. Then // Notification for courtesy that ISY has rebooted // Then start a loop in 'Find First Top of Hour' program to // find when minutes are zero Send Notification to 'MY_GROUP' content 'ISY_REBOOTED.NTF' $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) Else - No Actions - (To add one, press 'Action') Find First Top of Hour - [ID 000C][Parent 000D] If // With the ELSE clause, this forms a loop until the first // Top of Hour is found after an ISY reboot. $Minutes_of_Hour is 0 Then // The first Top of Hour is found // Trigger that with an increment to .Top_of_Hour $.Top_of_Hour += 1 Else // Wait 10 seconds between each test of the minutes on the clock Wait 20 seconds $Minutes_of_Hour = [Current Minute ] Run Program 'Find First Top of Hour' (If) Note Top of Hour - [ID 000B][Parent 000D] If // The increment of state variable .Top_of_Hour by // the program 'Find First Top of Hour' or by the // THEN clause below will trigger this program to run. // Any change to the state variable will cause this program // to run, but an initial value of zero or greater will insure // that the IF statement passes control to the THEN clause. // Initializing it to 0, will allow it to mark the number of hours // since reboot. $.Top_of_Hour > 0 Then // Wait one hour before retriggering the IF clause above. // Any other program testing the state variable .Top_of_Hour // will also be tiggered at each top of hour. Wait 1 hour $.Top_of_Hour += 1 Else - No Actions - (To add one, press 'Action') I have not tested it by rebooting ISY as yet, but I tested it by manually starting the program 'Start Top of Hour Clock' and this works fine. I decided that rather than keep a program looping every 20 seconds to continuously find the next Top of Hour, I would find the first one and then use Wait 1 hour to find each successive one. I will need to test over some time to see if this eventually looses too much time with respect to the real top of hour. I am wondering if once I have at least one other program being triggered by the .Top_of_Hour variable, that other program could start execution before this 'Note Top of Hour' program wakes up and initiates its WAIT 1 hour. This would delay the start of the 1 hour wait. Likely that will be less than minutes but perhaps a protocol should be established for each such program being triggered by .Top_of_Hour to issue a 'WAIT 1 second' before doing anything else to assure that the 1 hour wait is started. That may be over kill but any delay in starting the 1 hour wait will be a cumulative offset. I don't know if this will be any more efficient in ISY resources than a continuously running 20 second loop, but I thought this way, I am leaving the efficiency question up to the ISY developers for an efficient 1 hour wait. Any comments are welcome as usual.

I really appreciate all the discussion. I guess we all our at the point of guessing how the internals of ISY work. I don't remember seeing how many bits are allocated for integer variables hence my concern about incrementing every hour Thanks to Bumershoot for alleviating that concern. And as for the triggers or timing conditions, I wasn't sure if this was accomplished by software loops or hardware timers. The suggestion that software loops are likely used would make sense for a system with limited hardware but an unknown number of triggers desired by the users. I was happy to see larryllix is an old time machine code programmer from the 1970s. I spent the better part of two years writing the real time data acquisition software for my thesis experiment in the 1970s on a 1.25MHz computer. Some 25 years ago, I demonstrated that I knew some electronics and could manage projects and I never wrote another line of code. It's been much fun to play with ISY programs and Google Scripts. It would be interesting to learn a bit more about the ISY hardware. Perhaps I can get a couple more questions answered. For those two little program fragments that I included earlier, the first had no IF clause, only a THEN which should start each time ISY rebutted. Is that correct? It can exist without an IF clause? Secondly, when kclenden pointed out the need to specify that his program should auto start at startup, that was yet another ISY feature that I did not recall. In fact, I have four other programs that each start with an IF based upon time of day. After this recent extended power outage, these four programs restarted as desired and have been running correctly but those four programs do not have that autostart ON set. Is it understandable why they all restarted? I think I have enough information to setup my program to operate as I want. I guess to really test it, I will have to manually reboot my ISY to see how the programs behave.

Thank you all for the many suggestions. The discussion has been interesting. I know very little about the hardware resources within ISY so it is difficult to judge he "efficiency" of the various suggestions. In addition to the perhaps inelegance of the 24 clause of an IF statement is whether that would set up 24 separate tiggers to be installed perpetually. Questions about larryllix's suggestion: Is the intent that the "REPEAT every 20 seconds" runs for ever or just at the 4 times per day of the IF statement? I think it runs continuously for ever. If so, then what is the purpose of the 4 times in the IF statement? Also, what does the INIT TO action do? I am not familiar with that action. Certainly, Bumbershoot's suggestion would be the most elegant if there is a simple way to increment a state variable at the beginning of each hour, but to do that isn't a loop similar to larryllix's 20-second repeat loop required? A condition similar to "IF [current minute] is 0" which which set up some sort of trigger would do that but I don't think something like that is possible. Possibly a pair of programs such as: Program SetTopOfHour REPEAT every 20 seconds CurrentMinutes = [current minutes] RUN PROGRAM 'check minutes' Program check minutes IF CurrentMinutes = 0 THEN TopOfHour *= -TopOfHour // State variable initialized to -1 // Flipping sign for perpetual changes Perhaps these are so short as to not create too much overhead executing every 20 seconds?

This question may be answered in some Forum thread but I have tried several ways to ask the question without finding ti covered anywhere. I want an ISY program to execute every hour on the hour, or at least approximately on the hour. I currently have a way of doing this but I have found it is not sufficiently bullet proof. Our neighborhood recently experienced a power outage for 52 hours. When power was restored, all of my programs with starts based upon time of day, restarted. My program to loop every hour was waiting for the time of day of the original start, which was some 16 hours later. In similar situations, I would want my program to restart at the next whole hour. My existing program looks like this: if ( time is 8:00:00AM // This was just an aribtrary time to start program at an hour boundary and ProgRunning is 0 ) or ( time is Last Run Time for 'Prog Init' + 1 hour and ProgRunning > 0 ) then ProgRunning += 1 execute stuff The problem occurred, I believe, because once ISY rebooted after the power outage, the flag variable ProgRunning was re-initialized to 0 and possibly the Last Run Time may also have been cleared. I don't know about that. I am thinking there is likely an easier and more robust way to do this. Am I correct in that?

To finish my post of 21-November-19, the SmartHome contact got back to me stating the following, which I will paraphrase: The temperature sensor in the MSII was never fully developed and therefore is not supported by their Insteon hub, etc. Those with an ISY have access to that sensor, but it is still not supported by SmartHome. They offered to replace all three of my MSII units but warned that the replacements will behave in the same way. [What I had reported was that one unit often simply returned the previous value and would continue to do so for up to 10 consecutive queries before I would give up and wait some time before trying again while my other two sitting next to it reported different temperatures.] I replied that since two were operating as expected, I would like to replace just one and not all three. They agreed to that and sent me one replacement, covering the shipping in both directions. The replacement has been operating correctly for about a month while I again tested all there positioned next to each along with a mercury thermometer. I collected readings over a 20F range. I couldn't get the calibration process to reach exactly the correct reading so decided to use a software correction. Using just an offset got within 2F but a linear fit got close to1F so I am using that. There may be a quadratic term but my test range was not wide enough to capture that. I have the three MSII units positioned now in their final operating places.

I will add one more warning to those from Michel about this MS-II. I finally found time to get back to testing my three MS-II units, which had been giving me trouble in September. Now two months later, while all three units have been powered up but not accessed, I ran several queries every few hours for two days as the temperature in the room changed by a couple of degrees each time. Two of the sensors tracked well and one hick-uped only once. The third behaved erratically as it had two months ago. Most queries reported the same value as the previous read, returning a new value rarely. And many of those values were negative numbers. I had heard about some of this from others on the forum but the problem with this unit was that I often would have to query more than 10 times without a change to an actual value. There is no way to tell when the read back is valid or just stuck on the previous value. I contacted Smarthome to have this one replaced. At first, I was told that the MS-II isn't a temperature sensor so they would only respond to problems sensing motion. After pressing the person, he asked me to send him a screen shot of the ISY console and a description of the problem. He would discuss this with the developer. No final resolution yet, but it appears that they may not back their product for temperature sensing.

Yes, I can see the advantages of providing a connection between ISY and either Alexa or Google Home. I don't yet use those but could consider adding one of those in the future. The main downside of all that for me is that my music library is stored on a Mac computer which is connected to my Bose sound system through an Apple TV and the Bose system has audio outlets in six rooms of the house in addition to the Dolby 5.1 surround sound system in the family room. This Bose system is old enough that each room's audio is controlled by its own Bose remote. Tying all this with the IFTTT interface seems unlikely. I did look to see if IFTTT would connect to the Apple TV but asking the question did not yield an answer. Given all this, unless I am overlooking something fundamental, I think the voice commands would likely be limited to lighting scenes, at least until I'm ready to replace my entire sound system and library storage. But I do appreciate all the help understanding how all these pieces fit together.

Thanks, larryllix, for the added information. It does appear that I can use this to track my three temperature sensors over time with the actual read back values and not just when those values change as with the system log. If I can assign variables to the read back temperatures and put those periodically into a .csv file, I can do all I want with that, graphs, etc. Next, I just have to decide if the likelihood of using the ISY Portal module is high enough to warrant getting both or just the Network Module alone. Thanks again.

Thanks again for the info. I understand the cost model, a bit tricky to decide the optimum path since I likely will only make use of the ISY Portal down the road a ways and that will require more investigation of whether one of the connection would give me access to my Apple TV or my BOSE house wide sound system. Possible for the former but very unlikely for the latter. After a brief read of what you pointed me to, it appears that the software for the Network Module added to the Admin Console but somehow provides software added to the ISY programs I write so ultimately, I don't have to keep software running on my computer to log data or send email notices but can grab the logged data from ISY when I launch the Console. Is that correct? And can I create such a log such that the data can ultimately be fed to some form of spreadsheet such as Excel? From the wiki, it wasn't clear to me what format the created files might take.

Thank you, ELA, for your reply and reminding me to read again your previous report. I had read it before and was very impressed with the details you followed and reported. In reading it again, I found one important statement that I had not paid sufficient attention to in my first read, that is the necessity of executing a Query after a Calibrate. This seems very odd but now I found that indeed a Query immediately after a Calibrate results in a different value reported, one that is much closer to the requested Calibrate value. The whole calibration operation seems very odd to me both because of the need for the Query and the need to repeat the Calibrate several times to get close to but not exactly to the desired value. But by executing the Query after Calibrate I was eventually able to get to within a degree of my desired value on all three MS IIs which I have mounted on a board next to each other. Over the last three days, I have performed queries 4 times were day comparing the three MS II readouts to a room thermometer I have. Two are tracking very well, exactly matching when applying a software correction based upon the final calibration offset. One, however, performs mysteriously. With many of the reads, it also reports a value within a degree of the other two, however, on some of the reads it first reports the same value as it previously reported several hours before, but on a second query command, it reports the correct new value. On one read sequence, it continued to report the value from several house before even after three consecutive reads. I am concluding that this devices if faulty and should be returned. I do have a few questions that you possibly can help answer: 1) It appears that when powering the MS II with USB power, one does not need to put the device in set mode. Another person had commented that this was necessary but I think that is only in battery mode. Is this correct? 2) Once the devices is calibrated powered by USB, can the device be powered down to be moved to a different location without recalibrating? I assume it will hold its calibration after a loss of USB power, which will be important in operation during a general power failure? 3) Some Query commands put the ISY is Busy Mode for an extended period of time during which several pop up windows appear with the warning not power to down or change configurations, but some Query commands show System Busy for only a very brief moment and then return to Ready. Is this normal? Do you know a reason why the difference? 4) I have not done any thing with the motion part of the device. I just linked the device which produced three devices in the ISY device list. The MS II unit will often flash a red light in addition to the green light. The manual states that the red light implies "Error Controlling a Device", which is odd since I have not purposely set the MS II to control anything. There is no report in the ISY Log or Error Log associated with this device. Is this a concern? Do you think this affects its temperature sensing, which is the only purpose I intend for the device? Thanks again.

Thank you, kclenden, for this new information. This option appears to be worth investigating further before I go in the Nodelink direction. The Network module looked like something I might be interested in for the future when I first read the ISY Users Guide. But can you point me to more information about the Nework module and the ISY Portal Module? I see no information about the Portal Module in the Users Guide. And it is not clear to me if these various optional modules are extra hardware, firmware or software and how much they cost.

Not a problem. As you can see from the delay in my reply, that I only work on this ISY stuff in what spare time I can find. I found this Event Viewer. From my brief look at it, it appears to only run while I have the Admin Console running, at least the start of it's log was my launching of the console. You are correct, that I don't really want to require the computer running all the time. So it looks like I either use the system log and put up with only seeing changes to my temperature sensors, or I dig more into the Nodelink and see if that might provide a better logging system. That again will be completely new territory for me to explore. Thanks.

kclenden, my little program still isn't recording changes to my state variables. I forced the change in values as you suggested; I even just changed to value via two set variable lines in the code and still nothing in the log file. I must be leaving out some step to enable logging or enable logging of my state variables.

Very good. That's the key. Only state variables and only when they change get written to the log. I guess that is covered in some document somewhere but I couldn't find it Thanks.

If I might, I'd like to add a couple of questions to this thread. 1) In the sample program, the motion sensor node was set to query but then the temperature and luminescence was copied to variables. I have my MSIIs running on USB power and all I want to measure if the temperature. I set the temperature node to query and then copied the temperature to a variable. Is there anything problematic with doing that way? 2) I'm interested in logging data over a long period of time. It was suggested to me to download the ISY Log to my computer which has the option of putting the log into an Excel file. It looks like this should work fine, except in my attempts to try this, it appears that the temperature values from the query are only recorded in the log only if the temperature has changed. I tried copying the temperature to a variable just after the query but that also did not report anything to the log. This is someone off topic but that can be excused for a newbie, I'd like know if there is any way to force the result of a query to be reported to the log or even better to report the current value of a variable to the log. It would seem important for many other types of applications to be able to log the current value of variables. Any help will be greatly appreciated. (I don't know how my status was updated to "Advanced Member" but at best I'd classify myself as "Intermediate", and that might be a push.)

I am just starting to set up the MS II as a temperature sensor and having trouble calibrating it or even getting sensible readings. I've tried two of the three I purchased with similar results. It would appear that I haven't set it up correctly. Out of the box, I removed the battery and connected the USB cable for power. I linked the unit to my ISY using the "Link a sensor" -> "Motion Sensor II". This created three devices, the temperature sensor, Motion Enabled and Tamper, which I 've read is normal. The icon to the left of these device names in the Console listing of ISY devices looks like the capital letter "N" with a ball at the end of the up going and down going lines. Since this is my first senator device, I assume this is the normal symbol for a sensor. I did not change settings in the window that pops up in response to pressing the Options button. To calibrate, pressed the set button on the MS II (I read somewhere that it needed to be in set or link mode), selected the temperature device on the Console, typed a new number into the box just to the right of the Calibrate Temperature button and then pressed that button. The response I get to these actions is varied. Ready changes to System Busy in the lower left corner of the Console window and a few windows pop up sequentially warning me not to power down or change any settings. It's clearing trying to write to the MS II. During that period, the value I typed into the box to the right of the Calibrate button changes. Most often it changes back to the value displayed as the temperature read back which is where the operation ends with no change to the temperature reading. Sometimes it changes to a different temperature but not the one I entered and then the temperature read back also changes to that value. By repeating this calibrate sequence several times, I can get the read back to get close to the number I entered, sometimes above my value, sometimes below my value. Never the same value. One attempt changed the temperature to -17.9 degrees. I've also tried this calibrate sequence without first pressing the Set button on the MS II unit, with similar results except a few times that resulted in an error message saying that ISY could not communicate with the device. As I am writing this message, I tried repeating the sequence above a few times to make sure that I am recording the correct sequence and response but the response has changed. Firstly, I now see that as soon as I enter a new value to calibrate to and press my enter key, the system goes busy. It doesn't wait for me to press the Calibrate Temperature button. I had not noticed that before. Secondly, the popup windows warning me not to change anything are not appearing. It doesn't appear that ISY is writing to the device. As I stated above, I've tried this with two of the three units i purchased with similar results. I hope someone can point to some step I've left out because this is very frustrating.