Sending HTTP POST - tons of different commands

Configuration
1

This is an example URL for what I’m going to send:

(http://192.168.1.100:9876/nodered.html?1=Nettradio&2=6&3=1&4=SECRET_PASSWORD)

This sends a command to Promixis Girder (yeah, it’s old, but so am I!) It’s totally stable (which I may not be) and I like to program in LUA. I have around 8000 lines of code in it, and I really don’t fancy doing all my stuff again, when it works perfectly. In this case it runs web radio (“Nettradio”) in zone 6 (the bathroom) with channel 1 (Norwegian NRK P1). This is done with Foobar, which also is totally stable. I am triggering it from a webpage directly in Girder, but I want to trigger it with Namron K8 8 channel Z-Wave switches in the different rooms as well. This would then go from Z-Wave JS UI to Hass, where the same button does a few other things, depending on the room. And I’d use a template to translate the button pressed to the correct zone and channel.

I have gotten the setup to work on a few test channels, but to send the commands from Hass is too messy. I have to send MQTT from Hass to Node-RED, which then POSTs to Girder. I’d like to run it directly from Hass.

I have tried to read a bit around and it seems like REST is the thing that can do this. But if I have understood that correctly, I would have to have separate entries in configuration.yaml for each command, which is very messy. Or have I misunderstood? I have tried to look for a HTTP/REST plug-in that can do this more elegantly, but I haven’t found one. Does this mean that the multiple entries in configuration.yaml is the only way? I have 12 zones at the cabin and 16 in the house, and each can take 16 radio channels (by long pressing the buttons). That means that I would have 192 and 256 entries in the yaml file.

2

So your Node red is not running inside HA?
Since you already know Node red, why not install Node red in HA and use Node red to communicate with the other Node red?
With Node red you can adapt the url before triggering it.

3

RESTful Command payload is templatable. What sort of POST commands are you looking to send? Example in the documentation shows how this can be done:

It may be possible to transform your “8000 lines” into something useful without manually redoing it all. If it’s not confidential, pop it on Pastebin or similar and explain what you need.

4

@Hellis81 I do not want to run inside Hass, I have them in their own Docker containers, and they’re staying there. :grin:

@Troon The thousands of lines of code is not just this, it’s everything of the more advanced functions running in my house and cabin. I just mentioned that to explain why I’m using Girder. And I had an example of the POST command up in the first post. But if it’s templateable, I may be able to get it working, yeah. I had not understood that. I’ll better do some more reading… I didn’t think it could actually use the template as part of the URL, the way it’s shown in the first post. So much is easier with Hass, but sometimes stuff is just so complicated compared to programming in Node-RED, Python or LUA.

5

You can, url is also templatable.

That’s not a POST command.

If it has the query parameters in the URL, it’s a GET.

Not sure I agree: but you have to understand how HA works to get the best out of it. That’s true with everything though: Node-RED looks horrible to me because I’ve never used it, nor do I plan to.

6

Read my previous comment again.
You can use Node red for this part also.

7

Sorry, wrong spot…

8

Use the official docs as your primary reference. A lot of other “tutorials”, especially videos, may well be out of date to the current state of HA.

Don’t even consider ChatGPT…

We’re usually a helpful bunch so do post again with any specific questions.

9

@Troon Thanks! ChatGPT? Did I mention that I’m old? :grin: That’s not happening any time soon. But if I may try with a specific question: What would I have to put in the configuration.yaml so that I could fill inn the places with bold? The all the rest would be in the automation call.

(http:)//192.168.1.100:9876/nodered.html?1=Nettradio&2=6&3=1&4=SECRET_PASSWORD

Edit: had to put the paranthesis around http: to stop the forum page from not showing bold and trying to open the webpage. Those should not be a part of it, it’s the link without paranthesis.

10

What’s your intent for a user interface? How you plan to choose and select the various parameters will influence the best way to set them up.

Look up the various types of Helper — the input select type might be very useful here.

11

I already have the GUI, this is in addition to that, and it’s going to be run by the K8 Z-Wave wall switches, as I said in the first post. So pressing button that sends scene 1 should send the number of the scene and the name of that button, which tells the system what zone it is.

12

How are those wall switches exposed to HA? Are they buttons, switches or something else?

Could you give some examples of a few of the switches’ entity IDs and the commands they should send?

Is it always three parameters plus secret?

Here’s how I’d do this, with some reusable templates (macros) to store the mappings from switch ID to parameters, plus a simple automation. Set up your rest command called girder with p1, p2 and p3 as the three elements of the URL:

rest_command:
  girder:
    url: http://192.168.1.100:9876/nodered.html?1={{ p1 }}&2={{ p2 }}&3={{ p3 }}&4=SECRET_PASSWORD
    method: GET

then this for the macro in /config/custom_templates/girder.jinja:

{% macro entity_map(e) %}
{{ {
  'k8_switch_1': ['Netradio', '1', '6'],
  'k8_switch_2': ['Spotify',  '0', '6']
  }.get(e.split('.')[1], None)|to_json }}
{% endmacro %}
{% macro p1(e) %}
{{ (entity_map(e)|from_json)[0] }}
{% endmacro %}
{% macro p2(e) %}
{{ (entity_map(e)|from_json)[1] }}
{% endmacro %}
{% macro p3(e) %}
{{ (entity_map(e)|from_json)[2] }}
{% endmacro %}

Then this for the automation, keeping it nice and simple:

trigger:
  - platform: state
    entity_id:
      - button.k8_switch_1
      - button.k8_switch_2
action:
  - service: rest_command.girder
    data:
      p1: >
        {% from 'girder.jinja' import p1 %}
        {{ p1(trigger.entity_id) }}
      p2: >
        {% from 'girder.jinja' import p2 %}
        {{ p2(trigger.entity_id) }}
      p3: >
        {% from 'girder.jinja' import p3 %}
        {{ p3(trigger.entity_id) }}

You then just need to complete the mapping in the macro (currently lines 3 and 4 in that file) and add the other switches to the list in the trigger.

Macros only return strings, hence all the |to_json and from_json to handle the returning and splitting of the mapping object.

13

@Troon Thanks! I got the first part working, with the REST command:

rest_command:
  girder:
    url: http://192.168.1.100:9876/nodered.html?1={{ kommandoklasse }}&2={{ kommando }}&3={{ sone }}&4=SECRET_PASSWORD
    method: GET
    verify_ssl: false

Calling the service as a test with:

service: rest_command.girder
data: {"kommandoklasse" : "JRMC", "kommando" : "Play", "sone" : "6"}

That starts playback in the bathroom, works like a charm. :+1:

As or the buttons, I found I have to use a separate automation that calls each station or playback since I use standard press and long press to get 16 different actions out of each keypad (with printed tags for each button on a Brother marker macine). But it isn’t a problem, really. I just make the first keypad and duplicate that part of the automations with the code for the keypad as the only change.

Oh, and yes, I have the password (which is used only for that one thing) visible in the configuration.yaml, but nobody can read it on this headless Pi without having the strong passwords that I have on both VNC and SSL connection. And they would have to be on the inside of my network too. Or break in and steal the MicroSD, but that would probably bee a whole different problem! :rofl: