TRV - VER 21 ERROR 400

[agag206]

On the VER 21 the TRV still reporting the Error 400. I tried to download the fixing CLZ but the download link is offline.

[jbasen]

I'll take a look at this. The link to the other clz went away because the change I made in that file was incorporated into v21. However, there is obviously something else going on so I'll have to figure out what that is. Thanks for including the debug information in the post. That should simplify finding the problem.

[agag206]

thanks.

[jbasen]

I am unable to duplicate the problem you are seeing. The TRV I have for testing is on the latest firmware and I'm using the clz file included with v21 of the Shelly demo program. Are you sure you don't have an older version of the clz file (unfortunately they all have the same filename) somewhere on your computer that the S+ compiler might be using instead of the one included with v21? That is the thing that I would think is the most likely cause of the issue you are seeing.

[agag206]

Nop. I'm using the latest file in your download list. TRV has the latest firmware as well. Tested in three different machines and all have the same issue. Maybe your version is an updated one that isn't included in the download file? Just giving my 2 cents here.

[jbasen]

OK. You didn't post any of the debug information before the exception so I can't validate the formatting of the message being sent to the TRV by the software. Also, this occurs at startup when the S+ module polls the TRV for status. Again, guessing here because you didn't include any debugging info before the actual exception. Since the call to poll status is failing, are you absolutely sure that 1) the TRV isn't receiving its IP address through DHCP and that address hasn't changed? 2) that there isn't a typo when you entered the IP address in the parameter field of the TRV module? There is no error checking of those parameters fields to make sure the format of the IP address is correct. So, for example, accidentally substituting a comma instead of a period in the IP address entry will cause an issue like this.

If that doesn't address the issue please include more debugging info leading up to the exception.

Thanks

[agag206]

[jbasen]

I am very sorry and have to apologize. My goal is not to make more work for you. I forgot to tell you something. For the module to show the debugging information I need when you make a capture in debugger I need you to go to the Shelly Comm Manager Module and set the Startup_Debug_Msg_Output parameter to Console. This will tell the modules to send lots of debugging information to the console where it can either be captured in SimplDebugger (if the debugger is in a good mood) or in a separate Toolbox text console window. What I'm really looking for is the exact http message that is being rejected by the TRV and what about the format of that message is incorrect.

Again, I'm very sorry for not telling you this before you went through and collected all this data.

Thanks

[agag206]

No worries man, :) This is the debug I got it on Debugger same on Console.

Checking the TRV status page I get this

I hope this helps is some way

[jbasen]

Thanks. Exactly what I was looking for but it leaves me very confused. Clearly the command http://10.0.0.62/status that the code is sending to the TRV is valid because you can paste it into the address bar of your browser and it works. So, sending that command shouldn't cause a bad request exception. It is if something is blocking the processor from reaching the TRV. Two questions 1) What processor is this running on? 2) If you open up a text console window in Toolbox, connect the Text Console window to your processor, and type, without the quotes, "ping 10.0.0.62" do you get a reply from the TRV? Thanks

[agag206]

I tested in three different processors: din ap3, dmps-150-4k-c and a cp4. In conjunction with two different TRVS and in two different networking setups, all with the same results. Ping works fine in all cases.

[jbasen]

Thanks so much for that. That is pretty definitive.

Please send me the IP address of a processor you want to run a test with. Later today I'll create a test program compiled on my laptop with the TRV IP address 10.0.0.62 and the IP address of the processor you send me. Then I'll give you a download link and, without recompiling, you upload the code that I have compiled to your processor and we will definitively know if this is a computer environment issue or something else.

Thanks for your patience trying to figure this out.

[agag206]

10.0.0.45 Processor IP

Thank you man !

[jbasen]

Sorry. Forgot to ask which processor this is. I've been testing on an MC3 but if I compile for that processor it won't upload to whatever processor is at IP address 10.0.0.45.

Thanks

[agag206]

dmps-4k-150-c and Din-AP-3

[jbasen]

Sorry I wasn't clear. When I compile the code I need to match the processor type that I'm compiling for with its IP address as the processor IP address is included as a parameter in the Shelly Comm Manager module. What is the IP address of your Din-AP-3?

While there isn't a reason that the code shouldn't run on a DMPS I'm not a fan of that platform. It is designed for a commercial environment and Crestron has simply stuffed too much into the single box. Since all my code is specifically designed for a residential environment, the DMPS platform isn't something I directly support. As I said, it should work but...

[agag206]

DIN AP3 = 10.0.0.45

[jbasen]

Thanks. Here is a link for you to download the test version.

https://1drv.ms/u/s!AjlldUMTB6AFgoF6oQetUEs3Hx_QnQ?e=Swg49v

Note: 1) The processor is set to a DIN AP3 2) Processor IP address is 10.0.0.45 3) TRV IP address is 10.0.0.62 4) Startup Debug Msg Output parameter on the Shelly comm manager is set to console

Please don't recompile this. Just open the zip and upload the project to your processor.

Thanks

[agag206]

Well... nothing as well. I changed the TRV for a new one to test that maybe could be the previous device, but same. I can access it over CH, Shelly AP and Chrome/Safari, but over the SIMPL Module doesn't connect.

Shelly - TRV_Poll_Status - Error Polling Status: System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

[jbasen]

I'm going to guess that if you are swapping around with different TRVs that they aren't hooked up to a valve and therefore aren't calibrated. I had a great deal of trouble working with a TRV that was in a non-calibrated state. It doesn't respond the same way the device does when it is installed in a valve and is properly calibrated. This is the normal operating state of the TRV and is how I test my code. I don't have a radiator but just a standalone valve purchased off Amazon for testing that the TRV is installed on.

Here is a version of the Shelly.clz that significantly expands the timeout for the http calls for the TRV. See if this fixes the problem. Otherwise I'm going to need to contact Shelly and talk to them about the issue.

Thanks

https://1drv.ms/u/s!AjlldUMTB6AFgoF771sssFXz3I018w?e=4DfEPq

[agag206]

It makes sense. I'll get a connector. Can you share the model you have ?

[jbasen]

I believe this is it: https://www.amazon.com/Baluue-Radiator-Thermostatic-Temperature-Operator/dp/B08P71LHJV/ You throw away the plastic controller and just attach the TRV in its place to the metal valve assembly. One other thing is that this code supports 3 series processors so the S# code is written with VS2008. CH code is written in much newer versions of VS and the underlying libraries are going to be much more modern in how they support http communications. So, it doesn't surprise me that CH might work in this situation when this code runs into problems. Just curious if the CLZ I included a link to in my last post made a difference.

[mcge89]

Hey, i have the same issue. Shelly 1 is working just fine, but the TRV doesn't connect to my CP3. Ping is pretty bad too. Checked it on various APs.

[jbasen]

Hmm. Do you have multiple TRVs and this is a problem with all of them or do you just have one TRV?

Thanks

[mcge89]

I have four and they all act the same. Also checked the alternative CLZ, no differenz.

[jbasen]

I have asked someone at Shelly for some assistance with this as I don’t understand why I can’t reproduce the problem you’re having. I’ll let you know what I hear from them

[mcge89]

thanks!

[agag206]

Same as here, I still not able to reach the TRVs over the DIN AP3 or any other Crestron processor, although I'm able to control and see the TRV's over Crestron Home and HA.

[agag206]

Hey all any update on this matter?

[jbasen]

I'm still waiting to hear back from Shelly

[jbasen]

I'm continuing to check in with Shelly but they haven't offered a solution yet.

[dimitarm1]

Hello folks. The Shelly TRV uses a power saving mode called Beacon skip. It listens on every 20-th beacon from the router. So the normal working ping to it should be between 100 and 2000 milliseconds (for the default beacon interval of 100mS). I suggest to sniff your network communication with Wireshark and compare successful request for the TRV's status (e.g. from your browser) and a failed one.

[jbasen]

Thanks @dimitarm1 for the information.

But the basic question still remains. I've used the below code to talk to every other Shelly product; including products like the H&T that are also battery operated. How does it need to be modified to work reliably with the TRV. I'm stuck using VS2008 because the code supports older, 3-series Crestron processors that are windows CE based devices.

