larryllix

"Trigger" was Roy Roger's horse so.....

I would wait until Michel gets on this from your open ticket. I assume you meant to use the acronym IoP, as IoT has a different meaning typically, and may confuse some. Sent from my SM-G781W using Tapatalk

I have always had to restart my whole polisy any update I have done. Some small quirk always seems to show up. Sent from my SM-G781W using Tapatalk

Yeah, It seems like it would be so easy to add another pulldown option in the menu, and add the same code without the "program Stop"

Just some observations Why not use vacation mode if a permanent hold is wanted? I am not sure Away climate will ever be Indefinite remotely, and may not be a possible combination . I have never used Away on my ecobees. This is my third, now. What is your internal schedule hold set to? This may be overriding any remote Hold. I gave up trying to have my ISY control my ecobee stats (they already contain very advanced logic) and went the other way around, finding that the ecobee stat firmwares were so much more stable and didn't rely on cloud and multi-processor mediums to operate. In the end, a much more reliable and easily settable way was for the ecobee Vacation schedule status to control my ISY vacation logic for the whole house. If the connection failed it was only some fancy HA stuff like humidifier, HRV, fan cycling, security lighting etc.. not my home heating. Of course my house (slab heat in Canadian winter) would only reheat about 1 degree per hour, at best, so when it failed, we slept with a lot of blankets the first night home and used the stove a lot, the next morning

Here is what I would like to see... Program 1 If condition = True Then deTrigger Program 1 <------ disable If section without stopping it do something wait 5 seconds do something else enable Program 1 <----- enable If section Else ----

I heard you were coming and moved. Here is a map of southern Ontario. See the braying elephant? I lived in a**hole.

He couldn't live up to the blonde image giving good advice like that. Sent from my SM-G781W using Tapatalk

I can see you are a man of experience. Not many would even realise these quirks without sweating through it themselves. Still have any hair left?

Yes. IIRC this is only event driven system I have worked with, that can have processes stopped and restarted. I would guess in the beginning UDI had to decide what to do when a new event happens that is the same as one already being processed. Continue like nothing happened and ignore the new event Continue like nothing happened and stack the new event for sequential operation Stop the current process and handle the new even like the previous process wasn't happening. The choice they made provides a lot of strange happenings in even processing and program writing. It definitely puts a hiccough in the logical thinking of experienced inline code writers. Now I would like UDI to add a program disable command that allows a program to finish what it started. Currently the Disable program command line also stops the affected program. "They just have no self-control..."

Yeah, Spaghetti code can't really exist in ISY event programming. Although you can make some very interdependent event driven code that can oscillate. Been there, done that. BTW: I use the Repeat While construct as an inline If/Then/Else construct. Since ISY doesn't offer much in the way of inline conditionals, it makes and avenue to get things done. I don't like it but the whole thing would be much better if I could change the names of the construct to suit better. Good inline commenting and labeling helps the confusion a lot. It can get complicated when you write ISY code to average multiple sensor inputs and discard outliers but it works well for analogue inputs to be reliable in the event of a sensor malfunction and I always like to not use sensor analogues directly from input devices. Passing them through a stats variable has allowed me to swap input devices, change scaling and otherwise massage data that would mean modifying many programs using that data. When I half moved my programs fro ISY to polisy it took one program to synchronise sensor data between devices. Some see that as too complicated and some see it as simplified at the cost of a few more bytes of code. At least ISY offers many ways to do things and we all have our druthers. This is about the 5th system style I have worked with that used event driven code. If you lived on VB, using their "objects", for a length of time, you would fall right into this style.

Nice! I use integer variables profusely for constants with labels and my only records are imbedded comments and ISY element names. eg. $cTRUE $cFALSE Element names are always positive logic and try not to be ambiguous. eg. Program: deviceName.batt.ok All just good programming practices from inline code habits learned the hard way. I avoid hidden and obscure things like using program state logic etc. Sent from my SM-G781W using Tapatalk

Not quite so fast. I am still seeing people discussing Jimbo's NEST node server out there must be something happening there between NEST stats and ISY.

as per Geddy above

I I never had problems with the Ax92u routers for the quantity of devices being kept track of but I had my HA devices (about 50 mostly bulbs) all on an AP - my old Netgear router. It put out a lot more signal power than the ASUS units after they discovered each other and became a mesh. It seems they turn the output power down so the zones are smaller and don't disturb the neighbours as much. Even though I still had a single Ax92u handling all the DHCP entries and keeping track of the connection list it always did one thing badly. Certain devices would just lose their rights to connect with the Internet/WAN side. Signals were good. Connections inside the LAN were good and worked. Some devices would lose the connection between WAN and LAN about once per month at random. Never figured it out. The think I hated the most was there was never any reporting of any problem in logs, on screen etc. There was no way of knowing anything was happening except that random things would stop working. Most of the time a reboot or soft reboot wouldn't fix it. It took a power cycle of the router. Also when meshed the 5GHz band went so quiet my wife's iPad couldn't use it in the same room. The high end WiFi 6 was excellent though.

