One-Wire Module

[jca001]

I have seen a few other request for a way to read temperature from various places in their house and be able to act on the value in a program to turn on or off a ceiling fan or close or open curtains, etc... Others on the forum have presented their solution they have implemented but many require a full time PC which sort of defeats the concept of the ISY-99. Other solutions can get rather expensive, using an Insteon enabled wireless thermostat.

 

So I started searching (Googling) for an Ethernet to One-Wire devices because this would be the best integration interface for the ISY-99 since it does not have a serial interface to integrate with. I found some fairly inexpensive hobby grade ones for less than $75.00 and some more expensive ones for $300.00 and over. I found one that has been mentioned on this forum, HA7Net that was less than $200.00 and supported 100 One-Wire devices. But after further investigation I found out firmware development has been discontinued for it. But the company has another device called OW-SERVER for about $100.00, but only supports 24 One-Devices. I don't really see this as a problem because I don't think most people will even need that many.

 

The OW-SERVER can be polled via an HTTP request to get the configuration information and all the One-Wire device information, type, values, etc. It can also be configured to send the same information to a WEB server. The information is in XML format, which UD uses for their configuration information and would already have an XML API call to deal with it. The OW-SERVER has a WEB interface to do setup and get the status information. It also has a direct interface to the One-Wire buss to do more low level things such as setting values in some of the One-Wire device.

 

What I am purposing is an One-Wire (OW-SERVER) module that would be a lot like the ELK Module, but not as complicated. When I say it would be much like the ELK Module is there would be predefined tables for the One-Wire devices to select from in the IF, when writing programs. It would be good to have support for say 4 OW-SERVER devices so up to 96 One-Wire devices could be utilized. The OW-SERVER supports many different One-Wire devices, but UD would only need to support a few of them because most people only need temperature, humidity and maybe light. The polling could be done by the module so it could be a tune-able parameter on the ISY-99 and not have to set that up in the OW-Server. The poll interval could be from 1 to 60 minutes and if a value changed, it would trigger the evaluation of the IF in programs.

 

So lets hear from others if they think this would be a good solution and wants UD to work on this.

 

I did a quick look at the SDKs but did not see a way I could write my own module and load it. If I am wrong please let me know.

 

Maybe this or something like this is already on UD's road map for the ISY-99 or they have already decided the ROI is not worth it due to the amount of development and support time and the number of customers that would purchase the module at a reasonable price, somewhere around $50.00.

 

So Michel, Chris, (UD), please let us know if this is or is not possible. Maybe not exactly as I have stated, but a solution that will allow access to temerature readings that can be used in ISY-99 programs.

[apostolakisl]

CAI has told me that by this spring they will have the webcontrol 32 for sale. They are guessing the price is going to be about $70. It will have one-wire support and it will be able to post using REST. So, no module needed. Just set up the unit to post directly to variables in your ISY at whatever interval you like via REST. It will have built in PLC programming, but you could for the most part just right your programs in ISY and post to the unit using the network module.

 

It will also have a bunch of analog inputs, digital inputs, and digital outputs. A dedicated module would make using this easier, but the network module alone would suffice.

 

Of course, them telling me this is going to happen does not mean it is going to happen.

[TJF1960]

I would love for UDI to come out with a module for the WebControl board. Even if CAI does come out with the new board which issues Rest commands my feeling is the ISY module would be more interactive with the web boards. Plus I would rather not purchase new boards and worse spent days replacing them with the new ones.

Ever since apostolakisl first mentioned that board and io_guy wrote the interface program for it I have been using 3 in different parts of the house. The nice thing about the board is it has a number of inputs and outputs as well as 8 1-wire inputs and 1 humidity input. I have incorporated 3 webcontrol boards thru out the house. 1 controls my media server and back up servers and an EzEye from SHN is wired outside for daylight measurements as well as temps in different rooms of the house. One of the 1-wire inputs monitor my soft water pellet tank and emails me when it is low. Another controls all the home theater equipment + some other room temps and the 3rd controls the master bedroom a/v equipment and measures the temp in that room. Best of all all of this is done without flooding the AC lines with Insteon communication. The worst part for me is having to run my pc 24/7.

 

So my very biased opinion/wish list would be to see 3 modules from UDI:

 

WebControl board,

DSC Alarms,

Radio Thermostat / Filtrete wifi thermostat avail at Home Depot.

 

Jack, sorry I didn’t mean to hijack your thread,

 

Thanks

Tim

[jca001]

apostolakisl:

If you are saying CAI's new device will post to the ISY-99's REST, then it sounds like you would have to have a rule or what ever in the CAI device for each One-Wire device as to what you wanted it to post to the ISY-99, or many.

 

If you are saying CAI's new device will have a REST interface, then I don't see how this will help. From what I understand about the ISY-99 Network Module, is you can send a request with it, but you cannot read returned information with it. And if you can you would most likely have to parse it in some way which I don't see the Network Module being able to do.

 

If a PC has to be in between the CAI device and ISY-99, then as I said before that defeats one of the concepts of using the ISY-99 about requiring a PC all the time.

==========

 

TJF1960:

Yes a module to handle the current or the possible new device from CAI would probably work fine for my needs as long as it supported multiple of them. I can also see why you would want a Module for DSC Alarm like the ELK Module, I assume because you already have a DSC Alarm and could use some of its possible relay contacts or what every. I have an ELK M1, but not installed yet. And yes a Module for other thermostats would be nice. No problem about hijacking, it is still about the need to be able to access One-Wire devices without a PC.

==========

 

Overall what would be nice is to have several different modules to be able to have a choice on which one best fits somebodies requirements. But as I said earlier, UD has to take into consideration of ROI when developing a module, because if there is not enough purchases of it then they will not make any money on it will will drop it at some point or at least stop enhancing it or fixing possible bugs in it.

 

I hope others will chime in with their wants and needs and enough interest will be generated to make it worth while for UD to do something.

[Michel Kohanim]

Hi Guys,

 

I think a one wire solution is probably a good thing to invest in. The only problem is that current 99i hardware does not support it. 994 has an expansion slot with all sorts of I/O that we can use.

 

In the meantime, we have to find the easiest and least expensive way to get one wire working on the network.

 

 

With kind regards,

Michel

[jca001]

Michel:

Are you saying it would be best to implement a direct One-Wire interface on a ISY944i through its expansion slot and because it has more program memory space?

 

But in the meanwhile a module may be able to be developed that could be used by the ISY944i and the ISY99i, but determining which black box to interface with will take some research on you all's part to decide?

 

Or maybe more than one black box?

 

I went to the UD Web page and it has been change since the last time I was there and found the ISY944i can be bought from Bet Buy. I went to Best Buy and it is on sale for $269.99.

[apostolakisl]

apostolakisl:

If you are saying CAI's new device will post to the ISY-99's REST, then it sounds like you would have to have a rule or what ever in the CAI device for each One-Wire device as to what you wanted it to post to the ISY-99, or many.

 

If you are saying CAI's new device will have a REST interface, then I don't see how this will help. From what I understand about the ISY-99 Network Module, is you can send a request with it, but you cannot read returned information with it. And if you can you would most likely have to parse it in some way which I don't see the Network Module being able to do.

 

.

 

I have not used the REST interface on ISY before, but my understanding is that you can set variables and execute other functions on ISY via html REST commands. I assume this is how io_guys program sends values to ISY after querying them from the CAI unit.

 

CAI unit has a programming interface built-in (PLC). It has been explained to me that on the new board, this programming interface will be able to execute REST commands, posting information to other devices capable of accepting REST commands. The programming language is PLC which I have used exensively. It would be very easy to write a PLC program to execute a function on a time interval or a change in value status (like a temp change), or some combination of the above.

 

As it stands with the current CAI unit, ISY is capable of sending a command to it using its network module which could change one of its values (turn an output on or change a RAM value). From there the CAI's programming can execute whatever you like based on the fact that you sent a new value to it.

[Michel Kohanim]

Hello Mr. Allen,

 

Comments below.

 

With kind regards,

Michel

 

Michel:

Are you saying it would be best to implement a direct One-Wire interface on a ISY944i through its expansion slot and because it has more program memory space?

