Best Way to get the ISY to Interact with an Analog Input

[arw01]

Ok so you cannot DIRECTLY assign a variable from the elk to the isy, but you can Compare variables correct?

 

so one program does

 

if isy_var < elk_variable

 

Then

isy_var +=

Run isy_var_increase <== maybe not necessary, but want to run a loop until it gets there

 

Else exit program

 

 

Then you have at least a value just 1 digit higher, I think some remainder math could get you the other . something piece as well in the same manner, then perhaps some simpler programming can be done?

 

 

Since the %= gives you the remainder of a division, I think (that's dangerous) that you should be able to get at the .1 portion of the voltage measurement.

 

Can you increase the variable in the elk by a factor of 100, or something to make the easier to run the count up to proper value? eg. 1.83 volts becomes 183?

 

 

Alan

[apostolakisl]

Ok so you cannot DIRECTLY assign a variable from the elk to the isy, but you can Compare variables correct?

 

so one program does

 

if isy_var < elk_variable

 

 

You can't do that. ISY variables can only be compared to other ISY variables or a fixed number of your choice.

 

 

Why did you choose to go with Elk reading the voltages instead of CAI? CAI could have read the voltage, done the math to convert to gallons, and then posted that value directly to an ISY variable.

[PLCGuy]

Why did you choose to go with Elk reading the voltages instead of CAI? CAI could have read the voltage, done the math to convert to gallons, and then posted that value directly to an ISY variable.

If only I had known the fun we would have with the Elk/ISY option, I would have gone with the CAI... But we didn't know and now we have to live with the consequences which is ISY 83 programs

 

Now thanks to the fact that I can export and import ISY programs, writing 80 similar programs isn't hard with a text editor.

 

But the number of programs isn't currently my issue. It is the logic race issue inside the ISY and I don't think this would be solved by the CAI. Anyone have ideas on that?

[apostolakisl]

Why did you choose to go with Elk reading the voltages instead of CAI? CAI could have read the voltage, done the math to convert to gallons, and then posted that value directly to an ISY variable.

If only I had known the fun we would have with the Elk/ISY option, I would have gone with the CAI... But we didn't know and now we have to live with the consequences which is ISY 83 programs

 

Now thanks to the fact that I can export and import ISY programs, writing 80 similar programs isn't hard with a text editor.

 

But the number of programs isn't currently my issue. It is the logic race issue inside the ISY and I don't think this would be solved by the CAI. Anyone have ideas on that?

 

I don't really know what the logic issue is, but just at a glance of the posts it looks like it is somewhere in your ISY programs. Assuming your measuring device is outputting the correct value, then I don't know of any reason CAI would have a logic problem. It would be a pretty short CAI program to do what you want. The measured voltage from your measuring device would plug it's value directly into a couple lines of code on CAI that do the math and store the number of gallons as a CAI variable. From there one more line of CAI code posts the value to ISY variable. Since you probably don't want it to post a value every single time the processor cycles, you would include a little more code that either schedules periodic postings or only posts on a change in value. ISY wouldn't need to do any math or perform any logic functions. You could go this route for about $50 (CAI board plus a 4-20ma to 0-5v converter). You would also need a 12v wall wart

[PLCGuy]

I don't really know what the logic issue is, but just at a glance of the posts it looks like it is somewhere in your ISY programs. Assuming your measuring device is outputting the correct value, then I don't know of any reason CAI would have a logic problem. It would be a pretty short CAI program to do what you want. The measured voltage from your measuring device would plug it's value directly into a couple lines of code on CAI that do the math and store the number of gallons as a CAI variable. From there one more line of CAI code posts the value to ISY variable. Since you probably don't want it to post a value every single time the processor cycles, you would include a little more code that either schedules periodic postings or only posts on a change in value. ISY wouldn't need to do any math or perform any logic functions. You could go this route for about $50 (CAI board plus a 4-20ma to 0-5v converter). You would also need a 12v wall wart

The voltage is getting from the sensor to the ISY correctly - no issues there. So I agree the problem is somewhere in our ISY programs - that is what I am asking for help on.

 

And I agree that the CAI solution would be ideal, if I was to do it again. it might be what I use. But the CAI is not the horse we got onto (after carefully asking for advice on this forum and others). Now we have to live with the consquences of our choice and do the best we can, which is fix the ISY program.

 

As I noted earlier, the issue for our company isn't the cost of the CAI board (that is cheap) but rather the cost of labour for installation, configuration and long term support. Its another trip for our electrician to the site, another power supply (sorry - no wall warts allowed in a pump room - their MTBF stink), another day for one of our techs to learn new product, another day for someone to change the design documents for long term support and so on. This gets expensive.

 

Plus it is one more CPU device and one more power supply to fail, so it reduces the overall reliability of the system. A cistern pump room is not a nice temperature controlled environment, so reliability under non-office conditions is critical (note: we did a lot of checking to ensure the Elk board and level sensors will survive the conditions). So as ugly as it was, we decided that it would be cheaper to write the compare programs.

 

Bottom line is that going to the client with a significant rework of equipment is not going to fly at this stage. It's just life in the design and installtion business. So I need to fix the ISY logic

[apostolakisl]

So how is this working?

 

You push f4 to trigger the process of checking the voltage and displaying the result. Is this the only thing that can trigger anything to do with the $WtrGallons variable?

 

$WtrGallons is how much water you have in the tank, correct?

 

$SlopeDiv10 is what? How does this variable get set? It appears that this variable is the starting point for every calculation you do to determine the number of gallons.

[PLCGuy]

So how is this working?

 

You push f4 to trigger the process of checking the voltage and displaying the result. Is this the only thing that can trigger anything to do with the $WtrGallons variable?

99.9% of the time, it works great. The only two things that trigger the process is the time of 5:00 AM or pressing F4. The F4 was added as way to force a cleanup, when this error occurs. It never seems to fail - only the time tigger causes thw error. Go figure.

$WtrGallons is how much water you have in the tank, correct?

$SlopeDiv10 is what? How does this variable get set? It appears that this variable is the starting point for every calculation you do to determine the number of gallons.

Yes, $WtrGallons is how much water in the tank. $SlopeDiv10 is the scaling factor divided by 10 (to effect a decimal shift to allow integer math to be used). It is initiallized in the variable table and never touched again. basically the math is:

 

$WtrGallons = ($SlopeDiv10 * ElkVoltage) - $Offset

 

And since I can't actually assign a ElkVoltage reading to a variable, I assign a constant everytime, based on the compare to the "Elk Zone 'Water Level' 'Voltage'".

 

Thinking about it as I write this, my guess is what is going wrong is that two of the ChkxxxVolt programs are going true at almost exactly the same time, resulting in something like this: $WtrGallons = ($SlopeDiv10 * ElkVoltage1 *ElkVoltage2) - $Offset . Perhaps the water level is oscillating between say, 3.1 and 3.2 just at 5:00 AM. When I get back to the customer, I will see if that math works out to equal the error values.

[apostolakisl]

Well I suppose it could be that a voltage that is right on the cusp could trigger two of the programs to run during the split second between triggering of the first program and setting $State_LvlCalc = 2.

 

One thing would be to make $State_LvlCalc = 2 the first line of your then clause, but that would just make the time window smaller, not eliminate it.

 

Another would be to cascade your program where each one calls the next one from its Else clause. So all of your programs (except the first) would be set to "disabled" which means they don't trigger from their own "if" clause (but still they run from another program calling a "run if" on it.)

 

If the value is bouncing back and forth, however, it might be that none of the programs run the "then" clause because it happens to be that the voltage is slightly too low when the one program is called and then slightly too high when the next program is called.

[MaddBomber83]

I really think the data validation is the way to go. Least amount of work and it just reinitialized the process if an invalid number is passed.

 

Your next option is to remove the math from your voltage programs. They would instead change a variable (not multiply it) to your voltage. The display program would handle the multiplication. In this way it doesn't matter if the parameter is applied several times. They just overwrite each other.

 

I have 4 folders that compare 20 temperatures each to find out what the Heating and Cooling Set Points are for my Thermostat.

 

If
       Status  'Thermostat- Main' is 62° (Cool Setpoint)
   And $SP_Cooling < 62

Then
       Wait  1 hour 
       Set 'Thermostat- Main' 61° (Cool Setpoint)

Else
  - No Actions - (To add one, press 'Action')

 

The intent of this program is to detect when the wife changes the temperature set point and then to slowly walk it back to the normal set point.

 

SP_Cooling is the normal setpoint.

 

This is to overcome the same problem you are facing. My 'state' is the SP and it causes 80 programs to run and compare. One of them can be true and that one will run for an hour and then change the set point.

[MaddBomber83]

In your voltage program, Change $WtrGallons to $Voltage

 

// WaterLvlInit (Wait for a trigger to calculate and display the water level, then initialize the WtrGallons variable and move to State 1 (Check level))
If
       Time is  5:00:00AM
    Or Elk Keypad 'Main Keypad' 'F4' is Pressed

Then
       $WtrGallons  = $SlopeDiv10
       $State_LvlCalc  = 1

// Chk020Volt (Test if the Elk Zone 'Water Level' 'Voltage' is 2.0 Volts and if so, scale WtrGallons by 20)
If
       $State_LvlCalc is 1
   And Elk Zone 'Water Level' 'Voltage' is 2.0 Volts

Then
       $Voltage= 20
       $State_LvlCalc  = 2

// Chk021Volt (Test if the Elk Zone 'Water Level' 'Voltage' is 2.1 Volts and if so, scale WtrGallons by 21 and subtract the offset)
If
       $State_LvlCalc is 1
   And Elk Zone 'Water Level' 'Voltage' is 2.1 Volts

Then
       $Voltage= 21
       $State_LvlCalc  = 2

// Chk100Volt (Test if the Elk Zone 'Water Level' 'Voltage' >= 10.0 Volts and if so, scale WtrGallons by 100 and subtract the offset)
If
       $State_LvlCalc is 1
   And Elk Zone 'Water Level' 'Voltage' >= 10.0 Volts

Then
       $Voltage= 100
       $State_LvlCalc  = 2

// WaterLvLDisplay (Display the results in inches (rather than gallons) on the Elk Key Pad and go back to waiting)
If
       $State_LvlCalc is 2

Then
       $WtrLvl  = $WtrGallons
       $WtrLvl *= $Voltage
       $WtrLvl /= $GallonsPerInch
       Set Elk Area 'House' Display Text on Keypads, Content 'Elk_WaterLevel'
       $State_LvlCalc  = 0

 

In this, you would never find yourself with multiplying several things together.

[MaddBomber83]

As for limiting the programs in the folder options I mentioned.

 

Folder Conditions for 'Cooling Setpoints (Up)'
Add conditions to limit when programs in this folder are allowed to run.



If
       Status  'Thermostat- Main' < 78° (Temperature)
   And Status  'Thermostat- Main' >= 62° (Temperature)

Then
  Allow the programs in this folder to run.

 

For your voltage settings you should be able to pull down and use a compare to a set number. So you can only run programs in a folder with a specific range of voltages. You did this for the >= 10 reading.

[Autonow]

I too have been extremely frustrated by the lack of analog IO in home automation systems and the position of many of the people who ask why I even need analog. yes the elk has analog capabilities but they are limited. the ISY has none. So what are your options... I come from the industrial automation world so here is my recommendation. You will need a PLC, but first lets look at how to connect analog. You have wireless (you still need a wired power source) there is zigbee, bluetooth, and various IP protocols, and serial type connections. Then there are a host of wired field buses and of course direct connections.

 

THE ONLY benefits home automation systems such as the ISY offer are a host of home specific modules like dimmers, motion detectors and thermostats. AND the big one! ... the field bus over the power line. (their wireless is a con since it can not poll) So how do you combine the best of both worlds.

 

I use the elk as a low cost Digital IO platform. Lots of local digital IO as well as a nice security feature. I like the ISY because of its ability to connect to the ELK and the simple script and scene functions for the homey stuff. but for the analog and the more industrial IO like pump control related to nearby analog USE A PLC!

 

What do you look for in a plc.. Low cost and features! Most manufactures have good hardware but the proof is in the software. If I choose today I would pick a cpu that uses codesys software (IEC 1131 compliant) and can support modbus and has ethernet! There are tons of wireless IO and devices that support modbus (it is the lowest common denominator when it comes to protocols). But there are many other LOW COST solutions that do not use codesys. For example, many hmi's have built in web servers. So you can do your visualizations on the hmi and make it avail on the web; they can even send emails and do data logging from analog data!. A 6" full featured HMI from automation direct is $550 you will need to add the PLC for 3-5 hundred bucks. There are other similar HMI's with built in PLC's in the same price range. You can even load "PLC" type software on a PC and connect to IO via Ethernet or wireless (again use modbus). Digital IO on a PLC is 1/10 the cost of HA IO! Ok a lot to think about and a lot of choices...

 

How to skin the cat the low cost way. First you need a PLC to do the analog logic stuff. Any PLC will do but look at how you will connect the remote IO. It must have Ethernet capabilities. Here is a hidden tip! you can use wireless access points to build your field buss or even use Ethernet extenders that work over the AC line. (just addressed that BIG benefit in the HA world!) Every analog device for the HA world has its smarts inside and give an on/off (digital) signals. Well do your analog logic in the PLC and wire the PLC outputs to ELK inputs.. You can use elk outputs to signal the PLC to do something. Your done! back to the ISY for all the management functions. There is a nice PLC avail for $250 that has lots of digital IO and capabilities to add Analog for a few bucks more.

 

Again the PRO of the ISY is the CON of the PLC.. those pesky home type things like dimmers and KPL's. You can go full blown Building automation but it is out of reach for most home owners.

 

Reality check.. i have a small farm. I can use approximately 25-30 analog IO to deck-out my automation system. Level, pressure, temperature, humidity, power and moisture. If those were digital HA sensors at $50 per point that would be $1500 so don't expect to spend less for analog.

[MaddBomber83]

Looks like 1 wire may be able to do voltage as well.

 

http://www.raspberrypi.org/phpBB3/viewt ... 8&p=220084

 

The people at Sheepwalkelectronics have a module that can do 0-10 V. It uses the DS2438Z 1 wire chip.

[apostolakisl]

I too have been extremely frustrated by the lack of analog IO in home automation systems and the position of many of the people who ask why I even need analog. yes the elk has analog capabilities but they are limited. the ISY has none. So what are your options... I come from the industrial automation world so here is my recommendation. You will need a PLC, but first lets look at how to connect analog. You have wireless (you still need a wired power source) there is zigbee, bluetooth, and various IP protocols, and serial type connections. Then there are a host of wired field buses and of course direct connections.

 

THE ONLY benefits home automation systems such as the ISY offer are a host of home specific modules like dimmers, motion detectors and thermostats. AND the big one! ... the field bus over the power line. (their wireless is a con since it can not poll) So how do you combine the best of both worlds.

 

I use the elk as a low cost Digital IO platform. Lots of local digital IO as well as a nice security feature. I like the ISY because of its ability to connect to the ELK and the simple script and scene functions for the homey stuff. but for the analog and the more industrial IO like pump control related to nearby analog USE A PLC!

 

What do you look for in a plc.. Low cost and features! Most manufactures have good hardware but the proof is in the software. If I choose today I would pick a cpu that uses codesys software (IEC 1131 compliant) and can support modbus and has ethernet! There are tons of wireless IO and devices that support modbus (it is the lowest common denominator when it comes to protocols). But there are many other LOW COST solutions that do not use codesys. For example, many hmi's have built in web servers. So you can do your visualizations on the hmi and make it avail on the web; they can even send emails and do data logging from analog data!. A 6" full featured HMI from automation direct is $550 you will need to add the PLC for 3-5 hundred bucks. There are other similar HMI's with built in PLC's in the same price range. You can even load "PLC" type software on a PC and connect to IO via Ethernet or wireless (again use modbus). Digital IO on a PLC is 1/10 the cost of HA IO! Ok a lot to think about and a lot of choices...

 

How to skin the cat the low cost way. First you need a PLC to do the analog logic stuff. Any PLC will do but look at how you will connect the remote IO. It must have Ethernet capabilities. Here is a hidden tip! you can use wireless access points to build your field buss or even use Ethernet extenders that work over the AC line. (just addressed that BIG benefit in the HA world!) Every analog device for the HA world has its smarts inside and give an on/off (digital) signals. Well do your analog logic in the PLC and wire the PLC outputs to ELK inputs.. You can use elk outputs to signal the PLC to do something. Your done! back to the ISY for all the management functions. There is a nice PLC avail for $250 that has lots of digital IO and capabilities to add Analog for a few bucks more.

 

Again the PRO of the ISY is the CON of the PLC.. those pesky home type things like dimmers and KPL's. You can go full blown Building automation but it is out of reach for most home owners.

 

Reality check.. i have a small farm. I can use approximately 25-30 analog IO to deck-out my automation system. Level, pressure, temperature, humidity, power and moisture. If those were digital HA sensors at $50 per point that would be $1500 so don't expect to spend less for analog.

 

Your idea of low cost seems like a lot of money to me.

 

I have several cai webcontrol boards which run a plc type code and cost $35. Add to that another $30 for an ethernet to wifi converter and maybe $10 more for a housing and I have 3 analog inputs, 8 digital inputs, 8 digital outputs for about $70 that can go anywhere you have 120vac and are in range of a wifi hotspot. And it has the ability to post directly to ISY variables and ISY (with the network module) can set variables or outputs on the CAI board.

 

And it runs on 12vdc so you can mount in your Elk enclosure and use your Elk power supply to run it.

[TJF1960]

Have you had good luck with the wifi adapter, if so which one are you using?

[apostolakisl]

Have you had good luck with the wifi adapter, if so which one are you using?

 

 

I have 2 of these.

 

http://www.ebay.com/itm/NetGear-WNCE200 ... 27d1612e37

 

I have had no problems.

[PLCGuy]

Well I suppose it could be that a voltage that is right on the cusp could trigger two of the programs to run during the split second between triggering of the first program and setting $State_LvlCalc = 2.

One thing would be to make $State_LvlCalc = 2 the first line of your then clause, but that would just make the time window smaller, not eliminate it.

Wouldn't changing the $State_LvlCalc value immediately cause the program's IF statement to be re-evaluated and be found to be false. If I understand ergodic's great postings on State Machines and Triigers (http://forum.universal-devices.com/viewtopic.php?f=26&t=5731) this is exactly what would happen.

The ISY executes either the Then or Else body of a program whenever any of its trigger conditions are TESTED. (This means the Then or Else body of a program will be interrupted and restarted if that program is currently executing a Wait or Repeat command.) This causes the program to be reset and could be (often is) really a Bad Thing; we want the code for our state to run only when one of the trigger conditions (incoming state changes) is True, not each and every time they are simply checked by the ISY.

Now to me, Maddbober83 seems to be on the mark:

Your next option is to remove the math from your voltage programs. They would instead change a variable (not multiply it) to your voltage. The display program would handle the multiplication. In this way it doesn't matter if the parameter is applied several times. They just overwrite each other.

I will try this and see what happens. Frankly I would have split the conditions and body programs like ergodic suggests, but that would have resulted in 160 programs

 

Two questions for Michael -

1) Is there any way to stop a program's IF statement from being re-evaluated? In the PLC world (and in general programming) I can mask interrupts when executing a some code I don't want to be interrupted. Can I do that in the ISY?

