Gc100ir transform map

This binding seems to be working well on my IP2IR with my NEC plasma TV.

I also have an IP2SL that I am not using right now, but I plugged it in and it was discovered right away.

At first, my devices weren’t showing up in the inbox and I was getting an error about ExtendedDiscoveryService not working but I deleted the cache as described and all was good. https://community.openhab.org/t/noclassdeffounderror-when-starting-zwave-binding-after-upgrading-to-oh2-beta-4/14159

Also had to install Map Transformation service.

I found a minor issue. When you use PaperUI to manually add an IR thing, down under Network Address, it says “Enter the IP address of the iTach CC device”.

CC stands for contact closure. It should say IR instead of CC. Same issue for serial (SL) devices.

Thanks. Good catch. That should be fixed in the latest version. I saw that when I was adding the flex devices.

Mark,
I just looked over the Readme file on github. I was wondering if the binding supports 2 way communication for the serial devices? If so, could you put an example of how to configure the feedback from the device?

I haven’t yet worked out how to do 2-way communication. Are you looking to interpret the device’s response to a command, for instance in a rule?

I don’t know exactly what to do with the data returned from the devices. I’m still mostly sending one way commands to devices. Maybe use it to track a device’s state. Some devices let you query their status. I was just thinking that the IP2IR devices are only capable of one way communications. With IP2SL, there is a potential for 2 way communication.

Sorry I couldn’t post earlier. Both flex’s were successfully discovered and both worked with the IR codes I gave them. Good Job!!

However - I’m having issues with my ITachCC. Looking through your readme - seems like you use Switches to trigger the CC but the channel type is a Contact. I tried to use switches and it didn’t respond to the OnOff command and I haven’t the slightest idea how to use a Contact type in the sitemap (never used that before and can’t seem to find a clear example).

One quick documentation note - you should mention how to set the mapping file manually. While it’s pretty easy in the PaperUI - if you are working with things file directly, you don’t specify (or show in your examples) the configuration parameter to use (I looked it up in your code to figure it out).

That’s great. I’ll probably be making a change to the Flex channel definitions to allow for the use of IR, serial, and contact closure channels. Instead of just using m1c1, m1c2, etc., I’ll probably have an ir-m1c1, cc-m1c1, sl-m1c1, etc. That way, you’ll be able to send IR, serial, or CC commands to the device depending on which type of cable is connected.

Good point. Although I wonder why it’s working for me. The example in the documentation shows a Switch in the item definition and in the sitemap, and that seems to work for me. I’ll look at this more closely.

Yep. Good idea.

@tmrobert8
I changed the CC channel definition from Contact to Switch. Hopefully that will resolve the issue you were having.

The README now shows how to specify a map file in the .things file. Thanks for that suggestion!

Flex things now have IR, SL, and CC channels. This may not be the most elegant way to do it, but I think it will work. I need to get a Flex and some different cables (IR, 3-way IR, serial, and CC) to really get it sorted out…

ir-m1c1
ir-m1c2
ir-m1c3

sl-m1c1

cc-m1c1
cc-m1c2
cc-m1c3

As it turns out - I seem to have an equipment failure on my end (either the CC, the wire or the end equipment is having issues) so I’m not sure if the contact channel was working or not. I’ll keep a copy of the older ‘contact’ jar and the newer one to retest once I resolve the hardware issue.

Ack - the connector wasn’t seated properly in the IP2CC and that was the cause of my issues. Both the contact and the switch version worked fine for me (sorry about that). Probably would be better to go with your contact version since it more resembles the model.

Sorry about the confusion and thanks for the great work you’ve done on this. Let me know if you need any additional help testing.

Tim

Thanks. Yeah, I’ll probably revert it back to Contact.

I’m also going to change the name of the config parameter for the map file, as the current one is not named very well. This will break your setup, and I think will require you to delete the Flex things and rediscover.

Mark,

Thank you for your work! I am controlling several devices with iTach Flex units (all but one using serial). This binding is one of the missing links I have for integrating my audio/visual stuff with my home automation. Very much appreciated!

Your binding found my 4 Flex units. 2 of them were identified as “GlobalCache iTachFlexEthernet” devices and give me channel options (and type). The other two (which are older but on the same firmware) are identified as “GlobalCache iTachFlexEthernetPoE” devices and do not have any channel’s listed at all.

Although they are all POE type units the two older ones are labeled differently and don’t show up with any channel options. I assume that is due to the different naming convention used on these two devices.

