IP / Serial Plugin for HS3 (by "drule") - Discussion Thread

[brink0423@gmail.com]

Is anyone interested in utilizing drhslpPlugin to control QMotion Blinds? I have 18 QMotion Blinds in my home and ahve been using this Plugin for three years to control them. I learned all the QMotion Control Codes with an IP Monitor on my home network. This Plugin has worked without error for three years!

-Mark

[heatvent]

Wondering if someone can help me with this. I have a Control4 C4 amp that I would like to control with HomeSeer. I am thinking I should be able to do this with this plugin but this is a bit over my head so I probably need some help going in the right direction. I found this Home Assistant (python I think) add-on that can control the C4 AMP by UDP commands:

https://github.com/kmakar89/Home-***...es/__init__.py

I also stumbled across an old thread which is apparently related where there is some explanation of the commands used by the amp:

https://community.volumio.org/t/help...l-setup/291/11

I am trying to figure out how to setup the plugin to send the proper commands via UDP. If anyone can help me decipher how to do this it would be greatly appreciated.

Thanks!

[drule]

Yes, I think that can be classified as a bug. The plugin does resend the entire message as it grows through concatenation, up until the timeout or max size is reached.

The native HS4 plugin that I am currently working on will allow you to set different timeout values for each connection. I'll also make it so that no message is sent until the timeout is reached. This should allow messages to concatenate and get sent as one.

-David

[pete@malibubeach.com]

UPDATE: the problem below was easily solved:
dim Lastmessage as string = ""
public sub main(param as object)
Dim TokenToProcess as string = replace(param(2),Lastmessage,"")
LastMessage = param(2)
...... code to process TokentoProcess

Lastmessage has to be outside the scope of main so it remains from call to call.
--------------------------------------------------------------------------------

Got a problem -- don't think it has appeared in this thread, but I may be wrong .. if so, my apologies. Trying to talk to a Marantz receiver. Everything is good EXCEPT the plugin is sending duplicate messages to my script (TCP persistent connection on Port 23). I don't mind it concatenating messages, if it were to hold the message and send it all. But it is sending the messages when received and if the concatenation timeout has not expired, it simply concatenates the the previous message so I get the first message repeated. I have the concatenation interval all the way down to 2 msec and I still have the same result even though Wireshark says the messages are coming in 4 to 6 milliseconds apart. If I turn that interval down to 0 I get a different problem. It processes the first message and then loses a bunch with an error in the log:

Jul-23 12:37:00

drhsIpPlugIn

Starting Tcp client for Marantz SR5014 at address 192.168.10.24:23

Jul-23 12:37:00

drhsIpPlugIn

Watchdog restarting stalled connection for Marantz SR5014

I think I can always save the previously message and compare the new message with the old and strip out any repeated portion (pretty simple with 'replace'). Is there some other way to prevent this behavior (again, the concatenated messages are fine, but the repeat is not)

Here is the Homeseer log with a line printed at the entry to Main() printing the three parameters received from drhsIpplugin

Jul-23 12:19:35

TCPHandler

Main; param(0)=Marantz SR5014; param(1)=192.168.10.24:23; param(2)=DCAUTO

Jul-23 12:19:35

TCPHandler

Main; param(0)=Marantz SR5014; param(1)=192.168.10.24:23; param(2)=MVMAX 85

Jul-23 12:19:35

TCPHandler

Main; param(0)=Marantz SR5014; param(1)=192.168.10.24:23; param(2)=CVFL 50 CVFR 50 CVEND

Jul-23 12:19:35

TCPHandler

Main; param(0)=Marantz SR5014; param(1)=192.168.10.24:23; param(2)=CVFL 50 CVFR 50

Jul-23 12:19:35

TCPHandler

Main; param(0)=Marantz SR5014; param(1)=192.168.10.24:23; param(2)=CVFL 50

