jbasen / Crestron-Shelly

26 stars 1 forks source link

Shelly TRV #21

Closed djma1 closed 2 weeks ago

djma1 commented 2 years ago

Hi,

I just buy from shelly a TRV unit and i try to integrate with crestron RMC 3. When i send the command( for ex send analogic value to change target temperature) is showing a message error as 400 bad request. After i looked and maked some tests i discovered that the sintax is incomplete in dll " image "

It seems that is missing a "/" after 0.

Also i buy from shelly a HT plus sensor and is not comunication .

Please help with this and another modules.

Thank you

jbasen commented 2 years ago

I added the missing "/" that you suggested. I'm in the middle of some other changes to the code so I can't upload a full version. However here is a to download an updated version of the Shelly.clz file so you can test if this works for you. I did have a TRV valve and tested the code with it but it is difficult because I don't have radiator that the TRV can be attached to.

https://1drv.ms/u/s!AjlldUMTB6AFgoFyWPlk6mOSS1HDPw?e=j4yEhu

I may be able to help with the H&T Plus. Please change the Startup_Debug_Msg_Output parameter on the Shelly Comm Manager Module to Console, capture the output when you try to use the Shelly H&T Plus, and post that here.

Thanks

djma1 commented 2 years ago

I tried, but faild...it seems, after i studied the file that is correct .

Now i send a snip with debug....only to see. No hury

image

Thank you

djma1 commented 2 years ago

P.S - Shelly H&T is not receiving because has a wird sleep mode and only when transmit is wake up....this is the first impresion

jbasen commented 1 year ago

First, I uploaded a Shelly.clz file that I believe will fix the TRV polling issue you reported.

Second. I believe I found the issue with the Shelly H&T Plus. The format of the webhooks has changed since I wrote the module. The correct format of the temperature change webhook and humidity change webhook is as follows:

http://[Processor_IP]:[Processor_Port]/plus-ht/sensor/temperature/${ev.tF}/ http://[Processor_IP]:[Processor_Port]/plus-ht/sensor/humidity/${ev.rh}/

The entries in the Simpl+ module help are outdated

Over and under temperature webhooks are not supported on the H&T Plus

The H&T Plus does have an annoying habit of timing out; especially when trying to use the web interface. I found the app a better way of setting the webhooks though it also is a bit finicky and troublesome to edit a webhook that extends beyond the size of the edit field.

Once the webhooks were set I had to press the reset button on the inside of the H&T Plus case to force an update.

Let me know if this addresses the issues you've had

Stevie-Be commented 11 months ago

Hi, I can't seem to get the TRV's connected in my Crestron system.. any ideas? image

Stevie-Be commented 11 months ago

Strange ping result- image

jbasen commented 11 months ago

Hi @Stevie-Be

The only reasons that I can think of why you can't ping a TRV from a crestron processor are:

1) The TRV has gone to sleep to save its battery 2) You have a networking problem.

The first thing I would do is to validate you can ping your TRV from a computer on your network. If you can't then you need to focus on what is going on with your TRV and potentially contact Shelly about the issue. If you can ping the TRV from a computer on your network then I would be looking at what could be blocking communications between your CP3 and the TRV.

The battery on my TRV is dead so I can't look at this in any more detail. I'm recharging the battery and will see if I can come up with anything else.

Thanks

P.S. Just so you know, there is another, very long, closed issue thread on issues controlling the TRV due to a problem with the firmware on the TRV. I'm not sure if Shelly has addressed this or not. The last entry of that thread is as follows:


After a lot of work I wanted to close out this thread.

We've finally figured out what the issue is. The problem is that Shelly is using a product called LWIP (https://savannah.nongnu.org/projects/lwip) in the TRV firmware. If a message from the Crestron processor to the TRV arrives in a single packet, then everything works fine. Unfortunately, if the message from the Crestron processor is broken up into multiple packets, then it turns out there is a known problem with LWIP (https://mail.gnu.org/archive/html/lwip-users/2009-08/msg00203.html) and things break. This is what has been causing problems for some people using my Crestron-Shelly driver with the TRV. A key message in this message thread is:

