MrBill

Make everything a controller. Don't have anything that a responder only. You can actually do this in one scene, you don't need 2 scenes for what you're showing here.. just make everything a controller.

Keep in mind HTTP = Port 80 HTTPS = Port 443 Since 433 has another use with Polisy...... thats why 8443 is a better choice..

That wouldn't be any different than if you were using the non-existent option of not dimming that key. I'd combine it with time If Sunset to Sunrise (next day) and lock is locked then dim keypad else brighten keypad

Correct, only the brightness of all buttons is adjustable as a single unit. If the goal is to not go to bed with the lock unlocked, adjust the program that dims the keypads to not dim that keypad until the lock is locked.

I'd love to, but being honest it's probably over my head. While I've been successful with the Lua langauge in the past, and its data structure is not unlike python's data structures, I seem to have a block with some of python's concepts... it might be age. As you know I had a goal of creating two nodeservers and even purchased hardware for dev purposes, of the two potential nodeservers, one is a re-write of any early goose66 nodeserver for Pentair Screenlogic, that one works but I'm not comfortable actually releasing it via the store. The other one I failed entirely on because I could never figure out the google sheets python library. (my need or demand for that one also went down because the Universal Devices HA integration allows me to get the logging that I was trying to create with the 2nd nodeserver and google sheets. So while I'd love to create a nodeserver and become famous for it ? it's probably realistically not going to happen.

@Michel Kohanim Getting the shade to work was quite a story, it starts with "I bought the shade without a plan but it said Zigbee so I figured I could make it work." Then I learned that ZLL and ZHA are like Apples and Oranges. (Zigbee Light Link/hue vs Zigbee Home Automation). So next I had to look for a Zigbee Coordinator that also had a local API, that's hard to figure out because all they advertise is "works with Alexa/GH", and they literally all state that, but none appear to actually have local API's, some advertised cloud API's but I wasn't interested. Some post somewhere got me looking at ConBee and they advertise works with HA... so I ordered one. Again not really knowing if this would work out but figured I had 30days before the Amazon return window closed. Turns out that with deConz, the native interface for Conbee, my device (the shade) hadn't yet been integrated. I wrote to dresden elektronik support a.k.a. Phoscon the maker of the conBee and a very detailed email came back telling me how to collect the devices information so that it could be supported via deConz, but looking at the github page where you make such device support requests it looks like they are quite backlogged with 153 open requests dating back to early this year. But the dresden email also contained one more sentence: "it seems you can already use the blind with the ConBee II via the Zigbee2MQTT integration" and Zigbee2MQTT also had a Home Assistant add-on. Ultimately I had to install two add-on's to HA for MQTT broker and then Zigbee2MQTT, there was much trouble getting Zigbee2MQTT to start and the error message that was misleading, but after firmware upgrade and a different error message i finally found the info needed in a "Note" at the bottom of article. Then I had to mess around with Zigbee2MQTT until it just mysteriously paired with the shade... I'd done the process the same way 100 times by that point, but the youtube video tutorial I was using warned that step would be difficult and illogical so I kept trying. The first time I got the shade to run from a laptop click, I whooped and hollered so loud the dogs started barking and my wife came running to see what was wrong...lol Next I created an ISY state variable to control the shade via Home Assistant, normally 0, set -1 to close and 1 to open and HA sets it back to 0 at the end of the automation. Used that with an extra KPL button/ISY scene for manual control. In the end I ended up using an HA automation to get the automation I wanted: close at sunset +30 min offset (easy peazey, with either platform) open when the second person got out of bed in the morning I had an idea in the back of my head to use "when phone is disconnected from charger" as the sensor for the open automation. Originally the goal was to use the iOS shortcuts app to set an ISY state variable for each phone's connected to charger state... but I realized I needed to use REST via the portal in case the phone wasn't on wifi for some reason--no wifi and a local path resulted in an ugly error notification. In the end, I discovered Shortcuts app to HA native App made more sense because it would use local if it could and revert to cloud without wifi. Since this was all in HA I just ended up doing the automation there, so now from 5-9 AM when not one but both phones have been unplugged the shade rolls up. It works VERY WELL... and my new current favorite automation! Now that I have the phone charging state in HA, today I'm setting it up to update my temporarily abandoned ISY State variables, so that I can eliminate having to push a KPL button to initiate the goodnight routine in the ISY, instead Goodnight will become 2 phases, the first will run when the first phone is connected to the charger, the second will run when the second phone connects to the charger.

like I mentioned, link counts are very hard to do, especially on large systems, especially with wireless devices. ANY Insteon traffic during the link count will invalidate the link count. That's why you're getting confusing results from 600,900,1600... traffic occurred during the count. I also think you paying too much attention to the wrong thing. You upgraded from 4.x to 5.x... you didn't have a link count problem before that, and the upgrade didn't change your link count. Study your device tree, especially wireless devices do you see little 1011 icons that look like this: or this ? If so, that is your problem.

yours....

by Michels own words: he seemed to indicate that the ISY admin console would notify us when new versions are available. I don't care what your interpretation of that is, I wanted to know Michels, so I asked HIM... not you. There was another case... the # to substitute a node name that worked in email notifications but not network resources. That fact had gotten off Michel's radar. Funny, after a long thread where I finally pointed out and stated the fact that the # didn't work with network resources, it got fixed shortly thereafter, but only in ISY for Polisy, the fix has yet to be back-ported to the ISY994. I wondered if the fact the admin console was not notifying us was indeed off Michel's radar. It's really very very simple.... I quoted what Michel said and asked "are you aware?" I didn't say "Teken do you have an interpretion of what Michel meant?"

Like I said, when I want your opinion I'll ask you. when I'm asking Michel, then by all means please let Michel use his words... not what you think he meant to say.

you just affirmed why your statement above "on historical facts" is invalid. No two people will agree on "the historical facts".

Teken we don't agree on this. But I wasn't asking for your interpretation, you felt the need to give it anyway. I specifically ask Michel if he was aware... I didn't need you tell me what "he meant to say". I read what he said, then asked him a question, and you butted in.... In the future if I need your interpretation of what Michel might have meant to say, instead of asking him a question directly, I'll tag you like this "@Teken what do you think Michel meant to say?"

Because @Teken I wasn't asking you to interpret... Your exact words were: As you might have noticed I asked if he was aware that the upgrade display feature didn't work in v5.x. Michel's answer about official releases and Z-wave certification turned out to be just about what I assumed.. but that had never been stated by UDI. Once that is on the table I could follow thru with my secondary question of could the feature be enabled stating that a BETA release was available. The point of my post was to be able to make a suggestion that I ultimately made. Had I needed interpretation, I would have directly asked @Teken what do you think Michel means? Fact is, the feature came back on a system that is considered alpha or beta, so I wanted to start a discussion and see if we could get the functionality going in version 5.x I'm not as stupid as you tried to make me look.

Yes I did, but I was asking Michel for his answer to begin with, not your speculation about what he might have meant.

It's an interesting topic. I recently went down the zigbee rabbit hole with a blind. Learned a lot I didn't know about zigbee, but to skip all that I'll just say the Zigbee Controller I ended up with the ConBee2 the entire device is less than 2" long. I figured the next phase was to figure out a zigbee repeater to get the signal across the house. I was wrong. The signal jumps through a couple walls and rooms and ends up on the other side of the house with no problem. In fact the shade reports back that the LQI (or Link Quality Index) in the 230's and 240's (scale is 0 to 255). Recommended in the documentation is to use a USB male to female extension cord to move the device away from other interference. it's actually double sided taped to the back of a flat screen monitor for a different computer, but the flat screen monitor has enough RF blocking it doesn't seem to have any negative effect on the link quality. Needless to say I was quite impressed with the signal produced by the tiny ConBee2 device. For those curious... my 'automation' of the shade is unique, it closes at Sunset + 30 min and re-opens opens when both mine and my wife's phone have been disconnected from charging power. I actually did the automation in Home Assistant because I never figured out how to get the zigbee shade controlled directly by the ISY.... but the equivalent automation can easily be done via ISY.... Use iOS Shortcuts app to update the Charger state to a State Variable either on the local network, or using the portal API interface. (portal adds an external dependency, but removes a potential error message if the phone is not connected to wifi) (the same can be done on a Droid, but I'm less familiar with the platform... the original idea for the is automation came from someone using a droid tho).. once you have the phones pushing their charge status to ISY state variables, the programs to fire an automation when both have disconnected from charging would be FirstProgram If $sPhone1Charging = 0 OR $sPhone2Charging = 0 then Run NextProgram (if) else (none) --- NextProgram [Disabled] If $sPhone1Charging = 0 AND $sPhone2Charging = 0 then Do whatever you want to do when the second phone is unplugged from charging, such as open the blinds... else (none) ---- So the first program fires when either phone is unplugged, the second program is only true when neither phone is charging.

Perhaps you could implement a system that identifies the difference between beta and official releases. Its really much simpler to upgrade the ISY-994 by clicking the link in the admin console. The current alternative of 1)watch the forum 2) figure out which file to download (not an issue for regulars, but we see people stumble) 3) download to hard drive 4) upload to ISY is just not as efficient as clicking a link in the admin console to upgrade. Perhaps it would say "beta build 5.3.4 is now available".