Thanks

---

string url = "http://" + Device_IP + "/status"; HttpClient client = new HttpClient(); client.TimeoutEnabled = true; client.Timeout = 30; HttpClientRequest request = new HttpClientRequest(); HttpClientResponse response; request.KeepAlive = false; request.RequestType = Crestron.SimplSharp.Net.Http.RequestType.Get; request.Header.SetHeaderValue("accept", "application/json"); request.Header.SetHeaderValue("accept-language", "en"); request.Url.Parse(url); response = client.Dispatch(request);

[dimitarm1]

Everything looks perfect in this snippet. Should work. Can you sniff the network traffic with wireshark, filtered by the TRV's IP address?

[jbasen]

Thanks @dimitarm1

My challenge is that the code works perfectly when I test it. However, the other 2 people on this thread (@agag206 and @mcge89 ) are experiencing the exceptions with the code on their networks. I'm don't know if they are able to use WireShark to sniff their networks and provide more data on what is happening.

Thanks again

[agag206]

Hey All. It is my first time using wireshark, so I don't know if I copy all correct, but below are some feedbacks I got from it once sending the TRV_Poll command on SW.

1801 152.684838 10.0.0.126 10.0.0.133 HTTP 404 GET /status HTTP/1.1 1806 153.904036 10.0.0.126 10.0.0.133 TCP 404 [TCP Retransmission] 49214 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=350 1862 156.387354 10.0.0.133 10.0.0.126 HTTP/JSON 1110 HTTP/1.0 200 OK , JavaScript Object Notation (application/json) 1863 156.387354 10.0.0.133 10.0.0.126 TCP 54 [TCP Dup ACK 1862#1] 80 → 49214 [ACK] Seq=1058 Ack=351 Win=11330 Len=0 1864 156.387471 10.0.0.126 10.0.0.133 TCP 54 49214 → 80 [ACK] Seq=351 Ack=1058 Win=63184 Len=0 1865 156.388656 10.0.0.126 10.0.0.133 TCP 54 49214 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 1867 156.398350 10.0.0.133 10.0.0.126 TCP 54 80 → 49214 [ACK] Seq=1058 Ack=352 Win=11329 Len=0 1939 157.684147 10.0.0.126 10.0.0.133 TCP 66 49226 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 1941 157.947143 10.0.0.126 10.0.0.133 TCP 66 49227 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 1948 158.694089 10.0.0.126 10.0.0.133 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 49226 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 1949 158.700039 10.0.0.133 10.0.0.126 TCP 58 80 → 49226 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 1950 158.700333 10.0.0.126 10.0.0.133 TCP 54 49226 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 1951 158.700748 10.0.0.126 10.0.0.133 HTTP 404 GET /status HTTP/1.1 1952 158.701132 10.0.0.133 10.0.0.126 TCP 58 80 → 49227 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 1953 158.701284 10.0.0.126 10.0.0.133 TCP 54 49227 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 1954 158.704925 10.0.0.133 10.0.0.126 TCP 58 [TCP Out-Of-Order] 80 → 49226 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 1955 158.705009 10.0.0.126 10.0.0.133 TCP 54 [TCP Dup ACK 1950#1] 49226 → 80 [ACK] Seq=351 Ack=1 Win=64240 Len=0 1957 158.761625 10.0.0.133 10.0.0.126 HTTP/JSON 1110 HTTP/1.0 200 OK , JavaScript Object Notation (application/json) 1958 158.761769 10.0.0.126 10.0.0.133 TCP 54 49226 → 80 [ACK] Seq=351 Ack=1058 Win=63184 Len=0 1959 158.763198 10.0.0.126 10.0.0.133 TCP 54 49226 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 1960 158.769585 10.0.0.133 10.0.0.126 TCP 54 80 → 49226 [ACK] Seq=1058 Ack=352 Win=11329 Len=0 2012 162.691387 10.0.0.126 10.0.0.133 HTTP 404 GET /status HTTP/1.1 2014 163.199235 10.0.0.133 10.0.0.126 HTTP/JSON 1110 HTTP/1.0 200 OK , JavaScript Object Notation (application/json) 2015 163.199389 10.0.0.126 10.0.0.133 TCP 54 49227 → 80 [ACK] Seq=351 Ack=1058 Win=63184 Len=0 2016 163.200715 10.0.0.126 10.0.0.133 TCP 54 49227 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 2026 165.262764 10.0.0.126 10.0.0.133 TCP 54 [TCP Retransmission] 49227 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 2027 165.266899 10.0.0.133 10.0.0.126 TCP 1110 [TCP Spurious Retransmission] 80 → 49227 [FIN, PSH, ACK] Seq=1 Ack=351 Win=11330 Len=1056 2028 165.266899 10.0.0.133 10.0.0.126 TCP 54 80 → 49227 [ACK] Seq=1058 Ack=352 Win=11329 Len=0 2029 165.266957 10.0.0.126 10.0.0.133 TCP 54 [TCP Dup ACK 2015#1] 49227 → 80 [ACK] Seq=352 Ack=1058 Win=63184 Len=0 2030 165.285563 10.0.0.133 10.0.0.126 TCP 54 [TCP Dup ACK 2028#1] 80 → 49227 [ACK] Seq=1058 Ack=352 Win=11329 Len=0 2037 167.678905 10.0.0.126 10.0.0.133 TCP 66 49237 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2044 167.940628 10.0.0.126 10.0.0.133 TCP 66 49239 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2052 168.684251 10.0.0.126 10.0.0.133 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 49237 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2054 168.949582 10.0.0.126 10.0.0.133 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 49239 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2057 169.655317 10.0.0.133 10.0.0.126 TCP 58 80 → 49237 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 2058 169.655478 10.0.0.126 10.0.0.133 TCP 54 49237 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 2059 169.655760 10.0.0.126 10.0.0.133 HTTP 404 GET /status HTTP/1.1 2060 169.658185 10.0.0.133 10.0.0.126 TCP 58 80 → 49239 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 2061 169.658352 10.0.0.126 10.0.0.133 TCP 54 49239 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 2062 169.660289 10.0.0.133 10.0.0.126 TCP 58 [TCP Out-Of-Order] 80 → 49237 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 2063 169.660336 10.0.0.126 10.0.0.133 TCP 54 [TCP Dup ACK 2058#1] 49237 → 80 [ACK] Seq=351 Ack=1 Win=64240 Len=0 2064 169.663961 10.0.0.133 10.0.0.126 TCP 58 [TCP Out-Of-Order] 80 → 49239 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 2065 169.664057 10.0.0.126 10.0.0.133 TCP 54 [TCP Dup ACK 2061#1] 49239 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 2066 169.723090 10.0.0.133 10.0.0.126 HTTP/JSON 1110 HTTP/1.0 200 OK , JavaScript Object Notation (application/json) 2067 169.723189 10.0.0.126 10.0.0.133 TCP 54 49237 → 80 [ACK] Seq=351 Ack=1058 Win=63184 Len=0 2068 169.724579 10.0.0.126 10.0.0.133 TCP 54 49237 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 2069 169.730514 10.0.0.133 10.0.0.126 TCP 54 80 → 49237 [ACK] Seq=1058 Ack=352 Win=11329 Len=0 2082 172.687677 10.0.0.126 10.0.0.133 HTTP 404 GET /status HTTP/1.1 2086 173.673622 10.0.0.126 10.0.0.133 TCP 404 [TCP Retransmission] 49239 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=350 2092 174.213542 10.0.0.133 10.0.0.126 HTTP/JSON 1110 HTTP/1.0 200 OK , JavaScript Object Notation (application/json) 2093 174.213542 10.0.0.133 10.0.0.126 TCP 54 [TCP Dup ACK 2092#1] 80 → 49239 [ACK] Seq=1058 Ack=351 Win=11330 Len=0 2094 174.213686 10.0.0.126 10.0.0.133 TCP 54 49239 → 80 [ACK] Seq=351 Ack=1058 Win=63184 Len=0 2095 174.214693 10.0.0.126 10.0.0.133 TCP 54 49239 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 2096 174.232203 10.0.0.133 10.0.0.126 TCP 54 80 → 49239 [ACK] Seq=1058 Ack=352 Win=11329 Len=0 2114 177.679119 10.0.0.126 10.0.0.133 TCP 66 49246 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2117 177.942357 10.0.0.126 10.0.0.133 TCP 66 49247 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 2121 178.568513 10.0.0.133 10.0.0.126 TCP 58 80 → 49246 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 2122 178.568667 10.0.0.126 10.0.0.133 TCP 54 49246 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 2123 178.569087 10.0.0.126 10.0.0.133 HTTP 404 GET /status HTTP/1.1 2124 178.576963 10.0.0.133 10.0.0.126 TCP 58 80 → 49247 [SYN, ACK] Seq=0 Ack=1 Win=11680 Len=0 MSS=1460 2125 178.577066 10.0.0.126 10.0.0.133 TCP 54 49247 → 80 [ACK] Seq=1 Ack=1 Win=64240 Len=0 2126 178.636658 10.0.0.133 10.0.0.126 HTTP/JSON 1110 HTTP/1.0 200 OK , JavaScript Object Notation (application/json) 2127 178.636735 10.0.0.126 10.0.0.133 TCP 54 49246 → 80 [ACK] Seq=351 Ack=1058 Win=63184 Len=0 2128 178.637907 10.0.0.126 10.0.0.133 TCP 54 49246 → 80 [FIN, ACK] Seq=351 Ack=1058 Win=63184 Len=0 2129 178.649034 10.0.0.133 10.0.0.126 TCP 54 80 → 49246 [ACK] Seq=1058 Ack=352 Win=11329 Len=0

[agag206]

Sorry. I forgot to mention, the IP .133 is the Shelly device / 126 computer ruining Wireshark

[agag206]

Here is the DIN AP3 wireshark feedbacks.

230 3.487112 10.0.0.126 10.0.0.45 SSH 102 Client: Encrypted packet (len=48) 231 3.498173 10.0.0.45 10.0.0.126 SSH 150 Server: Encrypted packet (len=96) 232 3.498248 10.0.0.126 10.0.0.45 SSH 230 Client: Encrypted packet (len=176) 233 3.507205 10.0.0.45 10.0.0.126 SSH 102 Server: Encrypted packet (len=48) 234 3.507463 10.0.0.126 10.0.0.45 TCP 54 65393 → 22 [FIN, ACK] Seq=225 Ack=145 Win=253 Len=0 235 3.570364 10.0.0.45 10.0.0.126 TCP 54 22 → 65393 [ACK] Seq=145 Ack=226 Win=7980 Len=0 236 3.571670 10.0.0.45 10.0.0.126 TCP 54 22 → 65393 [FIN, ACK] Seq=145 Ack=226 Win=7980 Len=0 237 3.571732 10.0.0.126 10.0.0.45 TCP 54 65393 → 22 [ACK] Seq=226 Ack=146 Win=253 Len=0 284 7.037945 10.0.0.45 10.0.0.126 SSH 150 Server: Encrypted packet (len=96) 291 7.087019 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=1 Ack=97 Win=250 Len=0 343 12.652567 10.0.0.126 10.0.0.45 SSH 358 Client: Encrypted packet (len=304) 345 12.701999 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 346 12.722005 10.0.0.45 10.0.0.126 SSH 182 Server: Encrypted packet (len=128) 347 12.722137 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=305 Ack=305 Win=256 Len=0 348 12.736758 10.0.0.126 10.0.0.45 SSH 358 Client: Encrypted packet (len=304) 349 12.791649 10.0.0.45 10.0.0.126 SSH 166 Server: Encrypted packet (len=112) 350 12.841325 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=609 Ack=417 Win=256 Len=0 418 22.798252 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 419 22.799626 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 424 23.036044 10.0.0.45 10.0.0.126 TCP 54 22 → 65311 [ACK] Seq=497 Ack=721 Win=255 Len=0 485 25.067454 10.0.0.45 10.0.0.126 SSH 198 Server: Encrypted packet (len=144) 486 25.076519 10.0.0.45 10.0.0.126 SSH 182 Server: Encrypted packet (len=128) 487 25.076594 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=721 Ack=769 Win=254 Len=0 594 35.095636 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 595 35.096114 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 598 35.323385 10.0.0.45 10.0.0.126 TCP 54 22 → 65311 [ACK] Seq=849 Ack=833 Win=254 Len=0 733 45.136282 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 734 45.136826 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 736 45.438902 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=929 Ack=945 Win=254 Len=0 739 46.361773 10.0.0.45 10.0.0.126 SSH 1514 Server: Encrypted packet (len=1460) 740 46.361773 10.0.0.45 10.0.0.126 SSH 130 Server: Encrypted packet (len=76) 741 46.361938 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=945 Ack=2465 Win=256 Len=0 883 56.298079 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 884 56.298393 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 889 56.507100 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=2545 Ack=1057 Win=253 Len=0 933 60.276129 10.0.0.126 10.0.0.45 SSH 358 Client: Encrypted packet (len=304) 934 60.327270 10.0.0.45 10.0.0.126 SSH 166 Server: Encrypted packet (len=112) 935 60.353321 10.0.0.126 10.0.0.45 SSH 358 Client: Encrypted packet (len=304) 936 60.408174 10.0.0.45 10.0.0.126 SSH 166 Server: Encrypted packet (len=112) 938 60.455315 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=1665 Ack=2769 Win=255 Len=0 1019 70.460896 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1020 70.461368 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1021 70.769237 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=2849 Ack=1777 Win=256 Len=0 1110 80.485259 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1111 80.485467 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1112 80.772819 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=2929 Ack=1889 Win=256 Len=0 1196 90.495754 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1197 90.496173 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1198 90.948693 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=3009 Ack=2001 Win=255 Len=0 1276 100.536049 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1277 100.536543 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1278 100.839009 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=3089 Ack=2113 Win=255 Len=0 1370 110.568135 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1371 110.568450 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1373 110.776058 10.0.0.45 10.0.0.126 TCP 54 22 → 65311 [ACK] Seq=3169 Ack=2225 Win=254 Len=0 1411 118.006814 10.0.0.126 10.0.0.45 SSH 358 Client: Encrypted packet (len=304) 1412 118.052541 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1413 118.061612 10.0.0.45 10.0.0.126 SSH 230 Server: Encrypted packet (len=176) 1414 118.061722 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=2529 Ack=3425 Win=252 Len=0 1415 118.072087 10.0.0.45 10.0.0.126 SSH 182 Server: Encrypted packet (len=128) 1416 118.106188 10.0.0.126 10.0.0.45 SSH 358 Client: Encrypted packet (len=304) 1418 118.157287 10.0.0.45 10.0.0.126 SSH 166 Server: Encrypted packet (len=112) 1419 118.204635 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=2833 Ack=3665 Win=251 Len=0 1534 127.374620 10.0.0.45 10.0.0.126 SSH 806 Server: Encrypted packet (len=752) 1535 127.428491 10.0.0.126 10.0.0.45 TCP 54 65311 → 22 [ACK] Seq=2833 Ack=4417 Win=256 Len=0 1645 137.292857 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1646 137.293333 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1648 137.550243 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=4497 Ack=2945 Win=252 Len=0 1757 147.332916 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1758 147.333101 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1760 147.635345 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=4577 Ack=3057 Win=251 Len=0 1936 157.388833 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 1937 157.389276 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 1938 157.683727 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=4657 Ack=3169 Win=251 Len=0 2033 167.501142 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 2034 167.501353 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 2038 167.710113 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=4737 Ack=3281 Win=256 Len=0 2112 177.536773 10.0.0.45 10.0.0.126 SSH 134 Server: Encrypted packet (len=80) 2113 177.537055 10.0.0.126 10.0.0.45 SSH 166 Client: Encrypted packet (len=112) 2115 177.747199 10.0.0.45 10.0.0.126 TCP 60 22 → 65311 [ACK] Seq=4817 Ack=3393 Win=256 Len=0

[jbasen]

Thanks @agag206 Hopefully this will allow @dimitarm1 to figure out what the underlying issue is. Deciphering Wireshark logs is above my pay grade 😀

[dimitarm1]

The log from the TRV_Poll command has many times successful statuses sent from the TRV. Where is the problem? And what are these encrypted packets there in the second log?

[agag206]

Not an expert on Wireshark as I said, but could those encrypted be the communication between Crestron SIMPL Debugger and the Crestron Processor?

[dimitarm1]

As I can see from the first log, the status from the TRV is received by the device at ip .126, and is confirmed at TCP layer by an ACK. I do not see any problem in this communication (e.g. packet 1862 and the following)

[dimitarm1]

I'd like to mention that polling the TRV's status is not a good idea, since it will drain it's battery faster. If you want to know when the status is changed, there are other means like MQTT and COAP in the TRV.

[agag206]

As I can see from the first log, the status from the TRV is received by the device at ip .126, and is confirmed at TCP layer by an ACK. I do not see any problem in this communication (e.g. packet 1862 and the following)

But the 126 is the computer not the processor who is requesting the information .45

[jbasen]

@dimitarm1 - The code only polls the TRV for status a single time, at the startup of the Crestron processor. It does this so the feedback that the code provides to the Crestron system accurately reflects the status of the TRV. Once that is done the code relies on webhooks and response information provided during commands to the TRV to change something to keep the status updated and accurate. There is the ability for a user of the code to poll for status again if, for some reason, the feedback between the Crestron processor and the TRV has gotten out of synch. But, under normal operation that shouldn't be required.

Also, to try and give you more info, if you check back to the post @agag206 made on December 14th you can see the details of the exception being thrown when the Crestron system is not seeing, what it believes, is a proper response from the TRV.

One thing I did tried in the code was to set a 30 second timeout for a response from the TRV to try and take into account the TRV being a battery operated device that would be trying to save power. However, that didn't help resolve the issue

Thanks

[dimitarm1]

I wonder why you are opening each time 2 sockets at the same time with the same GET request. Look at packet 1937 and 1941. the next time is the same. The TRV should handle it with no problem, but what's the purpose of this?

[dimitarm1]

@jbasen -How do you plan to update the current temperature from the TRV using webhooks? There are no actions for reporting temperature in this device. Or you do not need it?

[dimitarm1]

The error from the @agag206 post on 14th Dec shows a socket timeout. But there are 2 consecutive polls, and the first did not fail. Did I get it correct?

[jbasen]

@dimitarm1 - To answer your questions as best I can.

1) There are 3 tiers here. I'm writing a driver to allow Crestron programmers to work with customers (homeowners) who have TRVs. The Crestron programmer may also be a homeowner. When the programmer initializes my driver code for the TRV it performs a single poll of the TRV. The driver provide all the data the TRV offers to the programmer so they can provide whatever information a homeowner feels they need to see. I don't have radiators in my own home so it is harder for me to envision exactly how people use TRVs to better manage this. So, I give people all the data offered by the TRV so I'm not limiting the usability of it. You are correct that there isn't a webhook to update temperature and if someone wants that information to stay current they will have to poll the TRV again.

2) I'm not sure why you are seeing 2 sockets opened. I've posted the code that does the poll and it certainly doesn't do anything that would open multiple sockets. However, I can't say what is happening within the class libraries. See number 3 below.

3) @agag206 - are you manually pulsing the poll input to the module right after pulsing the init input to the module? This could explain a lot of things especially if you are doing it immediately before the TRV has had a chance to respond. It could explain the multiple sockets being opened as well as why @dimitarm1 is seeing the first polling attempt work and the second fail.

Thanks

[dimitarm1]

@jbasen - 2 sockets are seen each time. e.g. here: 1939 157.684147 10.0.0.126 10.0.0.133 TCP 66 49226 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 1941 157.947143 10.0.0.126 10.0.0.133 TCP 66 49227 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 You see the ports for this sockets: 49226 and 49227 and they are used to create the same GET request over the HTTP protocol. Please, be aware that the packets could need retransmission over TCP protocol, and it can easily happen that the second request can be answered before the first one, if both are fired at the same time.

[jbasen]

@dimitarm1 I will post this to Crestron tech support to see if I can get an explanation.