2) Is the evaluation of an Elk variable handled the same way as say a state valuable?

[apostolakisl]

Well I suppose it could be that a voltage that is right on the cusp could trigger two of the programs to run during the split second between triggering of the first program and setting $State_LvlCalc = 2.

One thing would be to make $State_LvlCalc = 2 the first line of your then clause, but that would just make the time window smaller, not eliminate it.

Wouldn't changing the $State_LvlCalc value immediately cause the program's IF statement to be re-evaluated and be found to be false. If I understand ergodic's great postings on State Machines and Triigers (viewtopic.php?f=26&t=5731) this is exactly what would happen.

 

Sorry, that would cause the program to abort itself. As I look at your programs, it really is unnecessary to use that state variable at all. The first program and the last program could be eliminated and have the "f4/5am" conditions in every "if" clause and your final program's extra "then" calculations could be added onto each of your voltage programs.

 

Realize that the order of processing can not be predicted in ISY with simultaneous programs. I have done experiments where I ran mathematical formulations on variables using multiple programs that are running "simultaneously" and you do not always see the same order of operation. My experiences on this were confirmed by others a couple years ago when I posted questions specifically addressing that point. I wrote a massive set of programs that serve as a calendar for ISY and the order of operation is critical. I solved the problem by having one program call another after a calculation to be certain that each line of code that alters a variable runs in the proper sequence. In other words, I couldn't just set the "if" to trigger at midnight for all of the programs. It may be that an "if" condition changes but an already running "then" clause still gets a line or two in before it aborts and restarts.

 

Anyway, it is clear by the fact that you are occasionally not getting the right answer that something along these lines is happening.

 

If
       Elk Zone 'Water Level' 'Voltage' is 2.0 Volts
   And (
            Elk Keypad 'Main Keypad' 'F4' is Pressed
         Or Time is  5:00:00AM
       )

Then
       $WtrLvl  = $WtrGallons
       $WtrLvl *= 20
       $WtrLvl /= $GallonsPerInch
       Set Elk Area 'House' Display Text on Keypads, Content 'Elk_WaterLevel'

Else
  - No Actions - (To add one, press 'Action')

 

This eliminates all the possible errors that might occur in timing using that state variable flag and gets you 2 less programs. I don't think it would be possible for two of these programs to ever trigger true simultaneous since there are no possible delays related to altering a variable.

 

Edit: Also you can get rid of the voltage variable. .. which I did above. And somewhere in there you are setting the variable gallons/inch. I don't see any reason for that either. Unless you are planning on using this same set of programs on a bunch of different systems and want to just plug in the variable once. But still, the find/replace function on ISY can do that pretty darn well without using a variable.

[MaddBomber83]

So I'm going to pick up a A to D Converter for the 1 Wire Bus. If my reading is correct, it should be able to take a 0-10 Volt signal and convert it into 0-100% output to the ISY using OWLink.

 

Mapping this output to a State and converting it to an Integer should allow a lot of flexibility in programming. I'll let you know how it goes.

[apostolakisl]

So I'm going to pick up a A to D Converter for the 1 Wire Bus. If my reading is correct, it should be able to take a 0-10 Volt signal and convert it into 0-100% output to the ISY using OWLink.

 

Mapping this output to a State and converting it to an Integer should allow a lot of flexibility in programming. I'll let you know how it goes.

 

This would be the same concept as using the cai webcontrol, except you would be running an application on your raspberry pie instead of using a native function of the device. Also you would need the one-wire device instead of the on-board AD converter in the cai.

[MaddBomber83]

So I'm going to pick up a A to D Converter for the 1 Wire Bus. If my reading is correct, it should be able to take a 0-10 Volt signal and convert it into 0-100% output to the ISY using OWLink.

 

Mapping this output to a State and converting it to an Integer should allow a lot of flexibility in programming. I'll let you know how it goes.

 

This would be the same concept as using the cai webcontrol, except you would be running an application on your raspberry pie instead of using a native function of the device. Also you would need the one-wire device instead of the on-board AD converter in the cai.

 

As background, I am already running a Pi with several temperature probes reporting to the ISY.

[io_guy]

This would be the same concept as using the cai webcontrol, except you would be running an application on your raspberry pie instead of using a native function of the device. Also you would need the one-wire device instead of the on-board AD converter in the cai.