YET AGAIN... THE FEATURE HAS BEEN ENABLED ON ALPHA RELEASES OF ISY ON POLISY. So you argument is INVALID.... perhaps Michel will have a chance to tell us.. I suspect it's overlooked....

be aware, it's very hard to get accurate link counts, especially with 25 wireless devices randomly sending heartbeats... to count links there must be absolutely ZERO other insteaon traffic during the count. more than likely your issue is ISY needing to write to wireless devices which require manually being put into setup mode.

We've had one 5.x official release. Unfortunately the releases following that are labeled "test build" for reasons unknown to us.... But now the release notification feature has been enabled for ISY on Polisy Alpha releases. So I'm quite confused about why it doesn't work for mainstream 5.x releases. Color me confused! (or Colour me confused! in your part of the world.) I just think many more people would stay up to date with 5.x if the admin console notifications were once again enabled for version 5.x (something that I think perhaps could have just been overlooked!)

Are you aware that's not true in ISY-994 version 5.x? Currently you need to discover the need to upgrade and then manually upgrade. Last time I saw the notification in the admin console was version 4.x

Clear your java cache, including installed apps and applets, then download a fresh copy of the launcher by clicking https://isy.universal-devices.com/start.jnlp It's also helpful if you delete any and all versions of start.jnlp and/or admin.jnlp from your hard drive before you proceed with the above. Also remember after the new copy of the launcher is installed to expand the java cache. Personally I use -Xmx1024m rather the -Xmx512m noted in the wiki

What makes you think the GFCI isn't doing it's job? that is tripping because there is a ground fault. GFCI's are a very misunderstood electrical device. A Ground Fault Circuit Interrupter is designed to shut the power off as soon as it detects a very small 6 milliamp imbalance of power. What is an imbalance of power and how does it occur? Briefly disregarding the 3rd ground pin the electric circuit consists of a "hot" and "neutral"... the power travels out in the hot, and back on the neutral. A GFCI measures the power going each direction, when they are VERY EQUAL the power is allowed to flow. As soon as the GFCI detects that just a few milliamps of electricity got loose and didn't come back on the neutral the GFCI shuts off the power. It does that to protect people from getting shocked. (Conversely, a circuit breaker has a different job, it protects the circuit from overload-- to much current-- which causes fires.) Now that we know what a GFCI is, there are a number of ways to attack the problem but none of them are quick and easy. First you could plug the fountain pump into a different GFCI elsewhere and let it run a long time, plug it and unplug it several times... if the other GFCI never trips, then likely your problem isn't the fountain pump. Then there is that Insteon plug... you're correct those weren't designed to be used outdoors and moisture inside the unit may very well be the issue. This is a hard one to test for tho. The other problem could be a micro crack in the insulation of the wire going outside, whether it's in conduit or not, whether it goes underground or not. But consider that a micro crack in the insulation might not leak any current until the area around it gets damp and conducts a little bit of electrical leakage. Finally, it's not unheard of for the GFCI itself to be bad. Especially if it's an older GFCI (those manufactured back in the 90's or before for example). GFCI's also get less reliable as they trip more often, so if yours trips 12 times a year and has been tripping that way for 3 or 4 years... it might just be bad. So as you can see, YES you have a component, or perhaps components that need to be replaced. figuring out which is the problem.... or task.

turn off wireless writes: Press that button so that it's greyed out. Once you get your unactive devices deleted, you need to study the device tree looking for 1011 icons. those are wireless devices that need data written. Unfortunately it will probably be a slow painful process if you have very many. When you get to this phase put as many of the wireless devices with 1011 icons on the tree into setup mode that you can each time you do wireless writes. What's happening now is that every time you are writing to devices to delete and item it's trying to write to wireless devices.. and it's taking a lot of time to error out.

@ndorny The update you need actually came at the 4.73/4.75 So do as @Geddy mentions and update your firmware v4.9. I think due to the websocket vulnerability addressed at 4.73/4/75 you won't get the portal to work with 4.6.2

there are some .state files, but the names don't indicate theme, font, etc... see: https://wiki.universal-devices.com/index.php?title=Main_Page#Admin_Console_Minimized.2FInvisible_and_Cannot_be_Restored