"Long answer: You have to be careful with the words here. On the IP Layer there is "fragmentation" which is only used when you have an Ethernet packet from a medium that a a bigger MTU (maximum transfer size). SO when a router gets a big packet and needs to send it on a physical medium that cannot handle the size of the packet, it gets fragmented in several IP packets with fragmentation flags. On the TCP layer, there is "segmentation". Because TCP sees data as a stream, it is of course possible to send data that is longer than a single Packet is able to handle. The data is then basically just written into several packets and the other side puts the data stream back together.

LwIP has both features. For a TCP stream that just travels over Ethernet with constant MTU (1500), there will be no IP fragmentation, only TCP segmentation."

So, the problem has to be fixed by Shelly. The bad news is that Shelly's development staff is tied up right now on a project and won't get to address this issue for a couple of months. My understanding is that different MTU settings on the network are what is causing this to fail for some people and work fine for others. I am going to shortly post a new version of code that minimizes the header information of messages being sent to the TRV and therefore minimizes the chance of messages being broken up into multiple packets. That is the best I can do to fix this for people.

Stevie-Be commented 11 months ago

Hi @jbasen Thanks for your swift and detailed response! Ping from cmd works fine, so issue could be that the CP3 is sitting on a power line ethernet extender. I'll test using a long ethernet cable directly on router to see if it solves the issue. Question, do you perhaps know if CoIot and MQTT need to be enabled in TRV web interface? The only actions I set were as per the Simpl/TRV help file (valve open/close). thanks!

jbasen commented 11 months ago

Hi @Stevie-Be You don't need any of those other services. The Shelly-Crestron driver just uses Shelly's http API and relies on actions for unsolicited feedback from Shelly devices. Any other feedback has to be polled for or will be obtained based on the response to commands being sent to the Shelly device.
One other thought. By chance do you have multiple subnets? Is the TRV on a separate subnet from your CP3 because it is a wireless device and your CP3 is wired to your router? Can your CP3 ping other wireless devices in your home? Thanks

Stevie-Be commented 11 months ago

Hi @jbasen No subnets. I can ping all other wireless devices including all Shelly 2PM's from CP3. Shelly HT only replies when it wakes up(which is normal I think). I'll test with a direct LAN cable to router, bypassing the ethernet powerline extender. Will keep you posted. Thanks!

jbasen commented 11 months ago

Hi @Stevie-Be That is normal behavior for the Shelly HT. Let me know. I'm curious as to what is causing this problem. Thanks

Stevie-Be commented 11 months ago

Hi @jbasen Same behavior after bypassing ethernet powerline extender using LAN cable to router.. image Seems pinging from CP3 has different result than pinging from CMD. I thought it could be because of the TRV in sleep mode, but then pinging from CMD should also yield 'no reply'.. I'm seeing with our support guys(I actually work at Crestron), and I've also created a Shelly support ticket to enquire about that LwIP potential issue. I'll keep you posted. thanks

jbasen commented 11 months ago

Thanks @Stevie-Be .

FYI - I just tried pinging my TRV from both my my windows 11 laptop and my CP4. In both cases the ping failed. After that I

1) Entered the address of the TRV in the address bar of my browser 2) Under settings went to Device Discoverable 3) Checked the checkbox for Make Device Discoverable

After that the TRV responded to pings from both my laptop and the CP4 though with the CP4 it failed the first time and then worked after I tried the ping a second time.

Hope this helps

Stevie-Be commented 11 months ago

Thanks @jbasen I tried enabling discoverable but I still get intermittent replies via CP3 with both TRV's(same as when I know the device is 'awake'). image

Will investigate further..

jbasen commented 11 months ago

Hi @Stevie-Be

For what its worth, my pings to the TRV are also inconsistent. The first few ping attempts fail and after that it seems to respond. I'm wondering if this is simply part of the power savings.

