Not surprised about the Flex. I don’t have a Flex, so I was unable to put in support for it yet. Sorry about not noting that. I really need to get one of those!
You can stop the messages by turning off discovery as described in the README.
Before you do that, if you wouldn’t mind, can you put it in TRACE mode in order to capture the Flex beacon announcement, then send that to me.
That would be log:set TRACE org.openhab.binding/globalcache in the karaf console.
Here you go:
2016-09-16 10:36:13.662 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener parsing announcement packet: AMXB<-UUID=GlobalCache_000C1EE0E330><-SDKClass=Utility><-Make=GlobalCache><-Model=iTachFlexEthernet><-Revision=710-3000-18><-Pkg_Level=><-Config-URL=http://192.168.1.52><-PCB_PN=025-0034-12><-Status=Ready>
2016-09-16 10:36:13.662 [TRACE] [iscovery.GlobalCacheDiscoveryService] - Device of type iTachFlexEthernet discovered with MAC 000C1EE0E330 and IP 192.168.1.52
2016-09-16 10:36:13.662 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener looking up thing type for device model iTachFlexEthernet
2016-09-16 10:36:13.662 [ERROR] [balcache.discovery.MulticastListener] - Multicast listener unable to find a thing type for device model iTachFlexEthernet
2016-09-16 10:36:13.662 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port
2016-09-16 10:36:15.271 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener got datagram of length 100 from multicast port
2016-09-16 10:36:15.271 [WARN ] [balcache.discovery.MulticastListener] - Multicast listener beacon length is too short, length is 100
2016-09-16 10:36:15.271 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port
2016-09-16 10:36:18.271 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port
2016-09-16 10:36:20.146 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener got datagram of length 202 from multicast port
2016-09-16 10:36:20.146 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener parsing announcement packet: AMXB<-UUID=GlobalCache_000C1EE0EEEA><-SDKClass=Utility><-Make=GlobalCache><-Model=iTachFlexWiFi><-Revision=710-2000-18><-Pkg_Level=ÿ><-Config-URL=http://192.168.1.58><-PCB_PN=025-0033-10><-Status=Ready>
2016-09-16 10:36:20.146 [TRACE] [iscovery.GlobalCacheDiscoveryService] - Device of type iTachFlexWiFi discovered with MAC 000C1EE0EEEA and IP 192.168.1.58
2016-09-16 10:36:20.146 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener looking up thing type for device model iTachFlexWiFi
2016-09-16 10:36:20.146 [ERROR] [balcache.discovery.MulticastListener] - Multicast listener unable to find a thing type for device model iTachFlexWiFi
2016-09-16 10:36:20.146 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port
Note: if you want me to test those for you (both simply have the IR emitter/blaster cables attached - the ethernet one only uses on port, the wireless one uses two ports)
You have both models. That’s awesome.
This is good. It discovers it correctly as an itach. It just doesn’t know what to do with it because I haven’t defined the things for those models yet.
I’ll take you up on the offer to test it. I might not be able to get to it until Sunday, though.
Thanks for the logs.
@mhilbush That’s great you’ve got an OH2 binding working. This might be the best solution for the usability shortcoming in the OH1 binding, where you need a separate item for each IR command – just upgrade to OH2! When you’re ready to contribute the binding, you would submit a PR to the openhab2-addons repo with it.
It sounds like many people will be very pleased to have an OH2 binding with discovery included!
@tmrobert8 There’s a new jar file in the same location as the last one. This one should (hopefully) discover the ethernet and wifi flex devices, and add them to the inbox. I also copied the iTach IR channels to the flex thing definitions, so if the discovery works, the device might even accept an IR code. This is not the final solution, but it was an easy change.
BTW, which IR cables do you have connected to the flex?
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-m1c3As 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.
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. 
Let me know how it goes.