MrBill

There is a thread that I don't seem to have bookmarked, where someone uses a program to generate a heartbeat that is sent out via a Network Resource. The Network Resource points back to a state variable in the same ISY through a portal API URL. If the updates stop occurring, a wait in a different program times out, which means the connection to the portal has been interrupted. The internet connection is then power cycled via Insteon. Detection is missed you'd likely want to continue power cycles a few times per hour until the heartbeat is detected again. If no one links the thread I'll try to find it later, or I could just recreate sample programs.

Reading the post of mine that he quoted when asking the question, he's asking about Home Assistant because that's what I was talking about.

Home Assistant is actually another controller (open source project) that runs on several hardware platforms, its one of the largest and most active open source projects on github. In my case I use a Raspberry Pi 4 4GB. It can also be run on other hardware and even in containers (If you go this route just keep in mind you want a hardware platform that allow 'Supervisor", but that's jumping way to far ahead.) Home Assistant has 1858 built in integrations, one of which happens to be the Universal Devices ISY994. In the beginning you'll find this make Home Assistant (HA) an excellent Front End user interface for your ISY. The deeper you dig into it tho, it will become so much more. It way more than just a replacement for mobilinc, Agave or eKeypad. You'll find things you didn't know you wanted to integrate are now integratable. But on the topic of replacing the apps listed above, the dashboards I've created are the first where things are places on the screen in a logical order for our house. It's the first "remote" that is wife approved. There is also a dedicated sub-forum here on our forum. Edit to add: the Universal Devices integration hasn't yet been tested on ISY on Polisy, but I imagine that the code owners will provide tweaks if needed, it should likely work without because the ISY API seems to be the same for both hardware platforms.

For one thing, anytime $State_X is 0, Else will run. If you're seeding $State_X as -5 expecting the Else to run that won't happen the only time else will run is when $State_X = 0. There really is no way to make a single program that will count up if the number is negative and count down if it's positive. There are several methods with 2 programs, I'd stick to the first two since they are simple. A more economical method is: If $State_X > 0 then wait 1 sec $State_X =- 1 and If $State_X < 0 then wait 1 sec $State_X =+ 1 The difference is that each time $State_X changes using your method both the 'repeat' condition and the 'if' condition are reevaluate. Since the If is re-evaluated anytime a state variable changes value no repeat is needed. Watch out how many programs like that you have running, they eat processing time. State Variables are nice but they do have more overhead than an integer variable. Keep in mind that both programs are running when $State_X has any value other than 0, while positive the count down program is running Then and the Count Up Program is also running the empty Else clause with every change of $State_X What's the over all goal? why are you wanting to count a signal variable up or down if it's not zero? Edit: just noticed this is posted in the ISY on Polisy section, if you're really running on Polisy hardware the "don't have too many of these" warning is likely not important. Polisy hardware is much faster than the original 994 hardware. Many would make for an interesting hardware load test tho...

Me too, I don't have nearly as many NR's as you do, but I have a lot. I finally realized that Excel was amazing for creating concatenated strings to make many very similar but different NR's.

I was finally able to track down the Wiki edit where the words "(Does not work in network resources)" were added to the email substitutions wiki page. Those words were actually added December 12th 2015, by none other than MWareman ??

The version 4 branch is the only place you get prompts to update. That wasn't a part of V5 initially because everything was alpha, then beta... A year ago V5 had its first and only Official release. It's been posted by UDI that any version they want to have go through the Z-wave certification process costs them around $10K each. As such there is one officially certified version, after it are several more "test builds" but unlike early beta's like 5.0.14 these last few test builds after the official v5 release just have a few bugs quashed and are very stable releases. In version 5, the user must watch the forum for new versions and update manually accordingly. I wish that UDI would bring back the update flag in the UI in version 5, but for the time being it's been posted that they can't because of the z-wave certification process. Only venturing into "ISY running on Polisy" hardware are there experimental alpha/beta releases. Again I completely support letting old threads die, any thread that still has outstanding issues will be current and NOT get closed, only those that have died because they haven't been important for months will get closed... and they are NOT being removed, the information is still there for research purposes.

and after that you'll need to again sudo pkg upgrade udx sudo pkg upgrade isy sudo service udx restart sudo service isy restart