I had a lot of trouble with that combination. I was running an AC68u ??? with the Merlin firmware. Turns out that version had an NVRAM shortage, ASUS knew it and replaced it with double = 128KB NVRAM later in the production. When I went back to the ASUS firmware the problem cleared up for a while but re-appeared later. I tried adding two of the latest Ax92u mesh routers to the pile and it made them a mess also. Until I garbaged the AC68u and had one Ax92u routers fixed by ASUS my problems persisted. Look for revision 'A' IIRC. When the power blinked or I rebooted the router, every device would contact the DHCP server for an IP address. Having about 80 devices, sometimes my ISY994 and/or my polisy would not get an IP address, or it was forgotten due to a shortage of router memory. Of course ISY994 and polisy would attempt to carry on with IP addresses of 0.0.0.0 and that a made a mess of my LAN network. Things got very intermittent and undependable for about a year or more. The Ax92u routers didn't have the same NVRAM shortage. They have other problems. Putting my HA back onto an old Netgear router (without power killing mesh) made things work like the old days. Faster and totally reliable again. In the end, Merlin firmware kept adding new features without consideration if the router had the hardware to even support them and ASUS routers? hmmmmm.. I still have a few hairs left on my head.

I had thought that Nest products were locked to selected Google friends and were not accessible by other products now. Sent from my SM-G781W using Tapatalk

I had thought Google had disconnected their Nest stats from the public and the answer was .. ...get an ecobee smarter unit.

@bpwwer Installed all updates using puTTY method... sudo apt-git udpate..... sudo reboot for complete refresh of all modules. Looks good. No problems detected. Only 1 NS being used though.

No heartbeat. Insteon battery devices that send a low battery signal do not send heartbeats. UDI could never get co-operation from Smarthome, in the form of a protocol/spec sheet so the whole interface was hacked. Some data is still not understood perfectly. I ignore the non-MS style parameters. They always appear incorrect and random. Any attempts I have made to "calibrate" them has resulted in further errors in readings.

It's not the exhausted air that dries out the house. It is the incoming air that does that. When ventilating my extremely damp cold cellar (over 85% rH) I discovered that rH is not the factor that matters. I would bring in hot humid summer air that was lower rH than the cold cellar Rh and the Rh would rise every time. I had to understand dew point then. After figuring out how to calculate dew point for both environments using ISY calculations (fudged it a lot) the selective ventilation would actually lower the rH of the cold cellar. Although I could never get the rH below about 75% but I stopped the molding that was ruining things. To meter both ends of this I used an Insteon 2441WTH stat and two CAO wireless tags to send information into variables. The inside Tag was a backup to the Insteon stat, only. If the metered range was not reasonable or the Insteon signal was flaky the Tag would switch itself into the calcs. The most interesting point was using rH to control the humidity. Strange how you can bring in lower rH air and it can raise the destination air rH. Lesson learned on that one.

I'll have to give those a try as the constant randomising the from address by the UDI default converter is driving me nuts now and I can't make my Gmail SMTP server work for live nor money anymore. Rge constant changing of the from address makes it a lot of work to delete every SMS individually and floods my lists with so many different message titles like a nasty spammer making it useless, mostly. Sent from my SM-G781W using Tapatalk

You would require a three wire cable a d the bare ground doesn't count. Dimmable receptacles are a bad idea and I doubt you will ever find one in upper North America. Sent from my SM-G781W using Tapatalk

Oh sorry. I have never used the output contact statuses. I always did my own setpoints inside ISY with longer or shorter cycled the humidifier appropriately based on the ISY setpoint. However I did sync my ISY setpoints off my ecobee stat humidity setpoints. When I built my home many contractors stated I would never need a humidifier, based on the sealing of my construction, so I built the air handler space too tight to add one. Boy, were they wrong! If you use an HRV ventilation system in the winter climate. I used a large room humidifier and had to haul water regularly in winter months. 😪 IIRC, my ecobee 3, and ecobee 4, only ever had one extra contact output. You had to take your choice between usage setup.

yes. you can see them in the status page and use them in programs to read or set Sent from my SM-G781W using Tapatalk