Barionet + Elk M1

[Lagerhead]

This post follows Dan's suggestion that I describe the Barionet programming interface. I am using a Barionet with an Elk M1 as the core of my automation and have been pleased with the combination.

WHAT IS A BARIONET?

The Barionet is a PIC processor combined with a Lantronix Xport in a single unit, with a good range of onboard I/O as part of the package. In short, it is a small computer having the whole range of communications, and digital and analog I/O, built-in. Its major design weakness is a serious lack of persistent (disk-like) storage.

General Hardware Specifications
- Made by Swiss company Barix AG
- power 9-30 VDC/AC
- Ethernet port, 8 sockets supported
- RS232 and RS 422/485
- 4 digital inputs w/ programmable pull-up
- 4 digital or analog (9-bit resolution) inputs
- 4 digital outputs (current sinking)
- 2 relays, SPDT, 5A
- 1-wire temperature sensors, 8 direct attach
- Modbus I/O expandable
- Real-time clock with NTP and/or 1-wire RTC capability

The Barionet has been misunderstood and mischaracterized on this board. It has been called a PLC (and equated to the Ocelot), but it can do much more than that. It can work with HA applications or, with suitable programming, it can to a certain extent replace them, as I have done.

WHY BARIONET?

The Barionet is an unusual piece of hardware, not for everyone (I think three out of around 6,000 CT members). I wanted a low-power HA solution with flexible and expandable I/O and strong communication capabilities, particularly IP. My house now can run with all PCs and servers turned off, which was a long-time goal of mine. (I should note here that entertainment functionality is not a factor in my environment.)

The Barionet basically has become my HA app. I use it for 24/7 polling of my thermostats and M1-monitored conditions, for data aggregation and upload, for command and control from inside and outside access, weather forecast download and many other functions. Like any good HA solution, it provides the necessary HA integration by bridging the gaps between different devices and technologies.

But realize that the Barionet, as shipped, does none of that. This has been entirely a custom development effort, and getting there has meant some considerable programming, in my case 1,200 lines of code and continuing to grow. And because the Barionet has essentially no persistent storage capacity, I offload collected data to an outside, hosted website, where I have additional PHP code for interfacing, reporting and analysis.

There are some on CT who have criticized this kind of "clean-slate programming" as a waste of time, pointing out that many fully-developed and robust software alternatives (HomeSeer, Premise, CQC, etc.) already exist. That's fine, although because of the Barionet's I/O features, the criticism is not fully on the mark. The security of my network was another important factor in my thinking. We all have our preferences and make our choices how to use our time. So I will simply say, while it has worked out well for me, this is not a recommendation or an endorsement -- unless you fully understanding what you're getting into. Having said that, I am still amazed at what this little thing can do.

Programming sample in following post.

Barionet Pros
- 2 watts (typical) in my environment
- easily powered from M1
- no moving parts (other than relays)
- decent support from manufacturer in Yahoo group
- decent support from U.S. distributor Datanab
- excellent I/O expansion capability
- provides the analog inputs that M1 lacks
- wide-open programmable communications

Barionet Cons
- totally proprietary
- second-generation-style BASIC programming language
- no structured programming environment
- specific limitations in programming space and features
- single thread execution (no multi-tasking)
- sometimes difficult debugging (uneven diagnostics)
- essentially no onboard storage (some flash memory may be used for persistent storage, but R/W fatigue is a real consideration)

Info:
http://www.barix.com/Overview/781/
http://www.datanab.com/controllers/barionet.htm

 

[Lagerhead]

BARIONET PROGRAMMING

The Barionet is functional as shipped. With no additional programming, the supplied (built-in) web pages can control the unit's I/O. You can also customize or create entirely new web pages to control the unit's I/O and exploit some of the unit's other features. You design these pages and load into the Barionet. I have not used either of these as they are not useful for my purposes.

To do anything more you need to write BCL code. This opens the way to accomplish all sorts of general-purpose functions, with or without associated web pages, and with or without actually using the Barionet I/O. This is the only way to build interfaces to the M1 and other network-attached devices.

