Plugin for Relay Output / Analog Input Boards from iorelay.com

Looks like the port for a Connect ME module is 2101.

You can test that from a PC using “[tt]telnet 2101[/tt]” and see if it connects.

Hi guessed,

Thanks for your comprehensive answers.

I tried using Telnet to 10.0.1.90 2101 and it said unable to connect. I factory restored the IO board and tried again and now the command screen goes blank after entering that command. Of course, Telneting without the 2101 port appended prompts me with the login page. You’ll see I’ve appended 2101 to my device settings but I still only get the root device icon with no inputs and outputs being displayed so these must only display after a successful connection?

How do I check at the Vera end to see if it’s connecting or not?

Below are some screenshots of my setup.

Your files don’t look correct. They have an .lzo extension, but based upon their size they don’t look to be compressed (at all).

When you upload via a browser, the Vera upload script will compress these (using pluto-lzo c src dst). If you uploaded via WinSCP, then you’ll need to manually compress these yourself using the same command.

Compare the names/sizes to those that I list above as a reference.

Hi guessed,

Thanks again. The files were uploaded/updated using the browser.

I did find a problem with the R45PL_ZETH-ME board I have as it seems you need to configure a serial port for TCP/IP comms to get port 2101 open. I could not talk to the relay board using IO Relays own Base Station Software. This is working now on their software and I can control the relays that way. Thought I was on it it but alas, the Vera still cannot see it.

I see your app has been pulled from the store. Was this to fix it?

I’ve added the device manually using the following data but I still only see the parent device; no IO’s.

The one in the store was created by Florin, by changing some of my original sources, but it was broken. “Mysteriously” this showed up in the list of plugins that I owned, so they must have assigned it to me.

Since, technically, Floriin’s derived works weren’t actually mine and had nasty bugs, I decided it was easier to delete it altogether.

Right now, my focus is on getting you functional with the trunk version from code.mios.com. Whether I put it back into the store afterwards will completely depend upon how many critical bug fixes the MCV Team execute upon that infrastructure in the coming months :wink:

eg. (0 critical bug fixes) == (0 new plugins deployed)… or perhaps 1 removed/month until they fix it… 8)

If you’re comfortable with SSH, and WinSCP, I’d recommend you copy the files over using WinSCP, and then run:

pluto-lzo c S_IORelay1.xml S_IORelay1.xml.lzo
… over each of the 4x files you upload. The ones you have, with the sizes listed, just look like they’re “LZO” by filename only.

The files to upload are in this ZIP link:
http://code.mios.com/trac/mios_iorelay/changeset/6/trunk?old_path=%2F&format=zip

Your a genius guessed!!

We are nearly there. I don’t know why the browser did not compress the uploaded files even though there were saying they were LZO? Manually following your instructions has at least given me the right GUI now.

The relays however do not work even though the UI5 GUI reports back that the ‘light’ is ON. I have not tested the inputs.

Where to from here?

guessed,

I now get the attached message at the top. Is that indicating a problem? Goes away after 30s.

Guessed,

Just in case this helps, screenshots for the NCD Base Software are attached showing the commands sent for relay 2 on then off. Looks like if I connect the Vera to it using 2101, the relay board hangs for some reason and if I try to Telnet into it on 2101 or use the NCD base software again on port 2101 (after disconnecting the Vera from it as it only allows one connection at a time), neither program can connect until I reboot the relay board so something funny is happening.

Furthermore guessed, I’ve checked the relay board via the web gui and the Vera (10.0.1.91) has connected to it even though there is no control. Also, the MAC address is not being reported back.

The data that the tool is sending is interesting. It’s “wrapped” more than the data that my Plugin would send.

Turn on Relay 1:
170 3 254 109 1 25 (yours)
254 109 1 (mine)

ACK for the above:
170 1 85 0 (yours)
85 (mine)

What I can’t tell is where the extra wrapper bytes are coming from. Given I’m not sending them, I can see why the device isn’t responding. I’ve not used a Digi Connect ME module before, do you have any configuration screens that could change this type of wrappering?

do you have any configuration screens that could change this type of wrappering?

Not quite sure what your question is. The IO Relay Base software can send Decimal or HEX format commands so I’ve run on/off on relay 1 in both formats for you. Screenshots attached. The full guide is below.

