oskrypuch

I may be in a similar situation soon. IIRC, the EISY comes set up to only work with the new USB board. BUT, that is a software setting, it can be reset to use the old 700 series dongle. You may have to create a ticket. * Orest

Subject & body have text. Simple text. * Orest

So, this is using the "default" email server in IOX. Messages are just short text compositions. Today I noticed that no email notifications were being sent from one Polisy machine (v5.4.4), and trying a test message gives ... \\ BUT, another Polisy machine that about up to date (v5.8.0), email notifications are still coming. But (again), the other odd thing that I have noticed in the last month or so, is that I would get duplicate notice mails, that were sometimes months old. The message text time stamp was old, but the email time stamp was current. It is like it was resent. * Orest

I have just sat on it, for now. * Orest

@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

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

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

Anyone? Hate to waste a ticket slot, if someone here knows. * Orest

Best way might be to add a comment ... [FIXED] ... or something like that. * Orest

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

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

@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

Yep, see it in 5.8.0 (on one Polisy), but not on 5.4.4 (my other Polisy). * Orest

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

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