There were, in fact, 5 messages from the Marantz device: "CVFL 50", "CVFR 50", "CVEND", "MVMAX 85", and "DCAUTO" In this case it is not a big deal to process them multiple times (for example the CVFL 50 gets processed three times. But in other cases there are 20 or 30 messages that all get bundled together. The attachments are a PDF file of the Wireshark output showing the TELNET packets and also the raw Wireshark capture file (put into a zip fie because it wouldn't let me upload a .pcap file). As you can see the CVFL packet and the CVFR packet are separated by about 5.8 m-sec and then there is 4.5 msec before the CVEND. And then much longer breaks (65 and 95 msec) for the next two packets which are split up by the plugin. Is there a solution (other than my script looking for duplication)? And the timeout I have set for concatenation in the plugin is 2 sec (way down from the default).

[drule]

The maximum is currently hardcoded to 1024 bytes. I think it is a good idea to have a method to adjust this but as I'm currently working on a native HS4 version of the plugin, I'm not planning on making updates to the HS3 version. That said, it would be simple for me to simply increase the hard maximum to something bigger. PM me with your email address and I'll send you a version with a changed limit.

[simonmason]

I am getting the error message "concatenated string exceeds maximum" on some of the commands back from the Russound. I see in this thread that some people adjusted the timeout to have it break the strings up in smaller chunks. I went down to 25 MS but it didn't seem to make much difference. I think it is because the Russound is sending out periodic status elements that are really that long. Is there anyway to increase the size of the incoming data? Here is an example:

Jul-18 8:30:23 AM

drhsIpPlugIn

concatenated string exceeds maximum

Jul-18 8:30:23 AM

MPX-1

Connector: Russound | IP Address: 192.168.2.122:9621 | Data: S N C[1].Z[1].name="CHA5" N C[1].Z[1].treble="0" N C[1].Z[1].balance="0" N C[1].Z[1].loudness="ON" N C[1].Z[1].turnOnVolume="40" N C[1].Z[1].doNotDisturb="OFF" N C[1].Z[1].currentSource="1" N C[1].Z[1].volume="25" N C[1].Z[1].sleepTimeDefault="15" N C[1].Z[1].status="ON" N C[1].Z[1].mute="OFF" N C[1].Z[1].partyMode="OFF" N C[1].Z[1].bass="0" N C[1].Z[1].page="OFF" N C[1].Z[1].sharedSource="OFF" N C[1].Z[1].sleepTimeRemaining="0" N C[1].Z[1].lastError="" N S[1].name="Media Streamer" N S[1].type="Russound Media Streamer" N S[1].Support.favoritesV2="TRUE" N S[1].Support.MM.longList="TRUE" N S[1].Support.MM.restoreOption="TRUE" N S[1].Support.availableControls="TRUE" N S[1].Support.trackTime="TRUE" N S[1].Support.playTime="TRUE" N S[1].Support.playerData="TRUE" N S[1].channelName="076 Symphony Hall" N S[1].coverArtURL="" N S[1].channelArtURL="http://pri.art.prod.streaming.siriusxm.com/images/channel/20180725/symphonyhall-1-31-00-180x180.png" N S[1].mode="SiriusXM" N S[1].shuffleMod

[simonmason]

It looks like all commands sent to a Russound device need to be terminated with a carriage return and all commands received are terminated with carriage return and linefeed. Try changing your "Russound Watch On" command to Type: C Escaped and add \r to the end.

This worked! I need to learn more about C Escape. Never heard of it before - I have a lot to learn! Thanks.

[drule]

It looks like all commands sent to a Russound device need to be terminated with a carriage return and all commands received are terminated with carriage return and linefeed. Try changing your "Russound Watch On" command to Type: C Escaped and add \r to the end.

[simonmason]

I think you need single connector, defined as a TCP Client with the Persist option checked.

In this mode, the plugin will initiate a connection and keep it open so that data can pass in both directions.

Thanks, I made the suggested changes. I am sending a command that should result in a continuous feed of content coming back from the unit. When I issue this command the script is not being called.

I tried adding \r\n to the end of the ASCII string and this didn't do anything either.

I am sure I am missing something simple here? Thanks.

[drule]

I think you need single connector, defined as a TCP Client with the Persist option checked.

In this mode, the plugin will initiate a connection and keep it open so that data can pass in both directions.

[simonmason]

Newbie help. I am trying to set this up for the first time to talk to a Russound MPX PRE. I have the IP address and the port number. Went through the documentation and as much as I could in this forum but not having much luck. This is what I setup so far. I assume this would get some response in the log but I am sure I have completely wrong. Any help would be appreciated. Thanks.

[reggs11]

Found it. Its Malwarebytes. I've had this installed for years also but with Web Protection ON it now blocks the pluggin.
This is new behavior which I can only seem to change by switching Web Protection off.
Even when I allow a specific exception to the pluggin, HS3 and the entire HS3 directory its now still blocking all UDP traffic from the pluggin. I've even allowed a specific exception to the switchers IP address.
None of these measures have been an issue previously and Malwarebytes doesn't even report a problem.

This is infuriating but at least I now know what the problem is even if I don't seem able to fix it ! Thanks for the suggestions drule.

[drule]

Apologies drule, its not Putty I'm sending UDP with its Hercules (https://www.hw-group.com/software/he...-setup-utility) I just say Putty as a generic term really.
The commands I send are simple C Escaped characters and spaces. They've worked for 2 years no problem. This format
@ T 00 00 !

The 00's are input and output starting at zero. So @ T 00 01 ! selects Input 1 output 2. Like I say these used to work fine.
If I send exactly the same command with Hercules the switch changes normally. Something must be corrupted with my installation I just don't know what it is and would prefer not to reinstall everything again. Wireshark would pick up the UDP packet right? I'm sure it used to and it picks up the packets from Hercules fine.

I just setup a matching connection/command on my test server and can see the packet being sent from the plugin with Wireshark.

I'd start by checking your Windows firewall rules. Perhaps temporarily disable it altogether? I can't imagine a problem with Homeseer and/or the plugin, that would cause things to get as far as the plugin outputting "sending" to the console but not actually sending the command. Especially as you say it is sending other command formats. Presumably you are running Wireshark and Hercules on the same machine as Homeseer and Wireshark is showing yourip -> 192.168.0.80:5000 when you send the command from Hercules?

[reggs11]

That said, are you sure that you are sending UDP from Putty? I'd have expected TCP from putty. Can you give us some more info on the switch and the commands it uses?

Apologies drule, its not Putty I'm sending UDP with its Hercules (https://www.hw-group.com/software/he...-setup-utility) I just say Putty as a generic term really.
The commands I send are simple C Escaped characters and spaces. They've worked for 2 years no problem. This format
@ T 00 00 !

The 00's are input and output starting at zero. So @ T 00 01 ! selects Input 1 output 2. Like I say these used to work fine.
If I send exactly the same command with Hercules the switch changes normally. Something must be corrupted with my installation I just don't know what it is and would prefer not to reinstall everything again. Wireshark would pick up the UDP packet right? I'm sure it used to and it picks up the packets from Hercules fine.

[drule]

The output seems fine there. I repeated a few different strings

26/05/2020 16:48:13:[drhsIpPlugIn]->Sending Udp packet to 192.168.0.80:5000
26/05/2020 16:49:43:[drhsIpPlugIn]->Sending Udp packet to 192.168.0.80:5000
26/05/2020 16:49:44:[drhsIpPlugIn]->Sending Udp packet to 192.168.0.80:5000
26/05/2020 16:49:45:[drhsIpPlugIn]->Sending Udp packet to 192.168.0.80:5000
26/05/2020 16:49:45:[drhsIpPlugIn]->Sending Udp packet to 192.168.0.80:5000

It is definitely not sending data though. From the same machine if I send packets with a different program, Putty etc Wireshark picks up the data and the switcher responds correctly.

If the plugin gets that far and there are no errors, then the plugin is sending the data. Whatever is happening is doing so outside of Homeseer. Windows firewall perhaps? That said, are you sure that you are sending UDP from Putty? I'd have expected TCP from putty. Can you give us some more info on the switch and the commands it uses?