Yes. But the main issue is that we do not have yet even started on that path so it will require some HW/FW engineering. The other problem is that 994s enclosure does not have a protrusion to get anything into the system (except for holes for our Zigbee radio's antenna and LED).

 

But in the meanwhile a module may be able to be developed that could be used by the ISY944i and the ISY99i, but determining which black box to interface with will take some research on you all's part to decide?

And I think apostolakisl's information above is quite useful. If CAI can do all of this, then it would be quite easy to create network resources that can be downloaded into 99i/994i.

 

Or maybe more than one black box?

I do not think so! One should suffice as per the post from apostolakisl

 

I went to the UD Web page and it has been change since the last time I was there and found the ISY944i can be bought from Bet Buy. I went to Best Buy and it is on sale for $269.99.

Yes, they have a special ... but, please note that the Best Buy version comes equipped with Best Buy portal module so they might ask you to pay for subscriptions to their portal. If you want to purchase form Best Buy, you will have to ensure that either you are willing to pay for the portal subscription OR that you can get the unit without any subscriptions

[jca001]

I have not used the REST interface on ISY before, but my understanding is that you can set variables and execute other functions on ISY via html REST commands. I assume this is how io_guys program sends values to ISY after querying them from the CAI unit.

As far as I know that is true. From what I know about the REST interface to variable is it is done by an index number and not the variable name. This means you have to know the index number for the variable you want to do something to.

 

CAI unit has a programming interface built-in (PLC). It has been explained to me that on the new board, this programming interface will be able to execute REST commands, posting information to other devices capable of accepting REST commands. The programming language is PLC which I have used exensively. It would be very easy to write a PLC program to execute a function on a time interval or a change in value status (like a temp change), or some combination of the above.

I know this would work but it means more work would have to be done to use it. There are going to be those that have no idea how to do this. The device I have been looking only requires the general setup and no programming on it. All the One-Wire information is sent each time it is polled. All the ISY99i One-Wire module would have to do is pares it and match the unique ID number to what is in the table from the admin setup on the ISY99i.

 

As it stands with the current CAI unit, ISY is capable of sending a command to it using its network module which could change one of its values (turn an output on or change a RAM value). From there the CAI's programming can execute whatever you like based on the fact that you sent a new value to it.

This is good for operating relays and such, but does not help with getting the temperature values from the One-Wire devices back to the ISY99i. Plus the CIA only supports 8 One-Wire devices and the OW-SERVER supports 24. But is does not have any way to operate a relay except with one of the One-Wire devices.

 

I agree the CIA box is less expensive than the OW-SERVER but I think the OW-SERVER provide a simpler interface to the ISY99i if a module is created for it.

 

Just pointing out the plus and minus of one over the other in my opinion.

[jca001]

Michel:

Based on having to do hardware as well as firmware changes I think it would be easier and less expensive to just develop a module.

 

My concept on using the OW-SERVER and polling it say once a minute and parsing the returned information which is in XML format and matching the One-Wire ID number to what has been setup in the ISY99i. Check if the temperature value has changed and if it has cause a trigger event.

 

When I ask if more than one block box, it was the idea of having multiple modules, one for say CIA and one for OW-SERVER. The customer could purchase which one they need based on which black box they decide to use based on their need. Then each module would not take up as much space as if one module tried to interface to several different black boxes. Either way the module would need to support multiple of the same type black boxes.

 

That is good to know about the ISY944i from Best Buy. But it really does not matter at this time because as you have stated the current model does not have a way to connect a One-Wire buss anyway.

[apostolakisl]

We can wait and see when/if the new cai32 comes out and just what it is capable of doing.

 

I agree, a module would be nice and easy with drop downs in the programming page for whatever you wanted.

 

The issue as I see it is that UD is kind of a small co. I have no idea how many engineers and programmers they have, but I gather it is only a few. The market for this stuff probably just isn't big enough to support a huge UD operation. And this kind of a module isn't going to be a huge draw even out of that small market.

 

So, in short, I suspect we are going to be on our own on this one.

 

PLC is not that hard of a language to learn. I learned it in a few hours and I have minimal programming experience (aside from learning basic in high school 25 years ago, Elk rules and ISY programs are it). PLC also cut's and pastes like regular text, so if just one person developed the code it could be posted into the forum for anyone to cut and paste into their own CAI unit. Just change a few values to post into ISY at the variable ID locations you want.

 

You would only need the network module if you wanted ISY to be able send commands to CAI. Again, a cut and paste template could be posted from which you just change the IP address and the memory location on CAI you want to post to.

 

The current CAI board is probably the cheapest thing out there right now for getting 8 ttl outputs under the control of ISY. The 32 board I believe is going to have either 16 or 32 outputs. I don't know how many one-wire devices it will accept, I have to assume at least twice the current 8.

[Michel Kohanim]

Mr. Allen and apostolakisl,

 

I agree with both that currently the best approach is a CAI type of device. The main problem I see is that it's a piecemeal solution: if you do not have the same exact configuration as someone else who has the code, then you will have to spend hours trying to get the most basic things to work.

 

The question I have for apostolakisl is what would it take to make CAI a generic type of I/O that ISY can communicate with over the network and be notified of events. For instance:

1. The user registers a CAI to ISY (let's ignore the details for now)

2. ISY goes to CAI (through TCP) and says: give me your configuration

3. CAI returns the number of inputs/outputs and the range of values for each input/output

4. ISY says OK and creates:

--a. REST mapping rules for each input/output (say a node) which is used by CAI to notify ISY of changes

--a. Includes CAI nodes into ISY programs the same way that we currently do for almost everything else

5. For ISY to CAI communications, we can agree beforehand on a syntax; say: node/command/param ... i.e. 1/ON or 1/ON/50 etc.

 

This way, then, whoever implements the CAI boards could also make money by selling the full generic solution.

 

With kind regards,

Michel

[apostolakisl]

Mr. Allen and apostolakisl,

 

I agree with both that currently the best approach is a CAI type of device. The main problem I see is that it's a piecemeal solution: if you do not have the same exact configuration as someone else who has the code, then you will have to spend hours trying to get the most basic things to work.

 

The question I have for apostolakisl is what would it take to make CAI a generic type of I/O that ISY can communicate with over the network and be notified of events. For instance:

1. The user registers a CAI to ISY (let's ignore the details for now)

2. ISY goes to CAI (through TCP) and says: give me your configuration

3. CAI returns the number of inputs/outputs and the range of values for each input/output

4. ISY says OK and creates:

--a. REST mapping rules for each input/output (say a node) which is used by CAI to notify ISY of changes

--a. Includes CAI nodes into ISY programs the same way that we currently do for almost everything else

5. For ISY to CAI communications, we can agree beforehand on a syntax; say: node/command/param ... i.e. 1/ON or 1/ON/50 etc.

 

This way, then, whoever implements the CAI boards could also make money by selling the full generic solution.

 

With kind regards,

Michel

 

Michel,

 

I can't speak to the as yet unreleased webcontrol 32. This is from CAI:

 

"Thanks for your question. WebControl board we are selling now is a 8 bit board. We are also developing a 32bit WebControl32 board that may come to market early next year. Current WebControl board which we call it WebControl8 has 8 of everything, temp sensor, input and output, VARs.

WebControl32 will have 16 of everything, double the I/O. Of course, its cost will be higher, too.

 

We have little code space left in the WebControl8 board that we can add more temperature sensor, or I/O. But we are thinking maybe reserve that space for support LCD and kaypad. The LCD and keypad will be attached to the 1-wire bus. Then through PLC programming, you can display your own defined message on LCD, and push the 12 button keypad to enter your own code, like those alarm system, or for machine control purpose."

 

The current unit can have all the values querried one at a time or the whole lot at once. You only need the cai's IP/port (not password protected).

 

Example:

http://yournamehere.dyndns-server.com:y ... getall.cgi

 

returns:

3.01.05 1 0 0 1 1 0 0 0 0x19 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.0 F unbound unbound unbound unbound unbound unbound unbound fail unbound unbound unbound unbound unbound unbound unbound 000000000000 000000000000 000000000000 000000000000 000000000000 000000000000 000000000000 000000000000 287380030300 000000000000 000000000000 000000000000 000000000000 000000000000 000000000000 000000000000 0 % 0 0 0 0 12/13/2011 08:48:02 12/13/2011 08:48:02 192.168.1.15 00:22:12:02:00:7C02 WAREHOUSE

 

Or

http://yournamehere.dyndns-server.com:y ... etvar1.cgi

 

returns: the value of variable 1

 

The new unit will have post as a function. But, the current unit could just be querried every so often. You would ovbviously not get an instant response to a value change this way, but, depending on the application, once per minute may be plenty. ISY would be responsible for querying the cai. Perhaps this is set by a program

If

 

Then

query cai

wait 1 minute

repeat

 

The module might be set up to parse the "getall.cgi" and plug all the values into built-in nodes. Or, it could do all the individual get commands and not need to parse.

 

 

As far as setting variables and outputs on CAI. I forget the command. I know for sure it is possible as there is an iphone app that does it. At this particular moment, I can't seem to find that info.

 

So, to your points:

1) IP/port number is all you need

2-3) The configuration would always be the same for all units. There are 8 variables (32 bit), 8 temp readings (xx.x), one humidity (xx.x), 8 outputs (1 bit), 8 analog inputs (10 bit), 8 digital inputs (1 bit). It also has a time/date values which you can querry, it's mac address, it's ip address.

4) So ISY module would just have the above stuff built-in, no need to create for each unit since they are always the same.

