I'll PM you as we are hijacking this thread.
Send IP2IR Update...
1.1.0 - 10/20/18 - Big change in how Channels work. Only have to enter each digits IR code once, in the Advance Section of the Parent app. Now in the Child apps, only need to put in the digits (no IR codes!). This is a non-destructive update. All existing channels will still work. Thanks to Bruce (@bravenel) for showing me how to send code from parent to child apps.
You will need to update both parent and child apps.
Thanks
Driver update...
V1.0.1 - 11/01/18 - Merged pull request from DTTerastar, resend the command if busy is received. Thank you!
No prob. I'd like to figure out a way of having multiple commands queue up and get sent once the previous has been acked. It'll be needed if you want to send more than 2 commands quickly...
Thank you...ordered...
BIG update...
V1.1.2 - 11/01/18 - Added an optional Digit 4 within Channels. Sending Enter Code after Digits is now optional. Made the Delay between sending digits user specified and added in some instructions.
NOTE: All channel buttons will have to be fixed. They need to be made into either Channel_buttons (same as what they were, just need to be specified in the child app) or Channel_Switch (can be used with Google Assistant!).
To make the Channel device into a Channel_Switch:
- Edit the Virtual Button Device and change it to a Virtual Switch Type Device.
- Set the the 'Enable auto off' @ '500ms' and 'Save'
- Hit the 'On' button and watch it turn back 'Off'
- Next go to the Child App that this device controls.
- It will ask you to 'Select Trigger Type'
- Select Channel_Switch
- Most of your previous information will come up, double check it
- Be sure to check 'Send Enter Code After Digits' if needed
- If everything else looks good, hit 'Done'
To change over a regular button to a switch button... Unfortunately, the child app would simply have to be deleted and recreated.
Another thing I do is for Stereo volume...
- Create a Virtual Button and set the 'Enable auto off' @ '1s'
- then when you create the child app, put the same IR Command in both the On and Off fields. That way it sends two commands with one button push.
Thanks
I have veered off from @bptworld's driver and app...but wanted to share the driver if Bryan would like to incorporate parts into his driver, as I was able to get responses back from the IP2IR (with @mike.maxwell's help!) and also set up a queue for processing commands. The queue is working great for me, but I've not yet tested the telnetStatus logic (error cases).
/*
* **************** IP2IR Telnet Driver ****************
*
* This driver is designed to send commands to an iTach IP2IR device.
*
* IR Codes can be found using Global Cache Control Tower IR Database, https://irdb.globalcache.com/
*
*/
metadata {
definition (name: "IP2IR Telnet NEW", namespace: "hubitat", author: "hubitat") {
capability "Initialize"
capability "Telnet"
command "sendMsg", ["String"]
}
preferences {
section {
input "ipaddress", "text", required: true, title: "iTach IP2IR IP Address", defaultValue: "0.0.0.0"
input "debugMode", "bool", title: "Enable logging", required: true, defaultValue: true
}
}
}
def installed() {
initialize()
}
def updated() {
initialize()
}
def initialize() {
log.debug "initialize"
// set up message queue
state.msgQueue = []
state.msgInProcess = false
// set up telnet connection
resetConnection()
}
def resetConnection() {
telnetClose()
try {
LOGDEBUG("Opening telnet connection")
telnetConnect([terminalType:'VT100', termChars:[13]], "${ipaddress}", 4998, null, null)
//give it a chance to start
pauseExecution(1000)
LOGDEBUG("Telnet connection established")
} catch(e) {
LOGDEBUG("initialize error: ${e.message}")
}
}
def parse(String message) {
LOGDEBUG("parse: ${message}")
if (message.startsWith("completeir")) {
processResponse()
}
}
def telnetStatus(String status) {
LOGDEBUG("telnetStatus: ${status}")
if (status.startsWith("receive error") || status.startsWith("send error")) {
LOGDEBUG("Telnet connection dropped, reconnecting")
resetConnection()
if (state.msgInProcess) processResponse()
else processQueue()
}
}
def sendMsg(String message) {
state.msgQueue.add(message)
processQueue()
}
def processQueue() {
if (state.msgInProcess) return
if (!state.msgQueue.isEmpty()) {
LOGDEBUG("message queue: ${state.msgQueue}")
def message = state.msgQueue.get(0)
state.msgInProcess = true
sendHubCommand(new hubitat.device.HubAction("""$message""", hubitat.device.Protocol.TELNET))
}
}
def processResponse() {
state.msgInProcess = false
state.msgQueue.remove(0)
processQueue()
}
def LOGDEBUG(txt) {
try {
if (settings.debugMode) { log.debug "${txt}" }
} catch(ex) {
log.error("LOGDEBUG unable to output requested data!")
}
}Most of this was added in this morning update (Post 23 in this thread). Might want to take a look at the current driver. 
Big updates to the App too (Post 26). Will have another app update in the morning once I test some more. Hint: better volume controls
One more update...I think I've covered just about all the requests so far. 
App:
V1.1.3 - 11/02/18 - Added the ability to send multiple Switch On's, Off's or both and Button's to send multiple times with each push. Think volume controls. Also Fixed some typo's.
Following IR code is giving me some errors:
sendir,1:1,1,38000,1,1,10,30,10,70,10,30,10,30,10,30,10,30,10,30,10,70,10,30,10,30,10,30,10,70,10,70,10,30,10,30,10,1657,10,30,10,70,10,30,10,30,10,30,10,70,10,70,10,30,10,70,10,70,10,70,10,30,10,30,10,70,10,70,10,1657","0000 006d 0000 0020 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e 000a 001e 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e 000a 0046 000a 0046 000a 001e 000a 001e 000a 0679 000a 001e 000a 0046 000a 001e 000a 001e 000a 001e 000a 0046 000a 0046 000a 001e 000a 0046 000a 0046 000a 0046 000a 001e 000a 001e 000a 0046 000a 0046 000a 0679
Getting these errors:
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.683:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.663:debugSending Message: sendir...
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.530:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.508:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.478:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.459:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.417:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.380:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.324:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.297:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.256:debugparse ERR_0:0,001
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.228:debugparse ERR_1:1,008
[dev:327](http://192.168.13.46/logs#dev327)2018-11-04 00:07:26.191:debugSending Message: sendir,1:1,1,38000,1,1,10,31,10,31,10,71,10,71,10,31,10,31,10,31,10,31,10,31,10,71,10,31,10,31,10,71,10,31,10,31,10,1792,10,31,10,31,10,71,10,71,10,31,10,71,10,71,10,71,10,71,10,31,10,71,10,71,10,31,10,71,10,71,10,1621","0000 006d 0000 0020 000a 001f 000a 001f 000a 0047 000a 0047 000a 001f 000a 001f 000a 001f 000a 001f 000a 001f 000a 0047 000a 001f 000a 001f 000a 0047 000a 001f 000a 001f 000a 0700 000a 001f 000a 001f 000a 0047 000a 0047 000a 001f 000a 0047 000a 0047 000a 0047 000a 0047 000a 001f 000a 0047 000a 0047 000a 001f 000a 0047 000a 0047 000a 0655
Other codes from same device (Denon receiver) working fine.
All you need is just the first part. (see post #2)
sendir,1:1,1,38000,1,1,10,30,10,70,10,30,10,30,10,30,10,30,10,30,10,70,10,30,10,30,10,30,10,70,10,70,10,30,10,30,10,1657,10,30,10,70,10,30,10,30,10,30,10,70,10,70,10,30,10,70,10,70,10,70,10,30,10,30,10,70,10,70,10,1657
working on it...it seemed to be working but now not...
Thanks!
Ok, not exactly sure what's going on but I've learned a lot more about the device. When I take a correct string as in:
sendir,1:1,1,38000,1,1,10,30,10,70,10,30,10,30,10,30,10,70,10,30,10,30,10,30,10,30,10,70,10,70,10,70,10,30,10,30,10,1657,10,30,10,70,10,30,10,30,10,30,10,30,10,70,10,70,10,70,10,70,10,30,10,30,10,30,10,70,10,70,10,1657
I can send it using Global Cache's iTest program. I get a completeir response and the green light flashes on channel 1. All good.
However when using the exact same code in Send IP2IR here. I'm now getting the "Sending Message:" in the log but nothing ever gets sent to the unit. Not even the green LED flash for channel 1? Double checked IP address. thoughts? All the Hubitat's logs show it's going through.
EDIT: Figured it out. I had to change this line in the driver:
telnetConnect([terminalType: 'VT100', termChars:[13]], "${ipaddress}", 4998, null, null)
to this
telnetConnect([terminalType: 'VT100', termChars:[13,10]], "${ipaddress}", 4998, null, null)
needed a full CR/LF
1 Like
I'm adding more here. So that worked...and then it didn't. What I realized was I was setting it up here in my office...I'd see it working and think great...but as soon as I'd take it to where my equipment in a plug it in and test it would fail. I'd bring it back to the office and play some more...get it to work...and then take it back...repeat.
I think what needed to be done was "initialize" AFTER it's booted up. Anyone else confirm this behavior? I know it's not common because once it's up and running....who turns it off?
Make sure the IP isn't changing when you move it.
DHCP reservation it hasn't changed, and the iTEST program works consistently. There is definitely something up with the link between Hubitat and the device once it's rebooted.
Yup, just tried it. I unplugged my device, waited 30 seconds and plugged it back in. Only way I could regain control was to reboot the Hubitat.
So for now that's the only option if you want to move it around. Hopefully a different solution can be found at some point.
I don't have this problem, and we tested the disconnect quite some while setting up the ethernet to wireless box with the IP2IR. You might check the log and see what message you are getting and make sure it is being handled in the telnetStatus function (with a call to initialize).
Also, the telnetStatus function in the driver waits 60 seconds before running initialize, maybe you weren't waiting that long before attempting to use the IP2IR?
Doesn't come back for me unless I initialize manually..even then it took a few seconds. There has to be a way to keep it connected after a reboot.