Any insight on how to get these to have the same setup options as the other two that are not shown as POE?

Thanks for the feedback. I didn’t see that model in the API spec, so the discovery process doesn’t match on it. It’s probably showing up as an unknown device with no channels. Is that the case?

I assume it functions identically to an iTachFlexEthernet, it just announces itself differently as a PoE device. If so, it’s an easy code change to add iTachFlexEthernetPoE. I’ll post here when the new version is available.

@swamiller

There’s now a new version that should detect the model iTachFlexEthernetPoE. You should just be able to replace the jar in the addons directory with the new one. I think you will need to delete the unknown thing and/or inbox entry in order for it to be rediscovered. It should discover it, then add it as another iTachFlexEthernet device(s).

If this doesn’t work, I may need you to set the log level to TRACE in order to capture the announcement beacon string. We can cross this bridge if/when we get to it.

I see you are using the Flex devices as serial. Note that I don’t have any serial devices, so my only serial testing was done with a null modem cable connecting my GC-100 to a PC that was running a terminal program. :worried: Let me know how it goes.

Thank you Mark! All my devices were discovered and all had the various channel types available for assignment.

As you suspected, however, the serial devices don’t work. I did confirm my set up works by testing the one IR device I have (a Vizio TV) and it works as advertised.

I did verify via Docklight that my serial device isn’t receiving anything to rule out a syntax issue with the serial command itself.

I did successfully create a python script a while back from using the Global Cache API website to test sending serial commands using the “sendCommand” function in Openhab but I’m still hoping for a binding.

I know little about programming, but it looks like one of big differences between the iFlex IR vs iFlex serial is the port used to send the data. IR uses port 4998 and serial uses 4999. Not sure if that matters or not.

Let me know if I can help test in any way.

Thank you!!

Hmm. The port shouldn’t be the problem since I do use 4999 for the serial commands.

Can you show me how you have your items and map file entries set up for the serial device(s)?

Also, do you see any errors in the log file when you send a serial command?

Sure thing.

Serial item:

String SharpTV          "Living Room TV"                       { channel="globalcache:itachFlexEth:000C1EE0CE88:sl-m1c1" }

Map file:

 # Represents the command string "POWER ON" followed by carriage return line feed
SHARPTV_POWER_ON = POWR1%20%0D%0A
 # Represents the command string "POWER OFF" followed by carriage return line feed
SHARPTV_POWER_OFF = POWR0%20%0D%0A
 # Represents the command string "VOLUME UP" followed by carriage return line feed
SHARPTV_VOLUME_UP   = RCKY33%20%0D%0A
 # Represents the command string "VOLUME DOWN" followed by carriage return line feed
SHARPTV_VOLUME_DOWN = RCKY32%20%0D%0A

Sitemap:

Switch item=SharpTV label="LR TV Power" mappings=[SHARPTV_POWER_ON="On",SHARPTV_POWER_OFF="Off"]

Events.log sample:

2016-09-24 16:58:15.963 [ItemCommandEvent          ] - Item 'SHARPTV' received command SHARPTV_POWER_OFF

Here is the serial command example for “power on” for my Sharp TV from iRule: POWR1 \x0D

I tried a couple of different ways of building the serial command and resorted to using the same carriage return in your example. I figured that I would see some activity either way on the other end via Docklight Scripting which I use to monitor the commands received by the iFlex. I saw no activity.

And for your reference, here is the Python script I was dabbling with. This one is for a different component but you can see the serial command “OUTPUT01 01” sent by the script

from urllib2 import Request, urlopen

values = """
OUTPUT01 01;"""

headers = {
  'Content-Type': 'text/plain; charset=UTF-8',
  'Content-Length': '12'
}
request = Request('http://192.168.1.213/api/v1/serialports/1/sendserial', data=values, headers=headers)

response_body = urlopen(request).read()
print response_body

Thanks again for your help!

I think I know what’s wrong. When the thing initializes, I’ll bet you see a log entry that says “opening command port”. But, I’ll bet there’s not a log entry right after that one that says opening serial port.

I’m probably not recognizing the Flex as being “capable” of serial. I think I know what to do about this. I’ll get back to you.

@swamiller

Try again. This should work now for a Flex configured for serial. However, I’m not sure what it’s going to do if the Flex is configured for IR. If it breaks IR, then I’m probably going to need to get myself a Flex with all the different cable options…