5) Not exactly sure on this one.

[io_guy]

The syntax for setting the WebControl outputs can be found in WCLink. I added a generator to make it a little easier.

 

Making an ISY module for the WC should be fairly straight forward (but you would have to poll). As apostolakisl said, the single cgi webpage provides all available data in the WC. That's all I do with WCLink - poll the page at a configured interval and parse.

[jca001]

Michel:

I see apostolakisl has already answered your questions but I will add my 2 cents. Below I may when answering a question actually answer the next question by providing addition information and thoughts as they come to me. I have not taken the time to figure out how to use the Quote and add name so I am going to use my on format here.

 

==========

I agree with both that currently the best approach is a CAI type of device. The main problem I see is that it's a piecemeal solution: if you do not have the same exact configuration as someone else who has the code, then you will have to spend hours trying to get the most basic things to work.

[Jack Allen]

You may be talking in generic terms here when you say a CAI type device. But I think apostolakisl and io_guy are using the CAI device and would rather keep using it. I don't blame them. I like some of the features of the OW-SERVER better. This is the reason I have stated a couple of times it would be nice to have multiple modules so we have a choice and are not tied to only one solution and limited by its features. I think there are ways to get around people having different configurations. With what apostolakisl has provided about getting all the information with one request, the information is always laid out the same way. In the CAI device the user assigns which One-Wire device they want to be associated with which One-Wire slot number. So all the ISY99i pull down menu for the IF would have to do is present the slot number, very much like the ELK setup does now by just showing zone numbers. (I am going from memory on this).

