The reply comes back through parse(). This works except for the first send after opening the telnet port. The response I get on this first call is
ÿûÿûS1MODE:AUTO 1
I think the first 6 "bad" characters are telnet setup responses from the server (IAC WILL ECHO & IAC WILL SUPPRESS-GO-AHEAD) that should have been filtered out by the hub?
My question concerns the "commands" visible on the driver web page. I have implemented the full Thermostat Capability that has 13 commands, most of which are wrappers for the core commands, eg auto() = setThermostatMode(auto). Is there any way I can stop those redundant commands being displayed on the web page?
Ref the telnet interface. I thought when the telnet client connects to the server there was a protocol handshake to establish the connection. These "extra" characters match what you would expect to see in that handshake. In any event I do not see them if a use another telnet client to communicate with the thermostat.
Ref the driver commands: There is no duplication on the web page, I just want to hide some of the redundant commands from the web page. I think you are saying that if the commands are required by the capability they will appear on the web page and cannot be hidden?
yes.. the workaround is to delete the capability and make 100% custom attributes and commands. That may cause a future problem withe selecting the thermostat your driver supports. An App might create a selector with "capability.thermostat" and if your driver doesn't have that, it won't be selectable.
I'd suggest using capabilities and just ignoring the extraneous. In 'normal day-to-day use' the Driver Details page isn't the primary interface. In general, I assume people look at it day 1 when they are testing and then never look again unless there's a problem, Then you'd go back to the Driver Info page and verify everything works there... or not.
@csteele Thanks for the clarification, I suspected as much!
@mike.maxwell In the early days of the driver development I did hook up the telnet server (that the hub talks to) to a Windows telnet client. I do not remember seeing any of those control characters but I will check again.
Ive done most of the telnet driver development and actual device testing and have not seen any other devices issue those characters upon session establishment. So this is definatly something unique to that device.
@mike.maxwell . I tried using the Windows telnet client to talk to my thermostat, it did not return any "extra" characters.
It appears that those extra characters are two telnet commands that start with 0xFF. Surely they should never appear in the output stream unless they were "escaped" by the telnet server. If the server had have escaped them then they would have appeared in the Windows client as well. In other words why is the Hubitat client passing those commands through to the driver code?
Windows telnet is probably only displaying printable characters we dont do that as some devices use extended ASCII characters.
Youre going to need to deal with this in your driver.
Yes, my driver parses what it receives from the telnet stream and resends the command if it fails. I can live with this as the rogue characters only appear on the first send after the hub has established the telnet connection.
However, if the serial endpoint is sending extended ASCII characters, the telnet server should escape the command start byte (0xFF). The telnet client (the hub) should then remove the escape sequence and pass the message through to the driver. Unescaped command bytes should be filtered out by the hub.