Stevie-Be commented 11 months ago

Hi @jbasen It's weird that replies seem fine when pinging from CMD.. I have our advanced support guys looking into it, as I noticed that LwIP URL in debugger during one of my TRV polls.. I'll keep you posted! and also what Shelly come back with.

thanks!

jbasen commented 11 months ago

Hi @Stevie-Be I've also made a request with Shelly to see if they have ever replaced LwIP in the TRV firmware. The fact you saw an LwIP url in debugger is not good news.

Stevie-Be commented 11 months ago

@jbasen Here's that debugger grab after waking both TRV's and polling them- image

Stevie-Be commented 11 months ago

Hi @jbasen Here was the reply from Shelly-

Dear Steve, Thank you for reaching out to us! Regrettably, this falls outside the purview of our support as it constitutes an unofficial integration with our devices. We regret that we cannot provide further assistance. Kindly contact the developer responsible for the integration. Best Regards, Shelly Support Team

jbasen commented 11 months ago

Hi @Stevie-Be

I have the ability to find out if LwIP has been removed yet. I have posted the question and I'm waiting for a response. It just may take a little while for the response.

If it hasn't been removed then you can try communicating with the TRV from your Crestron program but it may, or may not, work. It gets into a lot of things outside your your, or my, control on your network. I went down this path with someone with 27 TRVs in their house and there wasn't a solution other than waiting for Shelly to remove LwIP from the TRV firmware and replace it with something else. Unfortunately, that just doesn't appear to be a high priority for them :-(

Thanks

Stevie-Be commented 11 months ago

Hi @jbasen No worries. I'll take a look into the Cresron Home module to see if I find anything as it's an official driver.. Do you know of any other TRV's that have been successfully integrated with Creston?

Thanks!

jbasen commented 11 months ago

Hi @Stevie-Be Sorry, I only hear when people have problems. Thanks

jbasen commented 11 months ago

Hi @Stevie-Be I just wanted to let you know that I heard back from Shelly. LwIP is still used in the TRV firmware and that there are no plans by Shelly to fix the problem. So, I can't make any guarantees that Crestron-TRV control will work. Depending on network configuration and what Crestron is doing with their firmware on different processors this could work or may not. Wish I had better news. Thanks

Stevie-Be commented 11 months ago

Hi @jbasen Thanks for the update! I'll see if any of our guys can take a look at the api. Will stay in touch! Thanks!

Stevie-Be commented 11 months ago

Hi @jbasen Here's the reply from the Crestron Home module developers-

image image

I'm going to request the API and see if I can create a basic HTTP module for the TRV. Will keep you posted.

thanks!

Steve

jbasen commented 11 months ago

Hi @Stevie-Be

LwIP is not a protocol. It is an open source software module (https://en.wikipedia.org/wiki/LwIP) that Shelly has used as part of the TRV firmware.

Also, the protocol for Shelly devices is fully documented and can be viewed by anyone - https://shelly-api-docs.shelly.cloud/

My modules all communicate with Shelly devices, including the TRV, using http requests as is documented in the protocol. I used http, and not https, so the code will run on an MC3. The full source code is on this GitHub including all the S# code that implements the http requests.

Maybe another set of eyes will uncover why there is an issue with the code I've written to communicate with the TRV so you are welcome to dig in and play with it.

Stevie-Be commented 11 months ago

Hi @jbasen Thanks for the info. I have some of our guys looking in to this as my Simpl+ knowledge is limited. I'll keep you posted!

thanks

jbasen commented 2 weeks ago

For those that want to integrate a TRV with a Crestron system I have a new approach. I haven't tested this but I believe it will work just fine. I just published an article on the integration of a Crestron system with Home Assistant. That article can be found here:

https://restechtoday.com/my-experience-integrating-crestron-and-home-assistant/

So, using the technique I discuss in the article you could integrate the Shelly TRV with a Crestron system using Home Assistant as a gateway.

Thanks