Personally I've fully switched to the Pi.

I have 2 webcontrols collecting dust and will never turn them on again. Yes they are cheap with abundant IO, but in reality all their IO is difficult to use, interfacing is a pain (yes the newest firmware makes it a little cleaner) and for me anyway, they have been terribly unreliable.

My CAIs 1-wire bus would drop out about once a week requiring a power cycle.

 

The new Pi solution uses a hardware 1-wire controller which has yet to crash on me. It also supports many more devices types and numbers.

With the Pi being a full Linux system the possibilities are endless on what could be added to it.

I personally run six "Link" programs on mine, a web-based remote control for my TV, NTP server, Samba server and it doesn't miss a beat.

[apostolakisl]

This would be the same concept as using the cai webcontrol, except you would be running an application on your raspberry pie instead of using a native function of the device. Also you would need the one-wire device instead of the on-board AD converter in the cai.

Personally I've fully switched to the Pi.

I have 2 webcontrols collecting dust and will never turn them on again. Yes they are cheap with abundant IO, but in reality all their IO is difficult to use, interfacing is a pain (yes the newest firmware makes it a little cleaner) and for me anyway, they have been terribly unreliable.

My CAIs 1-wire bus would drop out about once a week requiring a power cycle.

 

The new Pi solution uses a hardware 1-wire controller which has yet to crash on me. It also supports many more devices types and numbers.