Closing old threads is a very new procedure in this forum. In the past there were many threads that someone wouldn't even read the whole thread and tack a "me too" post on to the end of it. 98% of the time it wasn't the same thing that started the thread but just something that sounded close even if it was 5 years ago and completely unrelated to the new issue. Only in the past few months have the old threads started getting closed, arbitrarily and purely by date of last post. The purpose is to force people to start new threads and state there problem. If they don't give the version they are using that should always be one of the first questions asked, for cases just like yours, where the issue was likely fixed since 5.0.14. Another thing that the closure and unpinning of old threads seems to be helping is that users are no longer upgrading to weird versions. Some get the idea somehow they they should install something like 5.0.2 to get used to 5 before they jump to the latest and greatest... the bottom line is there is no reason to install 5 year old beta firmware that's full of bugs. There's only two version of 5 that people should be installing today... 5.0.16C if they have a 300 series z-wave board, or 5.3.4 if they have a 500 series z-wave board... all others versions of the 5.x branch should be considered exactly what they are... buggy beta versions.

In addition to Javi's comments, make a text backup of your programs in case you need to refer to what it looked like before. ("Adjust Scene" in particular doesn't play nice during the upgrade.) Before or After backing up the v4.9 ISY with the backup utility, also open the programs Tab, click the top/root folder usually named "My Programs", then right-click it and pick "Copy Folder to Clipboard". Then open any simple text editor that won't add formatting, such as Windows Notepad, Paste the clipboard, and Save the file. Now you have a text version of your programs in the event you need to reference it. After upgrade to V5.3.4 your admin console credentials will be reset to admin/admin. First thing you need to do when you log in check Help > About and make sure you've got the exact same version number listed for Firmware and UI, If not stop until you've reserved that. Second thing to do is open the "Programs" Tab, "Summary" sub-tab and look for the color Yellow, if you find any that program needs to be manually fixed and is the reason for the notepad file that you saved above. Final note the Admin Console under v5 uses much more Java memory, you likely need to do this. Be sure to read the rest of the detailed update instructions in this post.

It's not a new feature, its new to working with NR's on ISY on Polisy. the # with email notifications has always been around, I linked a wiki page, check the edit history, information on the # sign was included in the original page creation. There was quite a long thread last summer over the scalability of NR's due to lack of that feature. I finally realized that Michel didn't know that it didn't work and so stated the history as I knew it. I believe that it's because of that thread specifically that the functionality was fixed in NR's in ISY on Polisy. It has not been back-ported to the ISY-994, but as shown the # sign has always been a feature of EMAIL notifications on the ISY-994

The # sign already works with EMAIL notifications only on the ISY-994, it has never worked with NR's however. In fact there is a note on this wiki page that states: An example usage: AllRecessedDoorSW - [ID 0044][Parent 0037] If 'Door Switches / Barn Walk-thru Door / Barn Walk-thru Low Batt' is switched On Or 'Door Switches / Barn OHD Button / Barn OHD Button.3 - Low Batte' is switched Off Or 'Door Switches / Costco Rm NEW - Door / Costco Rm NEW Low Battery' is switched On Or 'Door Switches / Front Door / Front Door- Low Bat' is switched On Or 'Door Switches / Garage to House Door 2 / Garage to House Low Battery' is switched On Or 'Door Switches / Green Rm Closet Door / Green Rm Closet Low Battery' is switched On Or 'Door Switches / Laundry Rm Door / Laundry Rm Door - Low Battery' is switched On Or 'Door Switches / MBR Closet 2 Door / MBR Closet 2 Low Battery' is switched On Or 'Door Switches / Playroom Door / Playroom Door Low Battery' is switched On Or 'Door Switches / Pool Closet - Door Sensor / Pool Closet Door - Low Batter' is switched On Or 'Door Switches / RachioButtonLower / RachioButtonLower - Low Batt' is switched On Or 'Door Switches / RachioButtonUpper / RachioButtonUpper - Low Batte' is switched On Then Send Notification to 'Bill' content 'DoorName' Else - No Actions - (To add one, press 'Action') which uses this email template: (the words Low Battery are part of the node name). This is honestly the only place I've been able to use the # due to the email limitation. I prefer Pushover notifications, especially now that the Notification Nodeserver will retry on failed connections and some http errors.

V4.9 is the current official release in the version 4 branch. Version 4 was superseded by Version 5 firmware, which was beta for a long time. in the v5 branch 5.3.4 is the latest and greatest. It is labeled test build and not official release (without looking it up I think 5.1 is labeled “official”). 5.3.4 is what you should be using before you point fingers about long time bugs not being fixed. (in version 5 to be labeled “official” a firmware must go thru the Z-wave certification process which costs UDI a significant amount, that’s the only thing holding back all v5 release after 5.1 from being labeled “official”.) The version you’re using 5.0.14 is a beta version released October 2018. Yes it has lots of bugs. Your Z-wave version 6.81.00 tells us you have a series 500 Z-wave board, so move right up to 5.3.4.