==========

 

The question I have for apostolakisl is what would it take to make CAI a generic type of I/O that ISY can communicate with over the network and be notified of events. For instance:

1. The user registers a CAI to ISY (let's ignore the details for now)

[Jack Allen]

I don't see the module doing a registering per say, but providing the URL for the CAI device or the OW-SERVER. This would be the name if there is a local DNS that can resolve the name to an IP Address or the dot notation IP Address. The port would also be needed. Again a key thing that I have stated several times, but I feel has been glossed over is it needs to support multiple Ethernet to One-Wire black box. I am not stating different versions, but multiple of the same kind. As apostolakisl has stated he has 3 CAI devices.

==========

 

2. ISY goes to CAI (through TCP) and says: give me your configuration

[Jack Allen]

For both devices CAI and OW-SERVER this seems to be easily done with one request. The CAI device returns a smaller and simpler laid out format, space separated fields. This makes it easy to map a field for one of the One-Wire devices to an internal value that could cause a trigger event. Where as the OW-SERVER returns an XML format that would have to be parsed and then the unique One-Wire ID looked up to be able to map its value to one of the 24 slots that would have had to be setup in the ISY99i by matching on the ID the user specified. Again this would have to be done for each instance of the device. At this point I would suggest limiting the number device to 4 or 5. Let say it is 4, then for the CAI device this would give 32 One-Wire devices and for the OW-SERVER would give 96 One-Wire devices. With the CAI device the other input could also be used, but I think changing any of the output should be done through the Network module. Speaking of the other inputs the CAI device has, the OW-SERVER support more than just temperature One-Wire device. This may mean the type of One-Wire device would also have to be in the ISY99i setup.

==========

 

3. CAI returns the number of inputs/outputs and the range of values for each input/output

[Jack Allen]

See 2 above.

==========

 

4. ISY says OK and creates:

--a. REST mapping rules for each input/output (say a node) which is used by CAI to notify ISY of changes

[Jack Allen]

This may be nice, but I think just polling the device, CAI or OW-SERVER would be easier and be sufficient. The polling time should be parameter and for each instance of the Black Box. There should be limits on the polling time, not less that 15 seconds and not more than 900 seconds (15 minutes). I don't see polling the Black Boxes as causing too much network activity. You will have to way in on the affect to the ISY99i CPU utilization maybe being a problem or memory used. Because the ISY99i would have to keep a table of the values and after the poll compare them and if there was a change update the table and trigger an event.

==========

 

--a. Includes CAI nodes into ISY programs the same way that we currently do for almost everything else

[Jack Allen]

I think this is basing things on the new CAI. Again I don't think this is need if the ISY99i One-Wire Module just polls the Black Box for the information. We should use the Network Module to cause changes or do what ever to the Black Box. As with the CAI device, the outputs that can be controlled should be done this way and not through the One-Wire module it self. Yes this means we would have to have the One-Wire Module and the Network Module, but only if we wanted to cause a change on the Black Box. If just reacting to the change of the value of a One-Wire device or other input the Black Box supported, it could be turning on/off an Insteon light or doing something via the ELK Module, etc, the way changes are done now.

==========

 

5. For ISY to CAI communications, we can agree beforehand on a syntax; say: node/command/param ... i.e. 1/ON or 1/ON/50 etc.

[Jack Allen]

Again I see no need in this. The One-Wire Module or if you want to call it the CAI-WC Module or OW-SERVER Module, should only be getting the status of the device they can read, analog and digital and One-Wire inputs. The Network Module should be used to cause changes in the Black Box.

==========

 

 

This way, then, whoever implements the CAI boards could also make money by selling the full generic solution.

[Jack Allen]

I am not sure what you mean here. Maybe like some of the other 3rd party things I guess.

==========

[apostolakisl]

A point that I think is worth making:

 

Since this device is a network device (not a PLC device), it expands the controllable world of the ISY to anyplace that has an ethernet connection. I suppose that could also be said for the Elk module, but purchasing an Elk system/module just to turn a few things on and off at your remote location is not very appealing. With a CAI you can monitor and to a limited extend control things over the internet for very little money.

 

The CAI also has x10 functionality so you could really control quite a lot (provided you trust x10). It would be a little roundabout to control x10 but very possible. You would need to write programs on CAI that responded to setting variables to trigger x10 events.

[johnnyt]

Biggest problem with the CAI board is the limited number of humidity sensors - one per board. I would need 7 boards to do what I'm doing now around humidity, i.e. control bathroom fans, humidifier, HRV, AC, area dehumidifier, which all together provides a big dividend in terms of house health and family health (particularly for those living in areas where humidity varies a lot.) See this post for a slightly longer version of the story http://forum.universal-devices.com/viewtopic.php?f=27&t=7485&p=56950&hilit=biggest+bang+buck+IMO#p56950

 

From what I've read (quickly), the OW-SERVER would be better than the CAI board. It even does humidex (something I use all the time in summer and have to calculate right now using a formula that I think might be hard to pull off with ISY - I could be wrong though). And the sensors come in enclosures. For the solution I have now, I had a heck of a time finding vented enclosures (had to get custom one$) and ended up hiding some behind cold air return grills to keep the cost down to only "a lot" more than I want to spend...

[Michel Kohanim]

Hi all,

 

apostolakisl and Mr. Allen:

1. Polling may quickly become a bottleneck

2. I agree that we should have multiple solutions

 

So, perhaps it would be best for UDI to come up with an interface specification and then let others implement. I am a little hesitant in supporting polls. So, I think the minimum requirement would be for CAI or OW-Server to be able to post to a URL.

 

The question is would there be any interest in the community to develop these devices?

 

Also, apart from simple I/O, what else can be controlled and measured by these devices?

 

With kind regards,

Michel

[io_guy]

The question is would there be any interest in the community to develop these devices?

I've been debating working on an IO device for quite a while now. If I have time in the Spring I may put something together based on .NET Micro and maybe Gadgeteer. A little expensive but easily to develop and a ton of IO.

I'm thinking maybe 16 DI, 8 DO, 8 Relay, One-Wire and 2-4 RS-232. All IO changes would be pushed to the ISY via REST.

 

Also, apart from simple I/O, what else can be controlled and measured by these devices?

With ethernet and RS-232 the flood gates are open. Additional software modules could support other devices, such as building DSCLink into it (or any serial device). I'm still debating this though since the complixity of custom device support and modules will greatly increase development time. I guess it could always be included in a future software upgrade.

 

The hesitation for me is that it wouldn't really do anything new that running custom apps on a 24-7 computer doesn't do for me now (I don't care about the running computer). If it still communicates by setting standard variables, it's really no more integrated.

[apostolakisl]

Also, apart from simple I/O, what else can be controlled and measured by these devices?

 

 

With analog inputs, tons and tons and tons. For example, I have developed a system for measuring how much beer is in my keg using a 0-5v pressure transducer. There are all kinds of devices that measure pressure, temp, weight, power, brightness, "wettness", and on and on that return an analog voltage corresponding to the magnitude of the measurement. A stroll through digikey.com will amaze on what you can buy for typically a couple bucks.

 

Digital inputs are just a bit simpler but same idea. With a big enough I/O board, you could turn ISY into an alarm system for example.

 

The most basic need from the standpoint of getting the data into ISY is a way for ISY to be able to parse out values and stick them into variable slots or dedicated nodes. For cai, ISY would have to query the device (no problem there using network module as is) and then the hard part, accept the returned data and plug it into a usable memory location on ISY.

[jca001]

Hi all,

 

apostolakisl and Mr. Allen:

1. Polling may quickly become a bottleneck

2. I agree that we should have multiple solutions

 

So, perhaps it would be best for UDI to come up with an interface specification and then let others implement. I am a little hesitant in supporting polls. So, I think the minimum requirement would be for CAI or OW-Server to be able to post to a URL.

 

The question is would there be any interest in the community to develop these devices?

 

Also, apart from simple I/O, what else can be controlled and measured by these devices?

 

With kind regards,

Michel

 

1. Polling could become a bottleneck only if the time between each poll is too small like a few seconds. This is the reason I stated it should be a parameter and there be a lower and upper limit. I am pretty sure both devices poll the One-Wire device and store the results in its memory which is where the information would be returned from when queried via the http request. This should be almost instantaneous, and then I would think it would only take a fraction of a second for the ISY99i to process it. As far as temperature and humidity reading are concerned I would think polling once a minute should be sufficient. For input readings that may be used to indicate a button was pressed would need a much more frequent polling. But there again maybe this is a restriction for a use of this type of interface. On the CAI-WC the PL programming could be used to handle some of this and then the ISY99i could just use the results of the query that I think contains the value of the 8 (I think it is) variables and outputs which could be in the IF pull down menu for testing.

 

2. Well we seem to be agreeing on something at least.

 

As far as what else can these black box devices do I will try to list what I know about each.

 

CAI-WC:

8 digital inputs

3 analog inputs

1 humidity input

8 One-Wire temperature inputs

8 digital outputs, can be used to control relays

 

With no PL programming the above can be read and controlled directly via http request. With some PL programming a lot more can be done on the device itself.

 

OW-SERVER:

24 One-Wire device, which can be temperature, humidity, relays and some others

 

Because I am looking for something to read temperature and humidity I have not investigated much about the other One-Wire device it can use.

 

So both have there place depending on the users requirements. As one person has already stated they have a need for multiple humidity device, this would mean the OW-SERVER would be best for them. Another person stated they did not want to install an ELK M1 system just so they can detect contact closers and operate relays, so the CAI-WC would fit their needs best. And then I am sure there will be other that could use bot in some way.

 

I think taking a stance that the other vendors should change to interface to the ISY99i via its REST means it will not happen. One vendor CAI, says they already have plans to do something like that, but when will it really happen and then it means a lot of setup on that device to interface to the ISY99i. And their firmware is not customer up-gradable, you have to send the device to them and it cost $15.00 for the service and $5.00 fro shipping. As fare as I know the OW-SERVER is customer up-gradable. I still think it would be easier for UD to develop modules for block box device than to get the black box vendor to interface to the ISY99i. They already have an API per say, http request, to get information from it and to make changes to it.

[Michel Kohanim]

apostolakisl and Mr. Allen,

 

So, in short, we just need a network based I/O solution with a lot of analog input and at a reasonable price.

 

Let me do more investigation and see what would be the best possible approach that would meet my requirements (no polling) and yours. Perhaps, in the meantime, ioguy decides to develop his own and then we will all be much happier!

 

With kind regards,

Michel

[apostolakisl]

It might be possible to alter the firmware on a CAI board to enable posting, but I think they don't have the memory space. The new model will as I have been told.

 

CAI is not unlike you guys at ISY in that they actually will respond to inquiry. Wayne is someone at CAI who I have had a number of conversations with. If they were willing to do a custom ISY firmware for the unit, it might be good for both co's.

 

As far as cost, I dont see ever beating $35 for the CAI. I don't know what the other board costs.

[Michel Kohanim]

Hello apostolakisl,

 

I would very much like to talk to Wayne. Would you be kind enough to do the introductions?

 

With kind regards,

Michel

[MstrD]

I know this thread is a couple weeks old, but I'm in the process of integrating a one-wire network with my iSY-99. Mainly for temperature sensors. It's somewhat of a hack, but opens up a bunch of doors.

 

I purchased a Linksys NSLU2. (These go on eBay for about $30) It's a small server with 2 USB ports and designed to place it on your network and then you add in a flash drive, or USB hard drive. There is a whole community that has modified these. Internally it runs a version Linux.

 

More information here: http://www.nslu2-linux.org/

 

It's really small. Smaller than what a Walkman used to be (don't know what other size reference). There are directions on that site to load a modified Linux firmware. The update takes about 10 minutes max. I did the simpler of the mods (unslung). It retains all it's original functionality (becomes a network drive), but, you can access Linux as well. I'm not a Linux guy, but I was able to play around with it. There are all kinds of software modules already written. In particular to temperature sensors is a program called Digitemp. It can read and log temperatures, among other things.

 

The process can be automated as well, and it can post a REST command back to the iSY-99. At the moment, I also have a script that goes out to google weather (or yahoo, I can't remember), grabs the current conditions by zip code, and then updates the current temperature to a varibale on the iSY-99. The one-wire can also get the internal temp, by zone, and then update variables as well.

 

You can create a CGI program on the NSLU2, and have the iSY-99 start (poll), a request and have the NSLU2 REST a command back.

 

It's also added audio (with a USB controller), which once I get it setup, will be controllable from the iSY-99, and tied to my whole house audio (also controllable via Network Resources). I'm planning to use pre-recorded messages, but I've also been able to use google translate to convert text to speech, store the MP3, and then play it back. It's going to allow the weather forecast to be read over the audio system. Also wake up calls for the kids.

 

I've also thought about grabbing live data (sports scores, news headlines, etc.), and connecting in a scrolling LED sign in my basement bar area.

 

I'm also going to implement a bluetooth proximity program, that, I hope, will be able to tell the iSy-99 when anyone in our family with an iphone arrives home.

 

I'm thinking that ultimately, I'll let the iSy-99 be the brain, and let the NSLU2 be the muscle. Or Conductor / Band. Pick your analogy.

 

This isn't exactly Plug and Play, but it does open up a world of doors, and it's only $30. It's technically, still a computer, but then again, so is a dedicated ethernet one-wire board. It's well worth it just to play around. I think between the 2 units, I can do everything I need to. Once I get some scripts finalized, I'll post a thread with them so other non-Linux people like me can use them.