MrBill

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.

Something is generating stray noise that looks like X10 traffic to the PLM. Interesting that its Status request, house code J because status request in binary is 1 1 1 1 and house code J is binary 1 1 1 1 the start frame however is 1 1 1 0 and the final bit is 0 when the frame is a unit code and 1 when it's a command code... so if I remember the whole frame is start code, house code, function code, final bit or in this case 1 1 1 0 - 1 1 1 1 - 1 1 1 1 - 1 (dashes added for clarity) And it appears to be repeating this "frame" with great regularity. It might be an older insteon device (early insteon was capable of having an X10 address) that has gone rogue, Or it might be something else. To find it use process of elimination. I tend to do this quickly by turning off half the breakers, then if not found the other half, once we know which half has it (without turning off the PLM/ISY circuit) then i turn off half of that half and keep working with halves until i have it down to 1 breaker.... once you know which breaker it's on then search that circuit.

As @DennisC mentions upgrade to the latest version, but since this is posted in the ISY994 section of the forum there are a few things to bring to @kurelgyer's attention. If upgrading from V4 to V5, you should read the directions and then we should discuss that further before you actually do it, there's a few points that are important and a caveat or two.... If you're already on v5 there are two possible endpoints for you. If you don't have Z-wave, or have a 500 series z-wave board, then upgrade to v5.3.4. If you have a 300 series z-wave board, you can't go past v5.0.16C. It should also be noted that ISY994 is at end-of-life and no longer receiving non-critical updates. To upgrade to eisy you need to be on the latest v5 firmware before migration.

Before you can install the launcher tho, let's make sure you have to correct version of Java installed. Many people think they need to search google or oracle.com for the "latest version of java" which is wrong because like tomatoes in ketchup there are at least 57 varieties of java. Download and install Java 8 from https://www.java.com (if you've already installed a different Java go uninstall it first). Java 8 is the supported Java for UD's admin console. Other varieties of Java may work but probably not "out of the box", meaning you have to know how to configure it to work the way Java 8 works as soon as it's installed. With Java a bigger number is not better, its a different variety... you need Java 8.

Correct that's all you should need to migrate. I have an eisy but haven't yet migrated. I was going to in early January but ended up waiting for various reasons, now I just need to find the time.

No, as mentioned above download Java 8 from https://www.java.com , Also be sure to uninstall the SE SDK first...