How to setup GC100IR binding in OH2

Add-ons Bindings
, ,
61

Mark, if you could tell me step by step instruction how to put the binding in the debugging mode with GC-100-12 I would clean the configuration settings to get the clue to the problem of autodicovery fail in my case.

I am currently testing the binding, it works fairly stable, but I got the globalcache in offline mode couple of times recently. The log file said that the socket was closed. After the OH restart everything was ok.

Another strange thing to me. My .thing file has 2 records mentioned below, so I have 2 connection on IR and Serial ports.

String OPPO105      "OPPO 105D"   {channel="globalcache:gc100_12:000C1EC016A4:m1c1"}
String PanasonicTV    "TV"     {channel="globalcache:gc100_12:000C1EC016A4:m4c1"}

I have 3 following notes below in the log file. How do you think why there is a serial-2 port connection record in the log file?

2017-01-01 17:13:59.135 [INFO ] [GlobalCacheHandler$ConnectionManager] - Got a connection to command port for thing gc100_12:000C1EC016A4 at 192.168.0.30
2017-01-01 17:13:59.144 [INFO ] [GlobalCacheHandler$ConnectionManager] - Got a connection to serial-1 port for thing gc100_12:000C1EC016A4 at 192.168.0.30
2017-01-01 17:13:59.152 [INFO ] [GlobalCacheHandler$ConnectionManager] - Got a connection to serial-2 port for thing gc100_12:000C1EC016A4 at 192.168.0.30

Another question on rules. Am I right that since serial port is one-way, I can not receive a state update from the controlled device?

62

First, make sure you reenable auto discovery, as described in the globalcache README.

To put it in debug mode, you need to open up a Karaf console as described here:
http://docs.openhab.org/administration/console.html

Then, at the prompt enter log:set TRACE org.openhab.binding.globalcache. This will generate a lot of output in the log file. Hopefully you will see lines that look this one for a GC-100-6. If you see those lines, please paste them here and I’ll take a look.

AMXB<-UUID=GC100_000C1E00F0E9_GlobalCache><-SDKClass=Utility><-Make=GlobalCache><-Model=GC-100-06>
* <-Revision=1.0.0><Config-Name=GC-100><Config-URL=http://192.168.13.170>CR

When you’re done, put it back to INFO mode using log:set INFO org.openhab.binding.globalcache

If the connection is closed for some reason (network interruption, power cycled on the device, etc.), it should attempt to reconnect within about 60 seconds. In your situation, is it never coming back online until you restart OH2?

I assume you mean your .items file. Yes, OPPO105 is for module 1 which is a serial port, and PanasonicTV is module 4, which is IR.

The GC-100-12 has 2 serial ports, so the binding opens both, even though you have a channel bound to just one of the ports.

Yes, currently it’s just one-way. Adding a feedback channel is on my todo list.

63

@Offboard, @marlon-alvarez, @Nicholas_Waterton, @MacFly,

For those who were using a pre-release version of the OH2 globalcache binding, I wanted to let you know that the globalcache binding has been added to the OH2 distribution as of build number 687.

One VERY IMPORTANT thing to note. The channel naming convention has changed to use channel groups. When you install the binding from the OH2 distribution, you will need to change your items to reflect the channel naming convention as shown in the GlobalCache README. And, you will need to delete, rediscover, and readd your globalcache things.

To install the binding, first uninstall the one in addons. I generally do it this way.

From Karaf console,

  • stop the binding using bundle:stop org.openhab.binding.globalcache
  • Then bundle:uninstall org.openhab.binding.globalcache

Then, remove the jar from addons

Add the binding back using PaperUI, HABmin, or conf/services/addons.cfg.

Let me know if you run into any problems.

64

Mark,

I deleted the binding, and now can not manage to install the binding back.
Shall I find the respective build in add-ons menu in PaparUI? Unfortunately, I can not find it there.

65

Are you on the latest build? It wasn’t added until build 687.

66

should read your instructions more attentively - I had an outdated build of OH2. Everything is ok after the update.

67

I installed the the binding in hope to see autodiscovery in action, but unfortunately the binding did not find my gc100. Did I miss something?

What i did:

  1. put the record in runtime.cfg:
org.openhab.binding.globalcache.discovery.GlobalCacheDiscoveryService:backgroundDiscovery.enabled=true
  1. put the command in the console:
log:set TRACE org.openhab.binding.globalcache

the log file says the following:

2017-01-03 00:47:40.887 [DEBUG] [iscovery.GlobalCacheDiscoveryService] - Globalcache discovery service activated
2017-01-03 00:47:40.888 [DEBUG] [iscovery.GlobalCacheDiscoveryService] - Starting background discovery job in 10 seconds
2017-01-03 00:47:40.888 [DEBUG] [org.openhab.binding.globalcache     ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.pid=org.openhab.binding.globalcache.discovery.GlobalCacheDiscoveryService, backgroundDiscovery.enabled=true, component.name=org.openhab.binding.globalcache.discovery.GlobalCacheDiscoveryService, component.id=153, service.id=290, service.bundleid=180, service.scope=bundle} - org.openhab.binding.globalcache
2017-01-03 00:47:50.894 [DEBUG] [iscovery.GlobalCacheDiscoveryService] - Discovery job is running
2017-01-03 00:47:50.895 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.0.24
2017-01-03 00:47:50.895 [DEBUG] [balcache.discovery.MulticastListener] - Discovery job using address 192.168.2.1 on network interface bridge0
2017-01-03 00:47:50.896 [DEBUG] [balcache.discovery.MulticastListener] - Multicast listener joined multicast group 239.255.250.250:9131
2017-01-03 00:47:50.896 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port
2017-01-03 00:47:53.900 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port
2017-01-03 00:47:56.903 [TRACE] [balcache.discovery.MulticastListener] - Multicast listener waiting for datagram on multicast port

It seems to me now that the problem was my router. Currently I am testing the overall configuration from laptop. Sometime laptop changes wi-fi network - I have 2 wi-fi routers with different SSIDs. After network change it refuses to get the GC100 in online status, waited more than 60 seconds. I turn the wi-fi off and on (reconnect) and it works again. Given this, the problem is in stable connection and, to my mind, does not relate to binding at all.

Yes, it was . items file, you are right

1 Like
68

@Offboard Glad to hear it’s running stable for you.

This was very helpful. Thanks.

It looks like there are multiple active ipv4 network interfaces on the host running openHAB (192.168.0.0/24 and 192.168.2.0/24). The binding is listening for GlobalCache broadcasts on 192.168.1.0/24. Can you tell me the IP address of the GC-100-12? I’ll bet it’s on the 192.168.0.0/24 network.

If that’s the case, then I know what the problem is, and it’s on my list of things to fix (by adding a config parameter to specify the network to be used for discovery).

69

Thanks,

I just upgraded, and so far, so good – all seems to be working.

Thanks for the work on this binding.

1 Like
70

@mhilbush
GC-100-12 is on a static ip 192.168.0.30
192.168.0.24 is an ip of a laptop where OH2 is installed

1 Like
71

Thanks. Then my planned fix will resolve the issue.

I appreciate the help troubleshooting it!

72
  1. Unfortunately, Serial port #2 on GC100-12 does not work.
    All the commands I send to the Serial port#1 works fine, I can turn on and off the media player.

The log records when I send the command to serial port#2 are presented below. Everything seems to be ok, but the media player is off. I set baud rate and other parameters the same as on serial port#1.

2017-01-03 17:26:34.213 [DEBUG] [obalcache.handler.GlobalCacheHandler] - Handle serial command OPPO_POWER_ON on channel sl-m2#c1 of thing gc100_12:000C1EC016A4
2017-01-03 17:26:34.214 [DEBUG] [obalcache.handler.GlobalCacheHandler] - Transformed OPPO_POWER_ON for thing gc100_12:000C1EC016A4 with map file 'commands.map'
2017-01-03 17:26:34.214 [TRACE] [che.internal.command.AbstractCommand] - Put request on queue (depth=1), sent command '%23POW%20%0D%0A'
2017-01-03 17:26:34.214 [TRACE] [.GlobalCacheHandler$CommandProcessor] - Processor for thing gc100_12:000C1EC016A4 writing command to device
2017-01-03 17:26:34.214 [DEBUG] [.GlobalCacheHandler$CommandProcessor] - Decoded deviceCommand byte array: 23 50 4f 57 20 0d 0a 
2017-01-03 17:26:34.214 [DEBUG] [.GlobalCacheHandler$CommandProcessor] - Transaction 'sendserial' for thing gc100_12:000C1EC016A4 at 192.168.0.30 took 0 ms
2017-01-03 17:26:34.214 [TRACE] [.GlobalCacheHandler$CommandProcessor] - Processor for thing gc100_12:000C1EC016A4 queuing response message: successful
2017-01-03 17:26:34.214 [TRACE] [che.internal.command.AbstractCommand] - Got response message off response queue, received reply 'successful'
2017-01-03 17:26:34.214 [TRACE] [che.internal.command.AbstractCommand] - Checking device reply for error condition: successful
2017-01-03 17:26:34.214 [DEBUG] [e.internal.command.CommandSendserial] - Execute 'sendserial' succeeded for command OPPO_POWER_ON on thing 000C1EC016A4 at 192.168.0.30
  1. As I understand when I send the “ON” signal to the contact closure it should return 24Volts on contacts. I checked it with multimeter and it returns 0 Volts. Shall it work this way?
    Logs:
2017-01-03 17:38:25.410 [DEBUG] [obalcache.handler.GlobalCacheHandler] - Handling CC command ON on channel cc-m3#c1 of thing gc100_12:000C1EC016A4
2017-01-03 17:38:25.410 [TRACE] [che.internal.command.AbstractCommand] - Put request on queue (depth=1), sent command 'setstate,3:1,1'
2017-01-03 17:38:25.410 [TRACE] [.GlobalCacheHandler$CommandProcessor] - Processor for thing gc100_12:000C1EC016A4 writing command to device
2017-01-03 17:38:25.410 [TRACE] [.GlobalCacheHandler$CommandProcessor] - Processor for thing gc100_12:000C1EC016A4 reading response from device
2017-01-03 17:38:25.421 [DEBUG] [.GlobalCacheHandler$CommandProcessor] - Transaction 'setstate' for thing gc100_12:000C1EC016A4 at 192.168.0.30 took 11 ms
2017-01-03 17:38:25.421 [TRACE] [.GlobalCacheHandler$CommandProcessor] - Processor for thing gc100_12:000C1EC016A4 queuing response message: state,3:1,1
2017-01-03 17:38:25.421 [TRACE] [che.internal.command.AbstractCommand] - Got response message off response queue, received reply 'state,3:1,1'
2017-01-03 17:38:25.421 [TRACE] [che.internal.command.AbstractCommand] - Checking device reply for error condition: state,3:1,1
2017-01-03 17:38:25.421 [WARN ] [che.internal.command.CommandSetstate] - Successful reply from device can't be matched: state,3:1,1
2017-01-03 17:38:25.422 [DEBUG] [che.internal.command.CommandSetstate] - Execute 'setstate' succeeded for command ON on thing 000C1EC016A4 at 192.168.0.30
73

  1. This might be a bug. Since I only have a GC-100-6, I wasn’t able to test the second serial port. I’ll look into this.

  2. It looks like the command is successful, although I’m not sure why it says “Successful reply from device can’t be matched: state,3:1,1”

Can you hear the relay activating and deactivating? On the iTach’s, you can hear the relay faintly. Not sure about the GC-100.

74

I see why this is happening. On contact closure, the GC-100 returns a different response than the iTachs. I will fix that.

But, it still appears the command to activate relay 3:1 completed successfully. When looking at the back of the GC-100, is connector 3:1 on the left side or the right side of the grouping of 3 connectors?

75

Thank you for this in advance!

I hear some faint click but only when deactivate contacts closure to the state OFF but contacts do not have any voltage.

Leftmost. But I checked all 3 connectors, all of them do not have voltage.

76

On my iTach CC, the deactivate click is louder than the activate click.

Great that you have a multimeter. :slight_smile: Can you check to see if there is 0 Ohms across the relay when it’s activated? From my understanding, I didn’t think it provides a 24v source when activated.

BTW, I did confirm that the second serial port issue is a bug. I’ll work on a fix, but may not be able to get to it until the weekend. Since I don’t have a GC-100-12, I’ll also need you to test for me. :slight_smile:

77

I do not hear click activate click but there is faint deactivate click

Unfortunately, it provides 0 Ohms across the relay across both state activated and deactivated
Have no idea where could be the problem and what to check. The worst case is if dry contacts are broken.

Here is GC100-12 manual, as I understand it says that there should be 24v, but I might be wrong.

You can count on me in this :slight_smile:
Also looking forward testing feedback function on serial port :slight_smile:

78

I have a version that might fix the problem with the 2nd serial port.
https://github.com/mhilbush/globalcache-test/blob/master/org.openhab.binding.globalcache-2.0.0-SNAPSHOT.jar

If you installed the released version, you will need to uninstall it using PaperUI. Then add this version to the addons directory. Let me know how it works out.

Hmm. This doesn’t make any sense to me. I’l have to try this on my iTach CC.

The way I read this, it’s saying that the relay is rated for 24 V and 500 mA. But I could be wrong.

1 Like
79

Thank you for the update! It works now.
Just for information, also checked all the 6 IR ports (2 modules), all of them works fine.

It would me interesting to know what resistance and voltage you have on contacts, given that we know that your device works.

80

I just pushed an update with the fix for GC-100-12 serial port 2. I’ll post again here once it’s merged into the OH2 build.

Also fixed this confusing warning message.

2017-01-03 17:38:25.421 [WARN ] [che.internal.command.CommandSetstate] - Successful reply from device can't be matched: state,3:1,1

Thanks!