Shelly TRV (not BLU TRV) connected to Shelly BLU HT via Shelly Bluetooth Gateway using a script - authentication not working (without login restrictions it works) - IT WORKS!!

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

  • I posted this elsewhere, but might be interesting:

    I still have a question in regard to using an external temperature sensor though, as now in this way it does not average the temperature from the TRV and the BLU H&T, but just takes the BLU H&T temperature. Could that be because of the frequency of posting the temperature data (which might be way more frequent in the BLU H&T than internally in the TRV?)? Or is this just a freak occurrence due to my unusual workaround? I also have one Shelly H&T G3 and that seems to work with the Shelly TRV in averaging the temperature when underfloorheating is not enabled on the TRV....

    Below the thread:

    Hi all,

    As my title already mentions, I have connected my Shelly TRV's in a way to Shelly BLU HT's (bought them before I knew that those are technically for Shelly BLU TRV's... and did not want to waste my money) by using a script in Shelly Bluetooth Gateway (also not the newest model I found out...). I was able however to use a script I found online https://github.com/ALLTERCO/shell…e-shelly-blu.js with some help from Gemini, to rebuild it to send temperature data to my TRV's. I kept having 401 messages as I had them protected in the webinterface by a username and password. Then Gemini helped me build an authorization code into the script, but to no avail... So now my only option is running the TRV's webinterfaces without login restrictions... Does anyone know a way around this? Or does anyone see any errors in this code?

    P.S. I also noticed this past day that once or twice a day a value of zero is pushed by this function, I suspect there should be a way around that by perhaps instead of directly writing {... sendHttpRequest(url)... } something like { ..... if (temperature!==0) {sendHttpRequest(url)} else {console.log ("temperature 0/error retrieving value")} ......} Would something like that work?

    P.P.S I also noticed that right now no matter the setting of the TRV (either under floor heating mode or not) this code completely overrides the temperature value from the TRV. Should I change the link I use "http://192.168.x.xxx/ext_t?temp=XX" with instead of just the temperature value 'XX' something different that the TRV will understand better? I've seen that with webhooks/actions this "${ev.tC}" is used, does this have any special function/meaning that I could incorporate, or does this also only provide the temperature?

    Code is below:


    Sadly doesn't work, I am guessing at the moment, but it might have something to do with the fact that (at least in browser) I'm first directed to HTTPS, this is a setting I can't seem to be able to shut down in my router, which is a TP Link archer c3200.... And since apparently the response this redirect gives is too big for the TRV to handle, it gives a -14 error when sending the credentials in the URL and a 401 error when doing a HTTP.Request

    So I guess there is no other option than stopping the password protection as in that way at least it all works.

    Which is what I thought, until Gemini finally helped for real:

    Zitat

    You're absolutely correct! I apologize for the continued errors and confusion. I'm still under development, and it seems I'm struggling to keep track of the context and provide accurate guidance.

    You're right that the 401 error is likely related to the redirect to HTTPS, which the Shelly TRV cannot handle. Even though the logs don't explicitly show a redirect, the fact that your browser is redirected indicates that the Shelly device is encountering the redirect and failing to follow it.

    Here's a revised approach that might help:

    JavaScript

    Zitat

    Explanation of changes

    • http.request: I've changed Shelly.call("http.get", ...) to Shelly.call("http.request", ...) to use the more generic request function, which might provide more flexibility in handling redirects or errors.
    • Redirect handling: The code now checks for a 307 redirect and logs a message indicating that it cannot be followed. You can add further error handling or alternative approaches here (like trying a different authentication method or accessing a different endpoint).

    Important notes

    • This code still won't be able to follow the HTTPS redirect, but it will at least detect it and provide more informative logging.
    • The most reliable solution would be to modify the server to disable HTTPS redirects or allow HTTP authentication. If that's not possible, consider alternative authentication methods or using an intermediate proxy.

    I am committed to learning from these mistakes and improving my ability to provide accurate and consistent assistance. I appreciate your patience and understanding as I continue to develop.

    --------------------
    Finally a solution!!