Jump to content

A Better Way to Get Analog and Digital Inputs to ISY


Flex

Recommended Posts

Right now you need both, I'm dying to move it to NodeLink but currently V5 does not allow you to compare two node values.

So you'd have to move the one-wire value to a variable to compare it to a thermostat temp for example.

Kind of useless.

 

Once V5 can compare nodes I'll move it over.

OK.  I'm fine with running both.  Thanks.

 

-Xath

Link to comment

Nope. Cost too much to get here and you couldn't afford it. :)

 

Sent from my SGH-I257M using Tapatalk

Right.  Sorry, forgot you are in Canuckistan!

 

-Xathros

Link to comment

Right now you need both, I'm dying to move it to NodeLink but currently V5 does not allow you to compare two node values.

So you'd have to move the one-wire value to a variable to compare it to a thermostat temp for example.

Kind of useless.

 

Once V5 can compare nodes I'll move it over.

Will this newer Sheepwalk 8 channel host adapter work with OWLink or should I order the older one like Larry posted?

 

-Xathros

Link to comment

Right now you need both, I'm dying to move it to NodeLink but currently V5 does not allow you to compare two node values.

So you'd have to move the one-wire value to a variable to compare it to a thermostat temp for example.

Kind of useless.

 

Once V5 can compare nodes I'll move it over.

Yeah. Right now I have a bank of cloning programs that do just that.

 

There are some advantages to that though. I have a central house.temp that all programs use.

 

Now I have multiple sources that can be averaged and/or back each other up so the value is very reliable.

 

Sent from my SGH-I257M using Tapatalk

Link to comment

Either will work. OWLink supports any adapter that supports OWFS.

Excellent!  I will go with the new one then.  Thanks again. :)

 

Note there is limited amount of Pi versions this will adapt to.

 

Sent from my SGH-I257M using Tapatalk

Assuming that was in reference to the newer multichannel OneWire adapter at Sheepwalk.  I did see that inthe info there and it will work with my Pi3Bs so I think thats the way I'll go.  And, it will still probably be cheaper than yours in the end! :P

 

-Xathros

Link to comment

Excellent!  I will go with the new one then.  Thanks again. :)

 

Assuming that was in reference to the newer multichannel OneWire adapter at Sheepwalk.  I did see that inthe info there and it will work with my Pi3Bs so I think thats the way I'll go.  And, it will still probably be cheaper than yours in the end! :P

 

-Xathros

Yes it was (in reference)

 

Some day I will get back to this idea so I don't want to part with it.

It seems like a RPi is going to become an arm of the ISY anyway and it would make a good finger for that arm.

 

Thanks for the offer/thought, though.

Link to comment
  • 1 month later...

What would be the hardware layer for the Modbus protocol?

 

Over Ethernet? ISY doesn't have any other hardware interfaces to input Modbus to.

 

Modbus could open a lot of doors for instrumentation but there are many protocols taking over from Modbus. DNP 3.0 and probably too many other ones that have become very popular, with more serious equipment, all field of endeavour culture dependent. I dealt with a lot of Electrical Grid P&C and Modbus was only a bad rumour that some of the early jumpers got stuck with.

 

Modbus may be an excellent level protocol for ISY people, though. The protocol interface should be easy to write. DNP 3.0 wasn't. 

 

Support for Modbus over either serial (i.e. EIA-232/485) or over Ethernet-TCP/IP would be fantastic. It would allow the ISY to interface to the world of micro-PLCs and I/O that is robust and cost effective.

 

As the title of this thread suggests, Insteon's I/O capabilities are primitive, especially for analog I/O. I tried to interface an ISY with a level sensor on a cistern and it wasn't a pretty experience. There is short post on this adventure at http://forum.universal-devices.com/topic/16335-isy-variables-and-elk-integration/ 

 

But IMHO, even digital I/O is over priced and under performing in the home automation world. Yes, one can buy something like the Smartenit EZFLORA Sprinkler Controller, but 8 DO for $125 is expensive. In contrast, there are a number of low cost PLCs available that are less expensive and have much more (and better quality) I/O. For example, the Velocio Ace 5150c PLC has 12 DI, 12 DO, 3 AI (0-20mA  :-)) AND a RS232 serial port that talks Modbus  :-). It retails at $135 and looks a lot like an Apple TV.

 

