Jimini

Can I run ISY programs when my internet connection is down? I have a power grid outage but my solar system keeps my local WiFi operating. However, my isp is down. I need to run some ISY programs for house power management with grid down, but I can’t execute ISY admin console because it can’t load something. I think Java related.

Sorry, you are apparently pointing out the inadequacy of my investigation 3 years ago or the addition of more ZWave manufacturers since then. Once I decided on Insteon, I had not thought there was a need to continue watching alternate or new technologies. That is certainly no longer correct. Thanks for pointing out ZWave as a possible alternative.

I personally never tried the Leviton devices. About three years ago when I finally decided to replace my X10 system that I had been using for over 20 years at two successive homes, I looked at various forums including this one. I liked the ISY controller and it appeared that Insteon, especially the new modules with RF as well as AC-line communication was favored by what I read so I went "hole-hog" and replaced my X10 system with ISY and Insteon. It would certainly be preferred if there was a technology that was supported by more than one manufacturer. But I guess patents as well as a small market are making that difficult.

That wasn't true a short time ago. I managed to snag one from Amazon. But SmartHome and Insteon sites were sold out.

So then a USB PLM can somehow be used with my ISY 994? When your post popped up, I was reading another thread about ISY and Polisy and there was mention of "the new USB PLM". Is there some new USB PLM to replace the old 2413U? What should I be purchasing as my backup for now and replacement when ISY on Polisy is ready for prime time?

Thank you for the added information. In fact, I don't need a PLM now. But now that I just discovered that Insteon is disappearing, it seemed beneficial to at least look for a PLM spare as backup support my large number of Insteon devices. Waiting is reasonable but isn't it likely that the few USB PLMs will be gone by the time the new ISY on Polisy is available? Or do I need to search more for new threads on what to do about Insteon disappearing? Even though I first saw the issue of no more Insteon recently as now I have a new need for the added feature of the I/O Linc (the other thread I jumped into), most of the discussion I have found on this topic so far are 1-2 years old.

There appear to be a few PLM 2413U available but no 2413S. Can I replace my 2413S with a 2413U connected to my ISY 994i ZW+IR PRO?

Hello, Sorry to break in with somewhat of a tangent, but my question is related to Insteon replacements. Does any one have a replacement for the Insteon I/O Linc? I've tried several possible sources but only E-Bay seems to have some used ones. I don't need all the functions. I just need a device that will tell my ISY if a 5V supply is on or not. Thanks for any help.

Yes, I agree that each intermediate step that stores a result into a variable must fit within the precision available for that variable but it's doing something more sophisticated than just converting all floating point numbers to 32-bit binary integers by shifting the decimal point and then doing 32-bit arithmetic. For multiplication, it appears to be doing a double precision operation, i.e. 64-bit multiplication, before adjusting the result to match the specified precision of the 32-bit variable into which it will be stored. Very nice how it keeps track of the specified precision step by step.

This comment of mine is a bit late and out of order but I found this thread by searching for one related to arithmetic and/or precision. This was the only find. And I couldn't find any discussion of this in the ISY users guide. My comment regards an earlier statement that one can change the precision of integer type variables up to 8. The 8 includes the ones place, so only 7 decimal places. However, it is important to keep in mind that apparently this 8 possible digits appears to include those on both sides of the decimal point. I am trying to include a formula that squares a number of order 50 and then multiplies it by a number of order 0.005 before completing the calculation with a few more steps. I declared all the variables involved to have precision 6 (could have used 5) as I didn't want to lose the contribution of the quadratic term. Squaring the first number as the first step produced a negative result, a common symptom of twos-complement binary arithmetic. Backing the precision down to 4 and setting the constants (e.g. the number of order 0.005) to be 100 times larger, removed the negative intermediate result and then dividing the final result by 100 produced the expected final result. Changing the order to multiply by the number of order 50 by the number of order 0.005 first and then complete the square by multiplying that result by the first number of order 50 did not produce a negative result but still an incorrect one. I don't have an explanation for that but working with precession of all variables at 4 did give me the correct result with no problem with overflow. Also, thank you kclenden for the tip about using state variables and the Event Viewer for testing this. It was much easier than sending out notifications.