The Barionet "development model" and the "debugging model" are illustrated below. A code sample for M1 interfacing follows.

[codebox]
' == OPEN ELK M1 ASCII PROTOCOL SOCKET ==
OPEN "TCP:xxx.xxx.xxx.xxx:xxxx" as hM1
IF CONNECTED(hM1) THEN
SYSLOG "Connected to ELK M1G"
ELSE
SYSLOG "Not Connected to ELK M1G"
ENDIF
. . .

' == TEMPERATURE ACQUISITION SUBROUTINE ==
1000
WRITE hM1,"09st01500BA\r\n",0 ' poll M1ZTS temperature
tov = _TMR_(0) ' protective timeout
1001
READ hM1,M1R$,0
IF LASTLEN(hM1)>0 THEN RETURN ' got M1 response in M1R$
IF _TMR_(0)-tov<2000 THEN GOTO 1001 ' loop within 2-sec response limit
M1R$ = "TIMEOUT"
RETURN
[/codebox]

 

[signal15]

This is interesting. How much are they?

 

[signal15]

Looking around, I really like the idea of some form of Linux or BSD running on something like this:

http://www.gumstix.com/store/catalog/motherboards.php

They are cheap, low power, and you'd have all sorts of crazy capabilities that you currently do not have with custom hardware. Hook the thing up to some digital or analog I/O boards via RS-485 or something else, and you've got yourself an extremely powerful platform. You could even utilize Barionet devices as remote digital/analog I/O devices over a local network or even the internet. Plus, you could do your scripting/automation rules in a more mainstream language (perl, ruby, python, TCL, etc).

 

[Lagerhead]

Looking around, I really like the idea of some form of Linux or BSD running on something like this. . .

Right. As I said in my original post, "We all have our preferences and make our choices how to use our time. So I will simply say, while it has worked out well for me, this is not a recommendation or an endorsement. . ."

This thread is at Dan's request (see discussion) and is meant to deal with the Barionet. I am sharing my experience for those in the CT community who are interested.

 

[electron]

This is some GREAT info, thanks for posting this! Does your M1 'driver' support generating the CRC for the M1 commands?

 

[Lagerhead]

Does your M1 'driver' support generating the CRC for the M1 commands?

Here is the checksum routine.

[codebox]' M1 CHECKSUM FUNCTION
' Enter with work$ having the command string, less checksum
' Return with work$ ready to transmit to M1
'
cc=0
FOR i = 1 to LEN(work$)
cc = cc - ASC(MID$(work$,i,1))
NEXT i
work$ = work$ + MID$(SPRINTF$("%04x",cc),3,2)
RETURN
[/codebox]

EDIT: Simplified the code. Ignore the complexity in the ELK manual. The checksum is nothing more than a running arithmetic subtraction.

 

[electron]

This is very cool. Is there a cheap way of adding more serial ports?

 

[Lagerhead]

This is very cool. Is there a cheap way of adding more serial ports?