Schneider will sell you a Twido PLC with 16 DI, 16 DO and serial Modbus interface for $200. Even the Rockwell's Micrologix PLC family can be had for $300 if you know where to look. And all of these are a lot more reliable than most Insteon I/O products.

 

Now ideally Modbus over serial would allow the most cost effective connection to the the PLC world, as almost every micro-PLC supports serial Modbus natively (Rockwell being the exception). But since the ISY doesn't have a serial interface, Modbus over Ethernet would be okay too. It just means that the purchaser of the PLC has to either upgrade the micro-PLC to a version that has an Ethernet port or buy a Modbus Serial to Ethernet gateway. Those cost under $200. Regardless, the math works - for between $200 to $400, with Modbus support in the ISY, I could add an industrial grade 16-zone irrigation controller to my ISY, roughly the same price as two Smartenit EZFLORA Sprinkler Controller and a lot more capable. And I get a pile of DI and AI, real PID control and motion control capabilities all for free in the mix.

 

As for what protocol, Modbus is the only industrial protocol that ISY should consider. I have been responsible for the manufacture of industrial gateway and security products for over 20 years and while there is no shortage of industrial protocols like EtherNet/IP, DNP-3, ProfiNet/ProfiBus, IEC-104, etc, etc. Modbus is the protocol everyone falls back to when trying to interface different vendors control products. For every DNP-3 or EtherNet/IP gateway we sold, we sold 10 Modbus units. There is a lot wrong with Modbus (which is why protocols like DNP-3 or IEC-104 dominate the PT&D substation) but for ISY's market, I strongly suggest Modbus as the way to go. It is simple and every vendor supports it, whether they want to or not. 

 

Finally, if anyone wants help putting together a Modbus Node Server for the ISY, I'd be glad to partner on that. I have a mountain of Modbus documents and test tools from my industrial hardware days. I also know where the bodies are buried in that protocol.

Link to comment

For those looking for some nice digital and analog IO check out the BeagleBone Black. It's similar to the Pi but has some more interesting IO options including both analog in and a set of PRU controllers that can do things that the Pi can't come close to. It also has enough of a community that it isn't going to disappear like many of the Pi clones.

 

https://beagleboard.org/black

 

I picked one up a while back due to it having way more GPIO pins than the Pi and have it setting variables in my ISY via REST calls with their status. I've also used the PRUs to bit bang out control signals for individual addressable LED strips. I haven't used the analog inputs yet but they may be the next project.

Link to comment

For those looking for some nice digital and analog IO check out the BeagleBone Black. It's similar to the Pi but has some more interesting IO options including both analog in and a set of PRU controllers that can do things that the Pi can't come close to. It also has enough of a community that it isn't going to disappear like many of the Pi clones. https://beagleboard.org/black

I picked one up a while back due to it having way more GPIO pins than the Pi and have it setting variables in my ISY via REST calls with their status. I've also used the PRUs to bit bang out control signals for individual addressable LED strips. I haven't used the analog inputs yet but they may be the next project.

I searched the block diagrams and schematics and see no sign of anything analog inputs or outputs. Even a document search shows no matches for the word "analog".

 

Where are you finding this information about analog inputs and outputs that you mentioned?

How do you intend to get analog inputs into this board?

Link to comment

They are called AIN in some of the documents, 7 in total.  Pins 33, 35-40 on the P9 connector.  They allow 0-1.8V and are supposedly sampled at 12 bits.  There is also 1.8V available on pin 32 of the P9 connector.

 

Here are a couple articles with sample code on how to read them:

 

https://www.linux.com/learn/how-get-analog-input-beaglebone-black

 

http://www.toptechboy.com/tutorial/beaglebone-black-lesson-9-reading-analog-inputs-from-python/

 

http://beaglebone.cameon.net/home/reading-the-analog-inputs-adc

 

Edit:  here's a decent overview of the various pin configurations available:

 

http://beagleboard.org/Support/bone101/#headers

 

up to 65 GPIO pins, 7 analog, 4 UARTS, 8 PWMs, 2 I2C, 2 SPI, 25 PRU (driven by 2 independent 32-bit 200-MHz micro-controllers which you can download code into)

