larryllix

V5 can do it with seconds resolution so much better. I posted a series of programs to do this in the V5 section.

Nice! Did you know ISY has a modulo arithmetic function to make this easier? $hours /= 3600 $seconds %= 3600

You will need a few support programs to work with this basic timing loop but yes. It may make your ISY somewhat busy. You will need a program to run at midnight to transfer the accumulator variable to another one to remember it and then reset the accumulator variable, a program to send out the remember variable at a convenient time. You will lose timing if ISY power cycles, in all cases. If you run v5.+ it has a seconds since midnight function variable that is easy to accumulate from.

Use the Belias programs linked to in Post #10, this thread.

Here is a copy from the Belias program thread. 3d - Create a program called Leak Startup and ENABLE RUN AT START-UP If $iStartUp is 0 Then Run Program 'KitchenSink - Variable Control 2' (Then Path) Run Program 'StorageRoom - Variable Control 2' (Then Path) Wait 5 seconds $iStartUp = 1 Else - No Actions - (To add one, press 'Action') ** Set to run at start-up ** Here is the thread where the power up program was copied from. Post #1 http://forum.universal-devices.com/topic/11566-leak-sensors-a-suggested-complete-program-package/page-1 Now mind you, this program will also cause notifications to happen at the same time, 25 hours after ISY power up, also, if no heartbeats were detected.

I have a common initialisation program for the whole ISY. In that, I reset all MS low batts as well as all Leak detectors heartbeat detection programs. It's always a pain deciding where to keep these programs...all in one common place or with each device. Either way, it's always an easy forget to maintain thing, when so many other things are going on updating programs with new ideas.

Let's see what I have online here.... This one is a list of Network Resources I use. Typically I use three for each bulb. I could use a set of four NR for any all bulbs but ISY has a buffering problem and can send your new variable value for an old NR send. Using a set of three for each bulb resolves that and eliminates the safe timer using Wait 1 second between every send. I use one for Setting levels, one for simple On, and one for simple Off. Typically you would set up a brightness level, a colour and any other parameter in Integer variables. Then when you call a NR it uses those memory values to send the parameters. This avoids a bank of NR for every brightness level and colour combination numbering into hundreds or more. This one is for a bulb specified variable = one NR does all bulbs but is not used due to the above argument. Ths one is only for bulb 2 as specified in the URL. Other parameters are specified in variables

It would be better if you quoted a least a small piece of somebody's post. It gets that person's attention, let's others know who you are asking, and your post just happens to fall on a new page so it makes it hard to even know what you are posting about.

"close" works to turn off a light I tested but "open" just get's ignored. V5.0.10 / Echo / ISY Portal

You have always been vocal about certain things anyway but yes, vocal control has changed a lot for me too. I have two 4 button mini-remotes I haven't sen in a year now. The batteries are probably completely dead now. Wife know many of the commands now after hearing me use them ( the beatings didn't work! ) ISY can make it happen!

ISY time frames do not follow any other language simple logic. They exhibit dual logic personalities, one of triggered event driven logic, and one of inline style code conditional, conventional logic. ISY time frames are probably the most complicated constructs to understand.

I use that technique a lot! It works very well to centralise control and isolate triggers from many programs. When you discover a new method of determining "dark" you can change the code in one program and the rest will still work without modification. I use 7 out of 10 MSes reporting dark and even then the 7 factor is a variable I can modify. Nice!

Agreeing with apostolakisl above, is the ISYcode you use and others depend on, out of alpha / beta? V5.0.10 should have never been labelled as "alpha" In the same vein as your "Insteon/UDI/Smarthome" analysis...... You used the term "Smartphones" instead of "smart phones", as if android/Windows/iWool mobile phones were another division of the Smarties corporate chain. Way too much credit given there

I have a query for clarification about your use of the phrase (damn English ) "beginning to fail". Does this mean some have already failed...or ..some have started to function erratically? Being in a similar position as you my take on it....and I am procrastinating way too much. I wouldn't go about replacing things that are working well but I would switch gears in the future. If nothing else having a Zwave option will ensure all your Insteon devices work forever. I thik the writing on the wall for the SH/UDI relationship is getting clearer as time passes. As a severe procrastinator, I will give it another year and then start the ZWave trail, but along side what I already have. OTOH, I have developed a lot into WiFi and Ethernet devices for coloured lighting. Then again Hue is ZigBee, So much for my Insteon purity.........*SIGH**

