MrBill

@rcwagner Do you have Java 8 from https://www.java.com installed? or some other version? double clicking a .jnlp file an having IE open seems like Java might not be installed correctly, or the wrong version.

negative. Win11 and Java 8 from www.java.com are just like Win10 and Java 8 from www.java.com, no difference whatsoever... Been on win 11 for a long time, nothing different with admin console.

For those that don't realize the significance of the current releases area of the forum being locked down, it was done so that users can subscribe to that section of the forum.. and ONLY get release announcements and not a lot of noise following. Go here and click "follow" on the right side of that screen.

I assume that's a typo since the build portion matches: but to be clear are you using Java 8, update 361?

That's unfortunate. I'd rather get the node server fixed, so that i didn't need to worry about needing to restarting it at an odd time. My node servers are running months at a time. I have noticed Kasa quits lately but I'm using the unsupported Polyglot V2 node server. I'll be moving to eisy and Polyglot v3 sometime in the next few months, if Kasa still dies then I will spend the necessary 5 minutes to drop @Jimbo.Automates and log and note.

In addition some node servers produce a heartbeat, which is often better to detect failure. I don't have a heartbeat program set up for Kasa but since it's a @Jimbo.Automates node server I'd bet that it sends a heartbeat. Here's an example heartbeat program for the notification node server. (In this case, the NR doesn't use the notification node server to send the notification.) hb.controller - [ID 0028][Parent 016D] If 'Node Servers / Notification Controller' is switched On Or 'Node Servers / Notification Controller' is switched Off Then Wait 11 minutes Repeat Every 30 minutes Resource 'ISYnotification.NotificationNS.Missed Heartbeat' Else - No Actions - (To add one, press 'Action')

I have a strong opinion that I feel the need to re-state. It's important not to cause reboots, or push changes that may break a local installation. It's my understanding that even after the attention focus on last weeks unannounced portal induced eisy reboot, there was another one of those this morning during portal maintenance. In a perfect world everyone's ISY/IoX will reboot and chug onward. But what if they don't? What if update causes 1000's of ISY's not to restart correctly? What about a new ISY program that the owner hasn't taken into account startup conditions? What if the owner is on vacation in Timbuktu, or sailing around the world with no wifi? or on the beach margarita in hand? Automatons that I have for convenience when I'm home are nice, but I RELY on automation when I'm out of town.

there's a thread about AVRemote 2.0.5

Reverse Engineering is simply starting with the results and working backwards to find out how it works. To what level that is taken is subjective. In the case of the reverse engineering it's just of the API commands themselves, it's not even recreating the server side of MyQ. it's simply using tools to understand what the app on the phone is saying to the server to make X happen or check the status of Y. No on is reverse engineering the servers or the product, yes they are reverse engineering the API. Unfortunately MyQ doesn't want to share their API because supporting polling from another half million clients would cost real dollars by increasing traffic. It's unclear why myQ doesn't push messages to clients rather that requiring polling. If published, they also need to monitor who's miss using the API... with the current stance anyone not using the official app (client) is misusing the connection. ----- The red and white wire from MyQ operators to wall controls is carrying data. The operators still are designed to operate with that pair being connected to a single momentary push button, however it doesn't work well with other wall controls or other accessories using the same wire to wire a relay to mimic a push button when also using most wall controls. This MyQ button can be easily modified by soldering leads on to the button. specifically LM883 converts a push button to a data signal rather than shorting the two leads as the button is pushed. Someone sells a modified version of 883 with the leads already soldered on to add a relay, but I can't find the link to the modified version. Here's a youtube to help understand.

i have something similar however it only delays programs at startup, after 10 min it will run programs. There's one program that's allowed to always run, it waits 10 minutes and advances startup unlocking the rest of the programs and running any that need to run at startup.

have you used admin/admin to login? those are the default credentials, once they are accpet you can change them under File > Set UserId and Password. Note: only Admin can be changed, user 1 - 9 have never actually been enabled even tho they show in that menu.

Then don't update automatically. UDI should then deprecate old versions, that is no support for 2 versions ago and beyond. If support is requested on an older version the answer should be please update and retest.

Have you restarted the admin console? If not that should be first thing to try. Also double check the UUID that you entered into the portal. If that fails you might try restarting eisy.

I'm very happy to see this poll. After recent events I've come to some conclusions that I personally am very against forced updates, but why not let the user decide the level of automatic that they want. Perhaps with options like "Auto", everything happens (hopefully) automatically, "Download only" - download but don't install, "none" no auto updates. Perhaps a check box, for "no updates that require reboot" Personally, I don't want an update to take place, if I'm out of town. Either it could break and I wouldn't know right away, or I could end up doing remote work when I need to be doing something else. For time management aspects I would prefer to control when an update is installed, example I also run Home Assistant, and for the major update at the beginning of the month I choose to wait a few days and load it on a day that I can afford to spend a few uninterrupted hours if something goes south. I also make it a habit not to make too many changes to my ISY in the weeks before I leave town. I'd also suggest that there should be a method to roll back a node server update to the previous version. I've been watching the discussion in this thread and I think it points out the obvious, something was wrong with an update, but the developer doesn't have any time until "next week", or maybe some other circumstance could arise. Should the user need to wait if the prior version worked? It shouldn't be hard to implement, create a last_version.tar of the node server directory, so it can be unpacked and used if necessary. I've also got to point out the forced reboot of yesterday of eisy's running PG3x and IoX 5.5.9. That didn't go well for some people. While early on in the thread @bmercier mentions it should only amount to a few second, but it takes much longer for IoX to get up and running and happy again after a reboot. Another point on reboots, is I write complicated ISY programs, and sometimes at reboot something comes up that I didn't think about-- most of the time I try to remember to take startup into account and create a program to run on startup if any re-initialization needs to occur... but sometimes I forget, or sometimes forget a possible condition. While I personally don't want updates to occur unattended some people may be more interested in that occurring, so I vote for options.

Additionally it's not actually bad memory, its just an admin console bug caused by a change of maximum size that has never been corrected. Unfortunately there are MANY bad UX pain points in the admin console that never get fixed, i gave a few examples in another thread yesterday... this is one more...

My understanding is that the portal had to be modified to make way for portal access for PG3. The problem however is that an unexpected reboot was forced on all PG3X (limited to eisy at this point). The circumstances were unusual, and I'm not certain how the issue could have been mitigated, but an unexpected reboot when the customer may not be available to fix any issues that come up is not excusable. I've generally worked out all the issues that I once had on reboot, but I'd still be uneasy about an unattended reboot.

And I'll add that UD never discusses release time frames. The organization is small, priorities can change rapidly to promise a release is virtually impossible. We actually don't know that 5.6.0 will be the number of the next release. While the version numbering system of UD Mobile seems to be incrementing the middle digit after the minor release reaches .9 that's not the way firmware versions have followed in the past... i.e. the next release may be 5.5.10

is it an eisy? if so, is it connected to portal? If so, the cause of the reboot this morning is known and unrelated to this thread.

There are many bad UX's issues with the admin console. Unfortunately fixing those is virtually never a priority to UD.... One that I complain about frequently is: How does this screen work? If I change any of these 5 values, do they change instantly after the dropdown is adjusted, or do I need to press "write changes" perhaps? or something else? The correct answer is "Or something else" that is not remotely intuitive to the user... Change a drop down, then you must press the corresponding button that looks more like just a label to the LEFT of the drop-down. That answer is virtually impossible to guess. Another good question.... why are Integer variables [still] called Integer variables? After all they can have a decimal [now].

Fri 2023/03/24 07:21:49 AM 0 -5 Start IoX started at 07:21:49 AM.... sure seems like it rebooted to me...

Perhaps your eisy went through a random reboot, someone I was chatting with indicated they had one this morning with eisy... unclear what's causing those. Unfortunately the platform is still going thru some growing pains.

I don't think that portal functionality has been yet enabled. I can't seem to find the reference this morning but somewhere in the past few months I've seen seen discussion that work is being done to make node server accessible through the portal, but that hasn't actually happened yet. Lack of the ability to access node servers through portal, even just to restart them, has been a missing feature since Polisy was invented. I think we are close to resolution on the that issue, but we aren't there yet.

@KConover If you haven't yet discovered it.... Scene's appear AFTER devices in the "Your Devices" list. Scenes are preceded by the icon instead of the device icon

keep an eye out... i bet they return under some condition. I doubted it was the GFCI from the start which is why I suggested something downstream of it.

I'm curious if it's the actual GFCI causing the interference, or a device wired downstream of the GFCI off the line side terminals. As far as leaving it off or on, I'd choose off if you can do without it until you pick up a replacement. Less interference of signals/noise is always better. I get where you're coming from with the power interruptions, it's a pain to reset clocks and whatever else is different because the power was off. That is about the fastest method to track down the offender tho.