Jump to content

oskrypuch

Members
  • Posts

    756
  • Joined

  • Last visited

Everything posted by oskrypuch

  1. Some Polisys will brick if you try to do some of the recent updates. I have been sitting on the sidelines with 5.4.4 and my external USB ZWave stick. It is working solidly, and if it is not broken ... I understand that support can work around that issue, especially if you catch it ahead of time, that is catch the susceptibility. Will probably eventually do that. * Orest
  2. Nothing wrong with belt + suspenders. * Orest
  3. 'Walk Ins / TGOC Walk-Ins / TGOC Freezer' Temperature is 0.0°F Or 'Walk Ins / TGOC Walk-Ins / TGOC Freezer' Temperature is not 0.0°F That is clever logic to check for a change, any change, although it does rely on continued execution itself. As you say, adding time triggers would make it more bullet proof. I'm going to use it, somewhere. * Orest
  4. Yes, I have a monitor program that checks the loaded temp & baro pressures, and if it is not changing, it alerts me. Likely something is amuck. That is how I was alerted to this instance. But that I have to check over a longer period to be sure, so the competing variable approach is also faster, and a step "higher" in the logic. Many such background processes do have some sort of logic inconsistency generated, if they fail, so that can be easily monitored and acted on, and I do employ that approach. But, I also have a number of programs that aren't amenable to something similar to checking the temp & baro, or other resultant logic. So, the competing variable set/reset works perfectly. * Orest
  5. You are late to the party. Check out the other threads. You'll need an update. * Orest
  6. load poly data TP If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 5 minutes [blah, blah, blah] $sm_poly_TP = $xc_true This is the main program that needs to cycle, that was halted by the DST change (perhaps). It loads up a whole bunch of real time weather data into variables. Added the sm_poly_TP integer variable line. monitor Poly TP If Time is 3:00:00AM Or Time is 9:00:00AM Or Time is 3:00:00PM Or Time is 9:00:00PM Then $sm_poly_TP = $xc_false Wait 35 minutes Run Program 'monitor Poly TP.restart' (If) Every six hours this "service monitor" program resets the same variable, and waits for a Repeat interval + 30min (35 min) to see if it has been set again. monitor Poly TP.restart [disabled] If $sm_poly_TP is $xc_false Then Run Program 'load poly data TP' (If) Send Notification to 'xxxxxxxxx - email' content '$my_error' If not, then the restart and email notice is triggered. Although the integer variable can't trigger this program in any case, the program is disabled for good measure. The timing of the set/reset and recheck is dictated by the repeat interval, and how time critical the data is. Simple, solid. Automated, and logs the issue. Used the same format for the others. Thanks again for the idea. I'm looking forward to the next DST changeover! 😃 * Orest
  7. OK, implemented, with an error notice and auto-restart, for a bunch of those background threads. Thanks. * Orest
  8. And of course, besides sending a notice, you could have it re-initiate the repeating program that has apparently stopped. Need to be a little careful to not set up an infinite loop. * Orest
  9. Yes, that would do it! Competing programs, when the other wins, you have an error state. A bit of delay, and an indirect check, but it works. Just need to set the timer triggers intelligently. * Orest
  10. I have a number of Repeat Every xxx type logic programs that do a variety of "background" things, for example pull the weather state. On Sunday morning most of these programs had stopped repeating. I noticed this a day later (today), I have a routine (time of day triggered) that sniffs the temp & baro pressure, and if there is no change over two 12 hour periods, then it assumes an error state and lets me know. I can't be certain that the DST roll over was the culprit, but the circumstantial evidence (and the logic to it) is suggestive. I'm running a relatively stable v5.4.4 on a Polisy. IAC, it is an old version, and probably it is no longer supported. I'm just looking for a workaround for future issues, whether DST related or not. I looked before, but couldn't find a way to do it, is there a way to sense if a program is currently executing? For example, when the Details list would show Activity: Running 'Then', is there a way to pull that state into a program and act on it? I know you can check a program's last execution result (Then or Else), in fact we all used that many years ago before we had variables, to provide a variable-like True/False capability, but that doesn't do it. I need to know if the Repeat loop is actually executing, rather then how the logic finished. Setting/resetting a variable in the loop as a semaphore doesn't work, because I'm trying to determine if there was an errant stop to the program. To get around this issue I could just execute a (re)initiation of all the Repeat Every xxx programs once a day. That would work, but seems programmatically untidy. Thoughts? * Orest
  11. An app on a portable device is fine for little tasks here and there, simple stuff, and I do find it useful. But it doesn't come close to providing the kind of capability that a full programming IDE does. Now, the admin interface for UD also falls short somewhat, but it is miles ahead of what a portable app could do. I sure hope we don't lose that. A lot of folks speak ill of java, but there is no reason that a well written java program can't be just as good and indistinguishable from one with tight compiled code. Many programming frameworks are written entirely in java. If you don't like java, then python, or C, or whatever, please. * Orest
  12. So, that is where the update process hangs, and you have to power cycle it to finish it? How long do you wait? * Orest
  13. Ordered. Hopefully I don't need it too long! 😀 * Orest
  14. Got it. yes, the original is out of stock. The Amazon product looks to be equivalent. Also this guy ... https://www.amazon.com/ezOutlet5-Internet-WiFi-Reboot-Switch/dp/B0861NX6H2/ref=sr_1_2 That one has a REST interface as well. Thanks much for the leads! * Orest
  15. I will wait to update, and I'll submit the ticket when I'm ready to go. * Orest
  16. Is that a PG2 service, or has it been moved over? Is it still supported? * Orest
  17. That is what I understand. I have had three service calls now, with improvement for a bit after each. They detected an issue at the CO, then with a connector outside the house. I expect that the cable (somewhere) is just not up to 3.1 connectivity. I had nil issues with my 3.0 modem -- but of course they will not enable it now, I should have never "upgraded"! So, until this gets remedied (perhaps switching to fiber, which is on our street), I need something to reawaken the error overwhelmed modem from time to time. I do have a quick keypad button set to do this, and when we go away I have it run on spec every six hours. It would be more slick if the connectivity outage were detected somehow, and the power cycle triggered. I would be even MORE slick to have a properly working internet connection! (sigh) * Orest
  18. Having issues with our internet connection, a real pain to try to sort out with the provider, but I digress. (docsis 3.1 modem develops a high level of uncorrecteds after a while, and then ceases to pass packets) I have set up a dual-band insteon switch that I can turn OFF, and hold OFF for ten minutes, cold power cycling the modem. This seems to clear the loss of internet for a while. My question is, is there an easy way for Polisy/IoX to detect that the internet has gone down, and trigger a program? I have a couple of weather nodes on PG3, but these still indicate a connection as they are running locally. Clearly I could detect unchanging values, but that is a bit dodgy and not 100%. Any other clever way, perhaps interrogating some system variable? * Orest
  19. Thanks, polisy.local has never resolved to my local IP for the polisy, but using the actual policy IP doesn't work either. Yes, that is why I need to run a ticket. But, no I was asking about the 5.7.0 "disabled programs" fix. I am currently running 5.4.x, and PG 3.0, mainly a large Insteon system but do use the Z-Wave dongle (not the matter board) for a few Z-Wave items. I have been reluctant to upgrade until we get an update that is running smoothly for a while -- as all seems to be working for me well as is. Moving to 5.7.x, and then PG 3.0x, and then possibly shifting to the matter board for my Z-Wave, are the dominos that need to sequence at some point. So, that is where I am. * Orest
  20. It will be nice to see confirmations "out in the field" for the fix. * Orest
  21. After the usual certificate dialog and a log in prompt, I get ... ./FILES/WEB/sysconfig.txt not found So, am I set up for a 10% brick? If I want to upgrade, I will need to run a ticket? Hopefully there is a way to do it at some point! * Orest
  22. I kind of thought so. Was looking at doing so, but holding off for the moment given the current ".0" issues. * Orest""
  23. So, I am on Polisy, running 5.4.4, and using a Z-Wave dongle (no matter board) Any issues with upgrading to PG3x with this combo? Only use PG3 nodes at present. * Orest
  24. Is the last 5.6.x version still available to upgrade to? I have been on the fence for a while, running 5.4.x. Would prefer to grab the "last" release in a series. * Orest
×
×
  • Create New...