With the Pi being a full Linux system the possibilities are endless on what could be added to it.

I personally run six "Link" programs on mine, a web-based remote control for my TV, NTP server, Samba server and it doesn't miss a beat.

 

I've got 10 of the boards, all with the firmware that can post direct to ISY. I haven't used the one-wire bus as I have no need for it. Mine never need rebooting. I think the latest firmware lets you use the one-wire ad converter, but I had no need for that as the CAI has built-in AD times 3. You can also put them in the can with Elk and power off of the Elk's 12v. If it is in a hot area, you might consider putting a bigger heat sink on it, but mine on the Elk power supply is in conditioned space so I haven't bothered.

 

Just FYI, I am/was using the CAI boards for testing/prototypes of an invention of mine. It was reading analog pressure transducers and reporting them to ISY. In the first version I was using your (ioguys) program to sync ISY with the CAI boards. I have since had a custom designed dedicated hardware device to do that instead which will be the commercial version.

 

But back to the OP. If you got rid of the programs cascading through via state variables triggering down the line and wrote them as a single stage program with all the conditions in a single "if" and all the actions in a single "then", I think you would eliminate your spurious values with no need for any new hardware.

 

EDIT: Come to think of it, I did have one-wire temp hooked up to a couple of the units. I don't recall that ever needed rebooting, but it was a secondary item that I was only roughly paying attention to.

