Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using habridge to send string by tcp #1375

Open
guy1958 opened this issue Oct 18, 2022 · 5 comments
Open

Using habridge to send string by tcp #1375

guy1958 opened this issue Oct 18, 2022 · 5 comments

Comments

@guy1958
Copy link

guy1958 commented Oct 18, 2022

Hello. I've set up the habridge and it's working great. I'm using the command line option to run a small executable that then communicates with my own X10 bridge (connected to a CM11A), ultimately controlling lights. My executable connects to my bridge using a socket connection, and waits for the bridge to acknowledge reception of the string (it sends back "ok") to close the socket.

I see here that the habridge seems to support executing a tcp connection and sending a string. The only example I found on the site is like this:

[{"item":"tcp://192.168.3.3:9000/sendthismessage","type":"tcpDevice"}]

I want to send "A1 ON" to IP address 192.168.0.80 port 554, which is what my command line executable does. So I set it up like this:

Type:
tcp Device

Target item:
[{"item":"tcp://192.168.0.80:554/A1 ON","type":"tcpDevice"}]

Content type:
text/plain

The other fields were left blank (default)

When I try this, I'm not even getting a connection request on my X10 bridge. What am I doing wrong? Thanks.

@beandi
Copy link

beandi commented Oct 18, 2022

I think you need to escape the blank between "A1" an "ON", either by "%20" or by "\ " (both without quotes)

@bwssytems
Copy link
Owner

It already compensates for the spaces in the code. You will need to put a "\n" at the end of the line:

[{"item":"tcp://192.168.0.80:554/A1 ON\n","type":"tcpDevice"}]

@guy1958
Copy link
Author

guy1958 commented Oct 20, 2022

Ah, I think I've found it. Almost stumbled across it really. Looks like the documentation doesn't match how it actually works. All the examples shown like:

[{"item":"tcp://192.168.0.80:554/A1 ON\n","type":"tcpDevice"}]

...assume you're using an alternate editing mode that's not the default. If you click on "Add/Edit" on the main menu, you get the "Edit/Copy a device" menu. The fourth choice there is "Change Edit Mode". If you click on that, then the "On URL", "Off URL",etc. edit areas become single, large boxes. There, you can paste the example I just gave above and it will actually parse it into the individual fields that are more familiar in the device editing menu. If you save the above example in and entry, save it, and then change back to the default editing mode, you will see that Type becomes "TCP Device", "Target Item" becomes "tcp://192.168.0.80:554/12 ON". I also selected "text/plain" in the "Content Type" field though I don't know if that's necessary. And...the item now works! I get a connection to the socket and receive the string.

I'm guessing that the alternate, detailed device editing mode was added in a later version (and became the default), but that the documentation wasn't updated.

There remains one question in my mind: the "Delay" field. Does it simply state how long the bridge will wait until executing a subsequent item line, or does it also specify or affect how long the socket will be held open until it is closed after sending the string to the socket?

@bwssytems
Copy link
Owner

The delay field states how long it will wait until executing the next line, not keeping the socket open as each command is a separate invocation.

@guy1958
Copy link
Author

guy1958 commented Oct 26, 2022

Ok thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants