Virtual output with HTTPs

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • Gast

    #1

    Virtual output with HTTPs

    Hi everyone,

    Already posted this in the German section of the forum, but maybe I can get some additional input here.
    I have a Loxone Miniserver Gen. 2 and I am trying to trigger two actions via an HTTPS POST request. The provider of this API does not allow HTTP on these specific requests.

    Loxone, always tries to do these operations via HTTP and I end up getting: Method not allowed.

    Is there anything, any workaround, to allow this? Can't really believe I can't finish my automation because Loxone does not support HTTPS in 2022...

    Thanks
  • yarwoob
    Azubi
    • 14.09.2022
    • 4

    #2
    Did you get anywhere wit this? I'd like to do the same thing but have been told https will not work and some type of intermediary will be required.

    Kommentar

    • Gast

      #3
      I should have updates here. I made a similar post in the german section of the forum.
      Loxone can call https using virtual outputs; in my case i was using a POST with no body; loxone automatically converts this post to a GET. you have to supply an empty bite to trick loxone.

      However, loxone still does not allow me to chain requests, e.g get an authorization for getting data. For these cases I had to use a proxy of sorts (web server running on my NAS) and this web server provides an easy interface for Loxone to call and does all the complex logics that I cannot achieve in Loxone.

      If you post your concrete problem maybe I can throw some ideas.

      Kommentar

      • yarwoob
        Azubi
        • 14.09.2022
        • 4

        #4
        I found the debug log in loxone, I'm new to all this. I managed to debug the whole thing to nearly get it to work. The only problem I have now is that there appears to be some "feature" where loxone forces a "charset=utf-8" additional parameter into the "Content-Type" header which is breaking my call. It seems impossible to stop this happening unfortunately no matter what I try adding into the headers.

        Kommentar

        • Gast

          #5
          Yea, loxone is known to do this defaulting... Like in the body example of POST requests, where if empty, get automatically converted to GET...
          How were you able to debug btw?

          Kommentar

          • yarwoob
            Azubi
            • 14.09.2022
            • 4

            #6
            I used the loxone monitor (Diagnostics->Debug Info from the menu) built into the config tool and set the log level to 3 and filter for "HTC" It shows the full http conversation basically. The API I'm using have acknowledged that it's really their bug and they should allow the charset parameter and will fix. Who knows how long it will take though. I've used IFTTT as an intermediary for now.

            Here's a log example from the monitor:

            00000904 192.168.1.7 18:10:39.887 18:10:41.045 HTC read page 1 maker.ifttt.com /trigger/blinds_close/json/with/key/XXXXXXXXXXXX 8000ms
            00000905 192.168.1.7 18:10:39.887 18:10:41.046 HTC send 197 Bytes
            00000906 192.168.1.7 18:10:39.888 18:10:41.046 HTC send: GET /trigger/blinds_close/json/with/key/XXXXXXXXXXXXXXXX HTTP/1.1
            00000907 192.168.1.7 18:10:39.888 18:10:41.047 HTC send: Host: maker.ifttt.com
            00000908 192.168.1.7 18:10:39.888 18:10:41.047 HTC send: User-Agent: [en]
            00000909 192.168.1.7 18:10:39.888 18:10:41.047 HTC send: Content-Type: text/plain; charset=utf-8
            00000910 192.168.1.7 18:10:39.889 18:10:41.048 HTC send: Connection: close
            00004053 192.168.1.7 18:12:05.087 18:12:06.249 HTC received: Content-Type: text/html; charset=utf-8
            00004054 192.168.1.7 18:12:05.088 18:12:06.250 HTC received: Content-Length: 56
            00004055 192.168.1.7 18:12:05.089 18:12:06.250 HTC received: Connection: close
            00004056 192.168.1.7 18:12:05.089 18:12:06.251 HTC received: X-Powered-By: Sad Unicorns
            00004057 192.168.1.7 18:12:05.090 18:12:06.251 HTC received: X-Robots-Tag: none
            00004059 192.168.1.7 18:12:05.091 18:12:06.252 HTC received: Date: Thu, 15 Sep 2022 17:12:04 GMT
            00004060 192.168.1.7 18:12:05.091 18:12:06.253 HTC received: ETag: W/"38-m5q0NckE5uU6KwW4jhPc5eYFHI4"
            00004061 192.168.1.7 18:12:05.101 18:12:06.253 HTC received: Vary: Accept-Encoding
            00004062 192.168.1.7 18:12:05.101 18:12:06.254 HTC received: X-Cache: RefreshHit from cloudfront
            00004063 192.168.1.7 18:12:05.101 18:12:06.254 HTC received: Via: 1.1 6e05560e2a116f10e93777df92ea6478.cloudfront.net (CloudFront)
            00004064 192.168.1.7 18:12:05.101 18:12:06.255 HTC received: X-Amz-Cf-Pop: LHR50-P4
            00004065 192.168.1.7 18:12:05.101 18:12:06.255 HTC received: X-Amz-Cf-Id: X4ZG5mAAvlEMTRdjlqoraUENpmJEUxi4mJvUd7e4OpmEags2-8w2fA==
            00004066 192.168.1.7 18:12:05.101 18:12:06.256 HTC received: Congratulations! You've fired the blinds_open json event
            00004067 192.168.1.7 18:12:05.101 18:12:06.257 HTC close 18.164.68.20:443

            Kommentar

            • Gast

              #7
              Can you just send another Content-Type such as application/json?

              Kommentar

              • yarwoob
                Azubi
                • 14.09.2022
                • 4

                #8
                I did but no matter what you do it appends the charset=utf-8

                Kommentar

                Lädt...