Everything posted by oskrypuch
-
Accessing Admin UI through portal/cloud
Success! Thanks. * Orest
-
Accessing Admin UI through portal/cloud
The ISY Web access will bring up the lists of devices, and so on, and the UI app works fine, so something is working. So I ferreted out the my.isy.io ..../desc url from the ISY information dialog. Put that in the ISY finder, it populated with the "cloud" address entry, got the usual Admin UI credential request, put that in, but it failed. Yes, I doubled checked it. I then (after 3 tries) got just a blank Admin UI. Wonder what I'm doing wrong? Do I use the portal login instead? Is there some setting needed? * Orest
-
PG3x migration
I've read all I can on the wiki and the forums. I have an older Polisy running v13.0 (5.4.4 / PG3), so updates are not safely available with the Admin UI UPDATE button. Getting updated means reflashing the mSATA card (I'm familiar, already done once), but on a working Polisy that can lead to a number of challenges. Specifically here, if someone could answer about the PG3 -> PG3x issue. Should I update to PG3x now, it does indicate to not do that unless you updated your device, which I can't do directly, so assuming I shouldn't. Backing up PG3, can that be restored to the PG3 running on the new flashed mSATA, which will have 5.8.0 and the last available PG3, or should I then update the PG3 -> PG3x first, before trying a restore? Thanks. * Orest
-
The big update (procedure)
It was my plan to NOT migrate to the new ZWave board at present. Just wanted to get my Zooz stick working again, when I update PG/x and IOX. Given that I'm on an old Polisy OS (v13.0), the easy upgrade procedure is not available, so have to wipe the mSATA card clean, restart/run the new OS, and then restore. A pain, but it is what it is. So, my questions revolve around the Zooz ZWave dongle, and PG3/x. Restoring the IOX itself is dead simple, and not an issue. * Orest
-
The big update (procedure)
-
The big update (procedure)
I don't believe there is any way to backup ZWave, when using the original Zooz stick. * Orest
-
The big update (procedure)
I updated an old (new out of the box) Polisy with the image reflash. All good, and easy enough. But now need to do the same with another working Polisy (v13.0), running 5.4.4 and PG3 (with three weather nodes), with a serial PLM, and a large complicated Insteon network. It also has a plug in USB ZWave Zooz Stick 700 running a small number of ZWave. Just to be sure, the correct steps would be: 0) Ensure good backups of IOX and PG3. I understand there are no backups of the Zooz stick, but the information should remain safe on the stick (?) for transfer. Plan 1) Dissasemble and reflash mSATA card as per the previous UDI directions, and as I just completed on the other Polisy. 2) Start the Polisy up, let it boot, address it and select upgrade packages, reboot. 3) Enable PG3x. 3) Restore backup of IOX. 4) Restore backup of PG3. I believe that PG3 will now restore to PG3x, or should I leave the enabling of PG3x until AFTER the PG3 import? 5) Plug Zooz stick back in. Questions Will I also need to configure the PG nodes in the admin interface, or will these just come up? Will the ZWave setup carry over, including having the devices properly keyed to the programming code? Any other concerns or suggestions? Thanks. * Orest
-
Brand new Polisy, don't want to brick it
Will do. * Orest
-
Brand new Polisy, don't want to brick it
I did have a quick peek inside, there isn't an obvious version number (vs. part number) stamped on the SATA card, the unit does have a TPM daughterboard. Unit purchased May 2022. * Orest
-
Brand new Polisy, don't want to brick it
I have been running a Polisy for years, and many ISYs before that. Have a large Insteon/ZWave dongle setup at home (Polisy v5.4x), and a simple Insteon only setup at my cottage (older ISY994 v4.90). I had bought a new Polisy as a backup, and for potentially updating my cottage, yes about one month before the Eisy was announced! That said, it is still sitting in its box, together with a brand new serial PLM. I'd like to now use it to update my cottage setup, and add that to my portal and the UD mobile app for remote access, already have my home setup there. My biggest concern is that I may brick my brand new Polisy during initial setup, when it tries to update itself (as per the Wiki docs). Is there a way to avoid this, or at least check to make sure it is not susceptible? Obviously I can't REST in or SSH in, until it is booted. I know that my current Polisy is susceptible, as I can't get a system version with the REST command. That has stopped me from updating it, for now, but that is another story. I will eventually move to an Eisy at home. I understand that going v4 -> v5 might farkle up the coding, went through that for my home setup some time ago, but my cottage setup is simple enough that recreating it from a program text dump would take little time. * Orest
-
Can't log into Polisy -- I think I broke it
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
-
Repeat Every xxx -- programs stopped (DST roll over)
Nothing wrong with belt + suspenders. * Orest
-
Repeat Every xxx -- programs stopped (DST roll over)
'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
-
Repeat Every xxx -- programs stopped (DST roll over)
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
-
Yikes! All my programs were disabled...all of them
You are late to the party. Check out the other threads. You'll need an update. * Orest
-
Repeat Every xxx -- programs stopped (DST roll over)
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
-
Repeat Every xxx -- programs stopped (DST roll over)
OK, implemented, with an error notice and auto-restart, for a bunch of those background threads. Thanks. * Orest
-
Repeat Every xxx -- programs stopped (DST roll over)
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
-
Repeat Every xxx -- programs stopped (DST roll over)
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
-
Repeat Every xxx -- programs stopped (DST roll over)
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
-
cannot install the isy finder
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
-
Support Thread for IoX 5.7.0
So, that is where the update process hangs, and you have to power cycle it to finish it? How long do you wait? * Orest
-
Detect loss of internet (programming question)
Ordered. Hopefully I don't need it too long! 😀 * Orest
-
Detect loss of internet (programming question)
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
-
Support Thread for IoX 5.7.0
I will wait to update, and I'll submit the ticket when I'm ready to go. * Orest