I doubt it. I don't see it available, but I'm not sure. Every other kind of I/O expansion seems to be available -- analog, digital and relay boards in various mixtures and sizes. Also, most or all Modbus-compatible gear can be attached. Ironically (in my case, because I don't need them), Barix has a broad array of audio streaming products.

 

[vanoorta]

you could use additional barionets or other ip to serial converters to add additional "networked" serial ports that are controllable by the barionet.

also, the current barionet firmware now supports up to 50 1-wire temperature sensors. we have a nice variety of compatible sensors if anyone is interested.

There will be a new low cost version of the barionet coming out soon called the barionet-50. List price will be approx $150, which is half of what the standard version is. About the only thing that won't be included is the analog inputs, but they are adding a couple of relays. So there will be 4 dig ins, 4 relay outs, 1-wire temperature bus (with screw terminals), RS232, RS485, ethernet, programmability, etc.. And if you want analog inputs you could always add one of our Ai8_R13 modules which would give you 8 universal inputs and 13 additional relay outputs.

Lastly, "Lagerhead" is correct in saying that there are ways to expand pretty much all of the interfaces. We've programmed the BarioNet to talk Modbus-RTU to all of our Modbus I/O devices and temp/humidity sensors, as well as a host of other 3rd party devices. If it talks modbus-rtu or Modbus-TCP then the barionet can communicate with it.

Adam
DataNab LLC

 

[electron]

Welcome to CT, Adam! Thanks for the info, I saw a reference to the barionet-50 on their site but didn't realize it would be much cheaper.

I guess I need to figure out a way of adding cheap serial ports (I would like to interface my W800RF32 and Ocelot).

Lagerhead, have you noticed any delays, now that you have so many lines of code (all compiled I assume)?

 

[Lagerhead]

. . . have you noticed any delays, now that you have so many lines of code (all compiled I assume)?

The code is complied ("tokenized") and even with that much code I am using less than 20% of the available program space.

There are no performance issues whatsoever. It mostly loops in the idle state waiting for the next trigger. Response to an M1 zone change (for example) is immediate. Web page service and response is immediate. Response to X-10 input commands (routed via the M1) is immediate, after allowing for the PLC delay of course. My polling and upload cycle runs 160-200 msec including transmission, and this occurs only once every six minutes. In short, there is far more processing capacity than I can use. I should say that I have taken steps to economize the code based on my [undisclosed] years of programming experience and, because of the single-thread limitation, I have structured the program not to get trapped in long tasks.

Another CT member (RHughes) has had the same experience.
http://www.cocoontech.com/forums/index.php...st&p=107178

I must acknowlege again that I have some differences, probably significant ones, with many CT members, that make the Barionet appropriate as the basic HA application in my environment and maybe not for others. I do not need to satisfy a range of users, just two in my household. I do not need the user interface power that the full HA applications provide. We are satisfied that weather forecasts, for example, are displayed simply by the Barionet on the M1 bedroom keypad. And as I have said, there are no home theatre or other entertainment components in my mix. I am comfortable with TCP and native HTTP and have used these extensively to link the Barionet with my hosted website. There, I do my own graphics, plotting, and data presentation in PHP, which is impossible on the Barionet. A portion of this is customized for my Blackberry. This approach also allows me to hide everying behind the firewall, with the Barionet responding only to very specific, verified requests.

And not indicidentally, when you take this approach -- as you certainly know -- you also have to find and then code for all of the many error conditions that can arise. The (U.S.) National Weather Service XML forecast service has some undocumented behaviors, for instance. Simple local TCP sessions can fail in a surprising number of ways. This can be frustrating and tedious, but I now have a very stable and reliable base that meets all of my most important requirements and can accommodate many more.

Dave

 

[rhughes]

Hi,

Although not directly related to the Elk M1, I've programmed a Barionet to extend my lighting automation. I did this by writing a 2-way interface to an ISY-99 using the ISY Web Services layer. So now I can trigger ISY programs based on 1-wire temperature probe ranges, digital inputs such as hard-wired motion sensors and contact switches for doors and windows, and analog value ranges (not using that one yet). I can also control relays from ISY programs, such as opening/closing my garage door and an electric door lock. I also wrote a Barionet interface for the W800RF32 to read X-10 wireless devices -- both secure and unsecure. These X-10 wireless state changes can also be used to trigger ISY programs from the Barionet. This allowed me to scatter both wireless and wired motion sensors around the house and trigger lights on/off based on their state changes. The ISY contains the logic and the Barionet provides the interface to non-Insteon devices. I used the Barionet's HTML extensions to write-up a Web screen to register the X-10 wireless security codes and collect the necessary ISY connection information, including security credentials. The Web screen is hosted on the Barionet itself. I was impressed with the Barionet's speed and relative ease of programming once I got past the initial learning curve. I agree that it's primary shortcoming is a lack of easily accessible persistent data storage. If anyone is interested, I can post the code here.

Randy

 

[electron]

The more examples, the better! It will make it easier to understand what can be done, and how.

 

[electron]

In case anyone else is following this thread, I figured out a cheap serial port solution:

http://www.cocoontech.com/forums/index.php?showtopic=14158