Link to comment

They are called AIN in some of the documents, 7 in total.  Pins 33, 35-40 on the P9 connector.  They allow 0-1.8V and are supposedly sampled at 12 bits.  There is also 1.8V available on pin 32 of the P9 connector.

 

Here are a couple articles with sample code on how to read them:

 

https://www.linux.com/learn/how-get-analog-input-beaglebone-black

 

http://www.toptechboy.com/tutorial/beaglebone-black-lesson-9-reading-analog-inputs-from-python/

 

http://beaglebone.cameon.net/home/reading-the-analog-inputs-adc

 

Edit:  here's a decent overview of the various pin configurations available:

 

http://beagleboard.org/Support/bone101/#headers

 

up to 65 GPIO pins, 7 analog, 4 UARTS, 8 PWMs, 2 I2C, 2 SPI, 25 PRU (driven by 2 independent 32-bit 200-MHz micro-controllers which you can download code into)

Now I see them on the larger schematics.

Strange, the docs hardly mention them except to indicate the pins on the header.

The block diagram totally doesn't show them like they don't exist.

 

I was hoping for something more buffered that I don't have to create another PC board to interface them to real world things. I already have a WC8 with unbuffered analogue/digital  inputs and outputs that interfaces to ISY without even writing code.

 

Thanks for the info though. It's getting more interesting as time goes on, for sure.

Link to comment

My NodeLink node server will have Modbus TCP support released this weekend. I'm running it right now with a Beckhoff BK9000.

 

Nice - if you want any simulators or the Modbus test suites, let me know. Or if you want me to test it with a number of different PLC's also let me know.

 

Now I see them on the larger schematics.

Strange, the docs hardly mention them except to indicate the pins on the header.

The block diagram totally doesn't show them like they don't exist.

 

I was hoping for something more buffered that I don't have to create another PC board to interface them to real world things. I already have a WC8 with unbuffered analogue/digital  inputs and outputs that interfaces to ISY without even writing code.

 

Thanks for the info though. It's getting more interesting as time goes on, for sure.

 

Beagleboards are definitely cool. When I am doing a one-off hobbyist project for myself they are great. But like larryllix, it is good to have something with well-designed buffered I/O when I want repeatability and reliability.  For example where we live, a lot of the homes are on well water and have large water cistern systems. Now I can use a SBC like Beagleboard for my managing own water system, but I sure don't want that for my neighbours system. I just don't want the support issues and yelling when something electrical fries on a long weekend in the summer. I want something that any qualified electrician can source and replace in a day.
 
And that is why I suggested that UDI consider some sort of simple interfacing module to the world of low cost industrial I/O and PLCs. It is not to replace Linux-based SBCs like Raspberry PI and Beagleboard. It is expand what is possible in the world of home automation, moving it from strictly hobbyist driven to wide spread adoption.
 
I also want to reiterate that industrial I/O and PLCs used to be stupidly expensive, but now they are price competitive with devices like the Beagleboard. Yes, I can buy a bare Beagleboard for around $60, but by the time I get a case, power supply and buffered I/O it is as expensive as many microPLCs. 
 
In fact, to go back to the title of this post "A Better Way to Get Analog and Digital Inputs to ISY", I suspect that the originator of this thread didn't even need a PLC - the ISY is already a great controller - reliable and easy to support. All that is needed is better digital or analog I/O connected into it. If ISY supported Modbus like it supports the Elk, then something like the ADAM-4055-BE with 16-Channel Isolated Digital I/O Module with Modbus (Serial) ($144.00 list) or the ADAM-6051-CE with 16-Channel Isolated Digital I/O Module with Modbus (TCP/IP) ($201.00 list) beats the junk like the IOlinc all the way to the bank. 
 
And for Analog, there are I/O products that beat anything in the home automation world. Sure something like the  ADAM-6017-CE with 8-Channel Analog Input Modbus TCP Module with 2-Channel Digital Output is a bit pricy at $324 list, but at least it works reliably, which is something the EZIO2X4 can not claim. (Adam is just an example - I don't have any connection to them - typically I buy Schneider's HW.)  
 

Hello PLCGuy,

 