So you’re using firmware that was released October 2018… 3years ago.. but complaining about a bug that hasn’t been fixed? Really?

Help > About... what is the firmware and UI version? Try: unplug ISY, Unplug PLM, wait 30 seconds, plug in PLM, wait 30 seconds, is the light on the side of the PLM solid green?, Plug in ISY. Try: different power supply for the ISY.... there were some supplied by UDI with ISY's that don't do well after brownouts. The Bluepower light comes on still, but functionality is effected. You can try any power supply that outputs anywhere between 5 volt and 30 volts,center positive, 2mm barrel connector.

Help > Purchase Modules Add portal...

Admin console > Configuration > Portals is likely waiting for you to hit “Accept”.

As others have said, just download the correct file... use 5.3.4 since you're setting up a new system. Don't unzip the file. just select "manually upgrade" and upload the file the Zip file. You want the First link the in step 3 of the Install section of the directions.

Open a ticket by emailing support@universal-devices.com You've eliminated the possibility that the cable is bad. The remaining possibility are 1) Bad PLM, 2) Bad ISY, 3) wrong firmware on ISY. #3 is the best and easiest.... Does Help > About show OADR in the firmware string? That's the version that doesn't connect to a PLM. (even tho it says Insteon at the beginning). without the OADR string should be correct.

maybe we should name it NINO instead of Ninsteon... Nokia In Name Only... they don't have much control.

@Geddy has some links that will help for gmail. You basically need to create a gamil app specific password for the ISY. Surprised support hasn't answered, UDI support normally replies in a matter of hours on weekdays, maybe we should flag @Michel Kohanim, and remind him that he posted above about temp email credentials to use with 5.0.16C so that he knows what this is about.

The admin console never adds parenthesis on its own. You must add them manually by using the buttons I displayed in a screen shot then move them using the line up and down buttons into place. You have two options: 1) to receive notifications of device errors in real time as they happen just drop the first line from your if statement like this: If 'Back Yard Flood Light' Responding is False Or 'Bar Light' Responding is False Or 'Basement Door Light' Responding is False Or 'Cat Box Floor Lamp' Responding is False -----Snipped for brevity----- The status of the "Responding" flag changing will trigger an event that makes the IF run. Or 2) if, on the other hand, you only want the notifications to arrive once a day at sunset +10 min, then you need to press the AND (..) parenthesis button and move the lines that appear into place so that it looks like this: If Time is Sunset + 10 minutes And ( 'Back Yard Flood Light' Responding is False Or 'Bar Light' Responding is False Or 'Basement Door Light' Responding is False Or 'Cat Box Floor Lamp' Responding is False -----Snipped for brevity----- ) I can't provide much feedback on z-wave procedures because I don't use Z-wave, others will also have to provide that feedback... also this @lilyoyo1 post:

It doesn't work that way. When a device times out and gets a red ! in front of it's devices name, responding changes to false. responding is true if there is no red ! in front of the devices name. The IF statement that OP wrote does not cause communication.

You need parentheses... your AND and OR's or not being combined as you expect. Also a time isn't really needed, because when "responding" is a status and the change from true to false will trigger the program. To test that I Created this program: AAAAtest - [ID 01D0][Parent 0001] If 'LR Lamp 1#' Responding is False Then Set 'LR Lamp 2#' On Else Set 'LR Lamp 2#' Off Then I made the device for lamp 1 unavailable. then I issued query to lamp 1. At the end of the errors the red ! point appeared in the device tree and Lamp 2 turned on. If the desire is to ONLY notify at a specific time, the IF body would need to look like this: AAAAtest - [ID 01D0][Parent 0001] If Time is 9:40:00AM And ( 'LR Lamp 1#' Responding is False Or 'LR Lamp 2#' Responding is False Or 'LR Lamp 3#' Responding is False ) -- another thought is that the information regarding the error code is stale... it's whatever the ISY last knew, if the device isn't communicating the ISY can't update the error code from what is stored in the device, what you're seeing is whatever the ISY last received when the device last communicated.

Please post your program, its hard to guess. (right click the program name, copy to clipboard, paste) If this is indeed a z-wave device returning 0 or 1 you'd need to check the devices documentation for the meaning.