larrylllix, do you mean using the "Time is 1:00:00 After Last Run programxxx" in the IF clause with a Then clause to wake up the program? Sounds just like a Wait but may use different logic within ISY. Seems like UD people should be able to recommend this if it solves the problem.

So many replies, thank you all. To respond to as many as I can: I am starting to understand how the Wait 1 Hour might screw up at the clock change based upon larryllix's reply. That may be the base problem for any waits that cross a clock change. My little routine with the Wait 1 Hour, actually increments the state variable, so that part has been working for a few weeks. Just died at the clock change. It appears to me that apostolakisl's suggestion of using the ISY Time Data Node is the way to go, or at least try. Would it not be bothered by a clock change? But I need to know more about this Nodeserve. I am subscribed to the ISY Portal along the Network add-on, but beyond that, I'm lost as to how to load this ISY Time Data Node. When I pull down "Noe Servers" from my ISY Console and select Configure, I get an option for Query that seems to do nothing and a long list of numbers, which I take to be nodes, each one marked Empty. Is this the right place to go for the ISY Time Data Node? More info would be helpful. And one last reply to larryllix suggestion about graphing software inside ISY, I will have to investigate that further. Interesting to get all that inside ISY instead of sharing the work with Google Scripts. Jimini

My programs that work off time of day or sunrise/sunset, worked after the DST change without any problem. It was just the program with the Wait 1 Hour that appears to have stopped. This interplay between ISY and LAN/WAN presents interesting "gotchas". I have a set of programs to monitor the temperature of my "poor-mans" wine closet. The closet sits under a stairwell but plenty of extra insulation and extra heat mass objects and then a fan that sucks air from the house crawl space. Here on the central coast, I believe our temperatures are moderate enough to allow holding a fairly stable temperature with help from the cool air in the crawl space. ISY monitors the temperature every hour and records the data in a file in its webspace. But I decided it was a bit awkward to pull that up periodically to look at it. So I have ISY send an email to my gmail account and then I wrote a Google Script to grab the email message once an hour and put it in a Google sheet that makes pretty graphs, etc. But then I found an occasional problem where my ISP takes down our service for a while, usually after midnight, but sometime lasting for several hours. Even though my LAN is working just fine, ISY can't send an email to my Google account operating in the Ether somewhere. Not much I can do about that, except I added a test to the Google Script, that if it doesn't find an email from ISY when it should be there, it sends me its own message warning me that I'm missing data. It's also an interesting monitor of how often I'm missing internet service even when I'm not trying to use it.

I agree that DST is more damaging than helpful. I would prefer 12 months of ST but would take 12 months of either just to get rid of the switch. For one who has joined meetings both in person and by video for the past 25 years in 3 out of the 4 US time zones, two in Europe and 2 in Asia, I think it might be complicated to eliminate all time zones but having the US on one might be possible. But before either that or elimination of DST is attempted, it is complete lunacy to have some states or parts of some states not follow everyone else. I can never figure out when to call my cousin in Arizona, whether she is at the same time or not as us. But back to my issue about ISY and the time shift, seems like I should ask @apostolakisl. I'm running firmware version 5.0.15A, which is not the absolute most recent version but close to it. I've been avoiding upgrading because it's generally a hassle (not just for ISY) unless it's actually fixing something I use. The problem with this is that I won't know if it fixed this problem for another 6 months. I could live with kick starting the programs twice year as long as I happened not to be traveling when that happened. There are a few programs that I would prefer not to stop while I was away on a trip. I hope you, larryllix, don't have any "essential" programs hung because your router died.

A new problem just occurred this morning. My little routine that waits for one hour, increments a state variable and then executes another "Wait 1 hour" failed at the beginning of daylight savings time this morning. The routine correctly woke up at 1am, but failed to wake up and increment the state variable at 2am or any time after that until I kick started it again. After the kick start, it has correctly awakened in hour hour intervals. Does anyone know if it is documented that the Wait command fails when ISY changes its time twice a year?

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.