Everything posted by oskrypuch
-
How to set an event to recurr annually without having to reset the calendar each time a new year rolls around?
@CoLong Just set up some variables, using the system time variables. Roll them over just after midnight. The sky is the limit, add new ones as you need to. I use these in a number of programs in my setup. So, for example, testing for ... $cal_month_of_year = 3 and $cal_day_of_month = 16 ... would give you March 16th. * Orest
-
Late to the game but finally ordered the eisy, but I am really going to miss web interface.
UD mobile is fabulous for what it provides, and I use it all the time. But it can't sub for a full UI for initial programming and maintenance, except for the simplest of setups. If you could only use the mobile interface (with all its hardware related limitations), that might be the end of the platform! * Orest
-
ZMatter board, "factory reset"?
This was just a hypothetical. But from what you are suggesting, data/structure is stored on the ZMatter card, that was what I was wondering. So, is there a factory reset for the ZMatter card? No docs with the card, and the wiki doesn't talk about it. There is a reset command in the AC for the ZWave Zooz 700 USB controller, is there something similar for the ZMatter? * Orest
-
ZMatter board, "factory reset"?
Anyone? Hate to waste a ticket slot, if someone here knows. * Orest
-
Prepping for eisy upgrade
Best way might be to add a comment ... [FIXED] ... or something like that. * Orest
-
new pg3x migration, won't login (service not available)
This unit was new out of the box (but on the shelf for bit), and I already reflashed the image with Michel's help, updates fully done (or so I thought), was running 5.8.0, and even PG3 -> PG3x enabled -- although that never took for whatever reason, hence this thread. I was initially having trouble with accessing it, with the included PS, and substituted a new 12v 3A PS, and that got it going. That was with Michel's suggestion as well. I even tried the old PS, and it stopped booting, so it seemed pretty consistent. Yes, I never got the popups for the updates this time (can't remember if I did initially), but at the last instance I did get a popup saying that a new PG3x was available when I started up the AC, so something has changed. I declined the update for the moment. Perhaps it had got into some kind of intermittent state, as you say, and the multiple power cycles finally got it going. Perhaps I didn't wait long enough for the update, but it was at least a few minutes. I have not tried another three pushes of the m.s. to see if it will reboot. But, it is running now and working, so I'm a bit hesitant to do anything! 😃 It is also at my vacation property, I'm not up there at the moment, so can't do any further poking around. If it still continues to misbehave, I will open a ticket. Thanks much for your thoughts and suggestions. * Orest
-
ZMatter board, "factory reset"?
I understand that there are migration procedures and all kinds of pitfalls when switching IoX devices, and I have been poring over them as I have some work ahead of me .... But, just speaking of the ZMatter hardware, if you move a ZMatter board to a different Polisy/Eisy in the process of migration (or replacing a dead one, or just moving components around), is there some kind of factory reset procedure required on the Matter board itself, or is it just a passive sender/receiver, and all the smarts and settings data is stored in the Eisy/Polisy OS? For example, let us say I had two Polisys running, one operational and one a test box, both with a ZMatter board. Let us suppose one ZMatter board dies (a bit fanciful, but just a thought experiment), can you just physically swap in the other ZMatter board and keep going, or do you need to do the whole migration procedure? I understand that the old Zooz USB 700 stick does need to be cleared one way or another. * Orest
-
new pg3x migration, won't login (service not available)
@Geddy, well mixed results. As suggested ... Commanded an update from the AC. Although the cursor showed non-responsiveness for a bit over the AC, nothing happened. No shutdown, no reboot. Then I tried three pushes of the multi-function, nothing at all happened, and the Polisy continued normal ops. Tried it once more, again no operational change. Finally I tried a power cycle. Of course that closed the Polisy down, but then it became non-responsive. No network connection on attempted restart. I had removed the outer cover, so I could accurately contact the mini-switch. Waited a bit, then tried three pokes of the m-s again. Nothing. So, last thing to try, pulled the power, and waited a bit, then repowered. The unit would not resume operation. I had removed the outer cover, so was familiar with the expected flashes on the mobo. They were not proceeding. I was fearing the thing was bricked. Tried another power cycle, again nothing. OK, one more time, this time I got a single beep almost immediately on power up, but unit remained non-responsive. OK, one last time, did yet another power cycle. This time, it booted normally, I immediately recognized the "normal" power cycle by the mobo LEDs. Finally, it was running, and does appear that PG3x is now accessible as well. BUT, just wondering, is this to be expected as a normal kind of miasma for a simple update on the Polisy? Really makes you think twice about updating! * Orest
-
Run at Startup didn't run after time change
Yep, see it in 5.8.0 (on one Polisy), but not on 5.4.4 (my other Polisy). * Orest
-
Repeat Every xxx -- programs stopped (DST roll over) - continued ...
Well, (now) my service monitors will catch some of this, and the rest can be remedied by a forced reboot at 3:01AM when DST changes one way or the other. But, my observation is that this has only started recently, as I moved from 994 to Polisy, and through the firmwares to 5.4.4 on one, and 5.8.0 on the other. So, at some time in the past the system seemed more tolerant around the DST changes. Sure, my programming has changed in that time, but not dramatically. But, as I don't have better data than that (it is a hard thing to notice before you know it is going to happen), that observation is not going to be much help I expect. * Orest
-
Repeat Every xxx -- programs stopped (DST roll over) - continued ...
Well, it is confirmed. Looping programs such as this are halted with a DST roll over, either one way or the other. Also, many time referencing programs will not be executed until the next midnight or later. I have some service monitor programs that now look for any stopped looping programs, and force a restart, so a kind of workaround. One can also force a system reboot, just after a DST roll over, but that is kludgy. My question, is this bug logged/replicated by UD, and slated to be fixed at some point? Thanks. * Orest
-
Moving Zooz ZWave stick (all 700 series)
Given that I have only about 15 Z-Wave nodes, I may just bite the bullet, and grab a new Matter board, and do a complete manual rebuild. It seems the 700 stick -> Matter board migration process can be finicky. And, I can obviously carry the board forward once/when I move to an Eisy in the future. * Orest
-
Moving Zooz ZWave stick (all 700 series)
Anyone? I may be the last guy using one of these, I know! 😀 * Orest
-
Run at Startup didn't run after time change
How do you add that action? I only see Electricity Demand Price (or some such) under System. Perhaps this is a new option, since 5.4.4? * Orest
-
Old System Upgrade Guidance
The problem with powerstrips is only if they have "surge suppressors" in them. These are just capacitors that force voltage spikes to ground. As the power line signals from Insteon are just that, mini-spikes, that can reduce performance. It won't affect the RF side of course. The irony is that the surge suppressor capacitors eventually give up the ghost, and then the setup make actually magnify the effect of power line surges. In my view, unless properly hardy and heavy duty (like commercial boxes), these are not a good idea. So, just look for the very cheapest power strips, or get the ones made more for the home workshop environment, both usually don't have this circuitry. Or if you are handy, make your own. * Orest
-
new pg3x migration, won't login (service not available)
This is a brand new out of the box Polisy (sat for a bit), that I reflashed/updated with @Michel Kohanim directions. Then I restored some programming from a 994 that is being taken out of service, this is a secondary unit at my vacation property. Then, followed that with the PG3 to PG3x enabling. I don't have any nodes on this unit. This is all in the last week. @Geddy Will take the steps suggested, next time I'm up there, should be within the week. Thanks. * Orest
-
new pg3x migration, won't login (service not available)
Did just reboot the Polisy, due to the time shift bug, and also had a power cycle when I was restructuring some of the cabling, both this weekend. Can give it another try, but not too optimistic. Is there a way to force a restart of that service, by SSHing in? This is a new migration, I have never accessed the PG3 or PG3x service on this Polisy. * Orest
-
new pg3x migration, won't login (service not available)
Yes, I have PG 3x in the top corner of the log in screen. Using the AC password (not my old PG password), I get the following .. What am I doing wrong? * Orest
-
Sunrise off 1 hour this morning
I seem to recall that you had to do something special to update to the 5.8.0 "refresh". I have ... Is that the latest? * Orest
-
Sunrise off 1 hour this morning
Did you update something??? * Orest
-
Sunrise off 1 hour this morning
These issues occur on a Polisy as well, but ONLY if the firmware is up to date. I have one Polisy running 5.8.0 (with these issues), and one at 5.4.4 with none. * Orest
-
All Programs Disabled
It seems that the time change can kill looping programs, I saw that last time and added some keep alive checking. Sure enough it kicked in early this morning. This is 5.8.0 with a Polisy. Don't know if that is a factor in your case. * Orest
-
Change Device list color?
You can only change the background, I usually set Desert, a kind of mid-brown. (under Themes) That helps, but it doesn't persist long, and has to be reset. * Orest
-
PG3x migration
I have been told by @Michel Kohanim, that the optimal sequence is to enable PG3x on the reflashed Polisy, and only then to restore the old PG3 nodes. * Orest
-
Moving Zooz ZWave stick (all 700 series)
I need to update a 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. There a number of challenges, as the BIOS does have to be reflashed to factory state, the UPDATE button has a good chance of bricking it. I'm wondering specifically about the Zooz card, and my ZWave (all 700) setup. Once the Polisy is reflashed and IOX restored, do I just plug that same Zooz USB stick back in, and it should just work? Or is the setup going to be all farkled, and I will have to start over? There is no backup available for the Zooz stick, but I'm wondering if it is needed, as all the definitions I believe reside on the stick itself. * Orest