[url=http://assets.controlanything.com/QSG/API_Codec_Quick_Start_Guide.pdf]http://assets.controlanything.com/QSG/API_Codec_Quick_Start_Guide.pdf[/url]
[url=http://assets.controlanything.com/QSG/Base_Station_Quick_Start_Guide.pdf]http://assets.controlanything.com/QSG/Base_Station_Quick_Start_Guide.pdf[/url]

The IO Relay hardware developer has come back and said this in regards to your commands vs. those of the Base Software.

In Base Station Software, the second screen you see has a check box that says use API When Possible. Api communications is not required, but when working with network communications, it can be very helpful in managing network lags. The controller will accept commands either way, so both are correct, they are both going to work, but API is much safer as it allows for network delays. API is very easy to learn, please click on the API codec option in base station software, this will show you how to wrap your commands in API format. Don't forget to use the More button in Base Station software. It's in the upper left corner of most forms, and greatly helps you see all data transfer operations. Hope this helps.

Right, reading their doco it looks like the ProXR models have an extra “wrapper” that can [optionally] be delivered to the device. This includes a special starter-byte, a length-byte and a checksum at the end.

It’s supposed to understand the older format, which is what I’m sending (none of my boards support the wrapper format)

If you enable Verbose logging, you’ll get log lines like:

a request like:
[tt]51 01/28/13 21:55:37.552 0x52 0x5a 0x30 0x32 0x30 0xd (RZ020\r) <0x2c919680>
[/tt]
or a response like:
[tt]52 01/28/13 22:07:30.207 0x48 0x6f 0x73 0x74 0x3a 0x20 (Host: ) <0x2f55a680>
[/tt]

Do this while you’re clocking on the On or Off button. You should see entries in [tt]/var/log/cmh/LuaUpnP.log[/tt] IF Verbose logging is enabled.

I wanted to see if data is even being sent to the device and/or what’s coming back. In theory they support the older commands but I want to see what they’re doing in practice.

If this isn’t clean, then I might have to re-do the plugin to add native support for the ProXR wrappers (which will take me a weekend or two)

Thanks,

Log capture here [url=http://pastebin.com/HxbLLF8K]http://pastebin.com/HxbLLF8K[/url]

I switched on my garden water using a ZWave appliance module first then tried the IO Relay board relay 1 three times.

Let me know if you see anything.

Thanks for the log output. I can see that it’s making the (old style) request to the Relay device, but no response is coming back.

Initially it fires off single byte status polling requests, and this is what I’m seeing in the log. It expects to get a response to these and never does, so the subsequent stuff gets pipelined.

From a previous post it sounds like there is a way to turn on some sort of compatibility switch. Can you double check those screens?

Failing that, I’ll have to add a new mode to support this type of extended protocol. That would then add the start, count and compute the required checksum. Overall, not a bad thing, since their new model is MUCH more predictable than the old model… It’s why the code is so complicated, it’s trying to deal with data loss cases.

@guessed,

Here’s what the NCD Hardware Developer said. “There is no option to toggle API mode on or off. If you speak to the controller in API Mode, it will respond back to you in API mode. If you speak to the controller in standard mode, it will reply back to you in standard mode. Connect ME modules GREATLY BENEFIT from API Mode. Try sending an API Frame to the controller instead of a standard frame. API has a MUCH GREATER chance of processing than standard frames”.

If it will help, I can open up my network for remote access to the relay board or even send it to you if that will help?

Thanks very much for all of your assistance. Be a bit lost without it! :-\

@xbmcnut,
I’ve put together a change for the functionality. I don’t have a particular way to test it, since I don’t have a real device that does the API Codec mode, but I’ve bench tested the routines that do the work, and they appear to work well.

To run it, you’ll want to upload the 4 standard files from:
http://code.mios.com/trac/mios_iorelay/changeset/10/trunk?old_path=%2F&format=zip

You can ignore the test.lua file, since it’s the simple bench test for the new Codec/Wrapper API’s. You can overlay these files atop the original ones that you already have installed.

By default, these files will be in “Serial” Protocol, or the original behavior. After loading, and restarting Vera, you need to goto the Advanced Tab, and change the “[tt]Protocol[/tt]” field to be “API” (see screenshot). You’ll need to restart again after making that change, so that it sticks (the first restart makes the new parameter show up)

This Protocol change will trigger a very different codepath for data coming back from the IORelay board. It’ll also trigger a “wrapper” of all outgoing commands to include the API Codec per spec.

If it fails, I will need logs of the problem with Vera’s Verbose logging enabled. I suspect there will be errrors, since yours will be the first time it’s called with the API Codec codebase.

I have a fair amount of debugging logic enabled, so hopefully we can capture the right information if it breaks :wink:

@guessed.

Amazing work, thank you. Just got back from leave so will give this a burst tomorrow night and report back. Thank you sooo much. ;D

@guessed.

Thank you so much.It seems to be working flawlessly now!!!

Took a bit to get it working but now it’s configured, been running for 12hrs without an issue.

[ol][li]Copying the new files using WinSCP and compressing them using SSH did not work after a reboot. Option to enter protocol was not there. Rebooted a 2nd time, still no joy.
[/li][li]Copied files using browser and rebooted, protocol option appeared.[/li]
[li]Still no comms with IO Relay board so factory defaulted and reset serial ports for TCP Sockets profile with 115200 baud rate and bam, all working.[/li][/ol]

Inputs respond with either 0% (short to ground) or 100% (open circuit) which is perfectly fine for my application.
Relays respond instantly via the UI5 GUI and within 1~2 seconds via SQ Remote App

The only thing I would comment on is the polling time for the inputs. Currently it’s around 60~65 seconds. Is there are way to shorten this or does that create too much chatter?

I just have to figure out now how to use PLEG to check the input for my garage door reed switch at 2100 hours and if open circuit, close the Roller Door. Similar action required to bypass watering system if rain gauge is full.

I can’t express how grateful I am for the work you put in. Without your assistance I’d have a $200 PCB sitting around collecting dust and a grumpy wife! Let me know if you have an option to donate some bucks in your direction (DM me?) and I’ll at least buy you a beer!

Cool. Good to hear it’s working for you. There are likely a few tweaks that I still need to make to the code, but let me know how the stability progresses on your deployment.

You can change the Interval property to make it sample faster. It defaults to 60 seconds, but can be lowered to 3. Higher values are obviously less “abuse” on Vera :wink:

I can't express how grateful I am for the work you put in. Without your assistance I'd have a $200 PCB sitting around collecting dust and a grumpy wife! Let me know if you have an option to donate some bucks in your direction (DM me?) and I'll at least buy you a beer!
You're totally welcome. I don't take donations for this stuff, I only automate things I use around the house anyhow, and it's a great way to learn new stuff (like this case)

I’ll tag this in source control so there’s a more “formal” version of what you’re running on your system, since I’ll likely advance “trunk” on more.