We bought a Global Cache iTach IP2IR, and using the awesome driver and app put together by @bptworld, have not been missing the Harmony hub!
But we have run into timing issues when setting the TIVO channel. TIVO can take up to 4 digits and doesn't require an enter key, and we get skipped digits quite often, even with pauses in between the commands. So reading through the iTach API, it should be returning a status for every command, and I decided to put a queue in the driver and wait for status before sending another command.
After testing last night, no responses are being returned. I had put the following in, with a log.debug inside, but it never logs:
def parse(String msg) {
// process incoming telnet messages
}
I know nothing about telnet, but decided to try to test outside of Hubitat by enabling the Windows 10 telnet client. Closed the iTach connection with Hubitat and tried to open within the telnet command line (with the proper IP and port). But it never connected to the iTach, just sat there saying connecting.
Can't answer your specific questions since I don't have a Tivo but the driver just got a major update that should help with missing channels.
I'll be making additional changes to the app. Going to make the 'enter' key optional and also make a fourth digit optional. The latter being a lot more work, will see how it goes.
I'll be posting the updates in the Send IP2IR main thread.
More testing. I used PuTTY, am able to connect to the IP2IR and send a command, and get a response back.
The commands are successfully sent to the IP2IR from the device driver, but no response is being processed by the parse routine.
Here is the WIP device driver code. I commented out the "runIn(1, processResponse)" but processResponse never got called so it is back in to allow commands to be processed with a delay.
/*
* **************** 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"]
command "disconnect"
}
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'], "${ipaddress}", 4998, null, null)
//give it a chance to start
pauseExecution(1000)
LOGDEBUG("Telnet connection established")
} catch(e) {
LOGDEBUG("initialize error: ${e.message}")
}
}
def disconnect() {
telnetClose()
}
def parse(String message) {
log.debug "parse: ${message}"
processResponse()
}
def telnetStatus(String status) {
LOGDEBUG("telnetStatus: ${status}")
resetConnection()
}
def sendMsg(String message) {
state.msgQueue.add(message)
log.debug "sendMsg: message queue: $state.msgQueue"
processQueue()
}
def processQueue() {
if (state.msgInProcess) return
if (!state.msgQueue.isEmpty()) {
def message = state.msgQueue.get(0)
state.msgInProcess = true
log.debug "processQueue: sending message $message"
runIn(1, processResponse)
sendHubCommand(new hubitat.device.HubAction("""$message\r\n""", hubitat.device.Protocol.TELNET))
}
}
def processResponse() {
state.msgInProcess = false
state.msgQueue.remove(0)
log.debug "processResponse: message queue: $state.msgQueue"
processQueue()
}
def LOGDEBUG(txt) {
try {
if (settings.debugMode) { log.debug "${txt}" }
} catch(ex) {
log.error("LOGDEBUG unable to output requested data!")
}
}
this is likely a termination character issue, by default our telnet implementation will append CR/LF (decimal 10,13) to every send, and will take the contents of the telnet receive buffer and return that to the driver parse method when it finds a CR/LF pair in the buffer.
So if the iTach is terminating the the command sent reply with just a CR, or just LF, or LF/CR then things will get messed up.
Is there a way I can check the termination characters in PuTTY? I see in the driver that \r\n is being appended to the message and the IP2IR doesn't have a problem with that. I wonder if it is even necessary?
Edit: hubby just looked at the PuTTY output and because the cursor is at the beginning of the line with the response, he thinks it only returns CR.
Would you guys be able to fix this or is there something I can do on my end? You are more than welcome to look at my hub if that would help.