[PLCGuy]

But back to the OP. If you got rid of the programs cascading through via state variables triggering down the line and wrote them as a single stage program with all the conditions in a single "if" and all the actions in a single "then", I think you would eliminate your spurious values with no need for any new hardware.

 

Maybe I am a little slow this morning, but I don't get how this would work. Can you explain?

[apostolakisl]

But back to the OP. If you got rid of the programs cascading through via state variables triggering down the line and wrote them as a single stage program with all the conditions in a single "if" and all the actions in a single "then", I think you would eliminate your spurious values with no need for any new hardware.

 

Maybe I am a little slow this morning, but I don't get how this would work. Can you explain?

 

 

I posted the program for 2.0 volts earlier. At present you are using a 3 step process (program) where a state variable is changed in the "then" clause which is the trigger for the next program. This is an unnecessary step which I am speculating is the reason for your spurious value (you might be getting multiple programs running true at the same time). It is impossible for the program below to trigger more than once per 5am or per pressing of f4. If memory servers me, Elk voltage is not a trigger, it is only checked once the other triggers (5am or f4) causes the "if" to execute.

 

This single program takes the functions you split into three programs and puts them all into one and eliminates the state variable trigger completely. By using parenthesis you can merge all the conditions into one "if" clause. You would need 81 of these (2.0 through 10.0 in .1 intervals). Just use the "copy" function on ISY, and copy this program 80 times. Then use the "find" function looking for "2.0" and each time you hit "find next" replace the value with .1 higher than the time before until you get to "10". Then repeat that for "20" going through and upping that by 1 each time till you get to 100". It should take nor more than 5 minutes.

 

If
       Elk Zone 'Water Level' 'Voltage' is 2.0 Volts   **this of course is different in each of the 81 programs
   And (
            Elk Keypad 'Main Keypad' 'F4' is Pressed
         Or Time is  5:00:00AM
       )

Then
       $WtrGallons  = $SlopeDiv10   *** see below
       $WtrLvl  = $WtrGallons   *** see below
       $WtrLvl *= 20   *** and this is also different to match the above voltage
       $WtrGallons -= $Offset
       $WtrLvl /= $GallonsPerInch
       Set Elk Area 'House' Display Text on Keypads, Content 'Elk_WaterLevel'

Else
  - No Actions - (To add one, press 'Action')

 

***I don't know what you were doing exactly using these two lines of variables passing values through from one variable to the next. Perhaps these are being altered at other times by other programs, but if not, they aren't serving any purpose getting passed through like that.