All those should be easily supported by Polyglot. As a matter of fact, einstein.42 created a Poly that we now use to communicate with Outback inverters using Modbus!

 

With kind regards,

Michel

 

Thanks Michel - I'll take a look at that. Still I would love to see something that doesn't need more hardware, beyond the actual I/O module - it is just another point of failure. And especially worry about something like an RPI with an O/S that needs regular patching. What i like about your product is that it works for years without my attention - I have yet to have a ISY fail (PLMs are another matter). Reliable I/O that just plugs in and works, just like your Elk module just works with the Elk, would be a real gift to people who have I/O requirements beyond the light bulb and ceiling fan.

 

So all I am saying is that direct Modbus support could be a cheap way to get robust and reliable I/O into the ISY. 

 

That my two cents worth - please keep up the great work.

 

Regards

Eric

Link to comment

Nice - if you want any simulators or the Modbus test suites, let me know. Or if you want me to test it with a number of different PLC's also let me know.

 

Should be ok, MB is a pretty simple protocol.  Inputs, coils, registers.

I'm leaving it to the user to setup their device with standard address offsets and then you just specify the number of IO you have in NodeLink.

 

post-1310-0-95260400-1466193709_thumb.jpg

Link to comment

Nice - if you want any simulators or the Modbus test suites, let me know. Or if you want me to test it with a number of different PLC's also let me know.

 

 

Beagleboards are definitely cool. When I am doing a one-off hobbyist project for myself they are great. But like larryllix, it is good to have something with well-designed buffered I/O when I want repeatability and reliability.  For example where we live, a lot of the homes are on well water and have large water cistern systems. Now I can use a SBC like Beagleboard for my managing own water system, but I sure don't want that for my neighbours system. I just don't want the support issues and yelling when something electrical fries on a long weekend in the summer. I want something that any qualified electrician can source and replace in a day.
 
And that is why I suggested that UDI consider some sort of simple interfacing module to the world of low cost industrial I/O and PLCs. It is not to replace Linux-based SBCs like Raspberry PI and Beagleboard. It is expand what is possible in the world of home automation, moving it from strictly hobbyist driven to wide spread adoption.
 
I also want to reiterate that industrial I/O and PLCs used to be stupidly expensive, but now they are price competitive with devices like the Beagleboard. Yes, I can buy a bare Beagleboard for around $60, but by the time I get a case, power supply and buffered I/O it is as expensive as many microPLCs. 
 
<snippage>

 

Yup, just show me where the terminal blocks to connect my #14 cu wires are. I could care less about more GPIO headers that will take another six boxes and a rats nest of wiring to get make my voice controlled  neighbourhood community variable brightness street lighting work :)

Link to comment
  • 9 months later...

Thanks all for posting the I/O discussion.  I have quickly found that the home automation devices are not all reliable, manufacturers don't tell the whole story about their devices, or they are not universal enough to be recognized by all controllers (having tried several).  I too am looking for an easy way to get I/O connected to my ISY.  I have considered that for reliable I/O I need to write "interface" code for a computer to be a protocol translator using a ControlbyWeb device or equivalent industrial unit.  My thoughts are if I have to write code and employ a computer then I don't need the ISY.  The computer can talk directly to the PLM for light controls, directly to the interface for one-wire, 4-20, digital outs, etc., generate the GUI and any other features.  This is a big effort but do-able. I do like my ISY, it is reliable and solid but needs to be a bit more versitile.  I suspect that I will be tacking on single board computers to gather data and report back.  One does have to remember this is home automation and what is being discussed here, I believe, is a cut above.

Link to comment

ISY and the Insteon system of devices is very weak when it comes to analogue inputs.

 

Yes you could get a PLM and a computer and write your own home automations programs to replace about 12 years of software engineering, corrective bug and feature development feedback, maybe even do it better, but you will still need an IEDs (intelligent end devices) to do your information gathering and/or contact output controls.

 

I go through that same mental dilemna every so often, but having a lifetime of devlelop my own stuff experience, I would rather not re-invent the wheel, the tires, the spokes, the hub, or the mountings. I would rather hook to what is there and develop my own niches that I like better.

 

I like the nice compact boxes the manufactured devices come in and don't want a wire cluster on a desk anymore either.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...