People keep stating the blank status doesn't matter but that is nonsense. ISY programs have to test true or false, one way the the other, for blanks status fields. I need to do some testing for that logic since this has come so up many times now. Most are testing the Heartbeat with a 25 hour allowance. Some LDs send an On every 24 hours, and some send an alternating on and then off, one each 24 hours. Have a good one!

I hope you also tested each and every sensor and rest them too. I spent most of my years in industrial control systems. Electrical grid protection and control systems. We weren't allowed mistakes. Beer should be involved here. Some have successfully used both and it can be done but it takes a lot of mental homework and overhead. I wouldn't attempt it because I can't fathom any section of my HA control and inputs that could be isolated from the rest. ISY has plenty of computing power yet. It's the Insteon protocol that bogs down waiting to be so polite.

Interesting and I believe this must be the case. Now this has me curious and if further proof cannot be found I need to set up a test case to prove it. It would make sense that statuses are sent with the heartbeat once per 24 hours. Checking the program summary page should give me the last heartbeat and the ability to know when the next one should arrive. Unfortunately I will have to power cycle my ISY just before that time, to see the update and prove it. Does anybody know a way to blank a device parameter field in ISY other than power cycling the ISY itself?

My four Leak Detectors all show status and no blanks. Those fields have been filled in somehow, without tapping the button or detecting Wet since my last ISY power cycle. ISY is getting that information sent contrary to how other battery operated devices report. Perhaps status is also reported with each heartbeat?

I read the problem in your previous post but you still have not stated what the status of each leak detector is showing now, while ISY is running. There should be no blanks. I have four leak detectors and they all show Wet = off and Dry = On because I had to reset each one of them from installation, and after each flood I have detected. (I've had few) These LDs only send information when a change happens. That is the only way ISY can know the state of them. ISY remembers the last time wet was detected, or the last time you tapped the button on each of them. If neither of those have ever happenned then ISY will display a blank because it doesn't know what the LD states are and ISY programs cannot work properly with them. Your power up program detection of wet has to go. ISY is not ready to make that decision right after power up with unknown parameters. As Teken suggested, remove the "run at startup" from each program. Check to make sure each device status shows Dry=On and Wet=Off. If not, tap the button for that unit and recheck. There should be no blanks. Test again by power cycling your ISY. Train the neighbour to reset the Leak Detectors after cleanup by tapping the buttons after the LD is dried off completely. This must be done, and remote resetting your programs without resetting the Lek Detectorss may cause further problems with your program logic. I assume you also have heartbeat failure detection programs in place.

Please check the status of each leak detector in the admin console device page for each unit. Just because there has never been a leak doesn't mean one didn't last send a Wet signal and one, or more, Wet statuses stuck on would do exactly what you are complaining of. Surely you must have tested each unit when you installed them.

They are mostly readable but partitioned. So when you format it you are only getting say 4-8 GB of formated SSD not the full SD card. ie. 16, 32,or 64 GB. The rest would be hidden to ISY

What really surprises me is that the CAO tags, having dewpoint as an option do not have dewpoint as a sendable parameter option. Well, at least they didn't sometime back but then they couldn't graph the dewpoints either. IIRC I checked the code help pages a few months ago. That was just added less than a year ago so offering a sendable dewpoint to ISY would make all this dirty talk redundant.

Yeah, I linked to my ISY program in a previous post, that was styled after that chart. The dewpoint curves from 100% down to about 55% follow the (100% - RH%) /5 very closely, but at lower humidities the curves don't behave that simply. I took any (100% - RH%) difference over 45%, and added an additional 0.7 of difference to it, before dividing that resultant by 5.That made the lower humidities follow the dewpoint curves closer. Exponential calculations would have definitely been better. Mountians? LOL. In my previous home I was 350m abobe sea level to my foundation top = 1148 feet, and I was in a slight valley from mostly flat land around us.. Currently, my home is on a small mountain at 340m above sea level to my foundation top = 1115 feet. (yup, lower) My humidity here, ranges from about 30-100%. Mostly in the higher ranges. We have huge bodies of water about 10km, on one side and 80km away, on the other side. That gives us snow, over our heads most winters and some days needing to blow snow out the driveway at least three times. The location was a mistake but the views are spectacular. LOL

I explained why that doesn't work in my previous post. Check the ends of the curves. They are way out for a workable range outside.

Just an information warning. If you use a RPi with NOOBs and install an OS the installation process partitions the microSD card and formatting it elsewhere will NOT get the full SD card space back. This takes partitioning software to correct the SD card back to one partition for full usage of the space. Other software can do this also.