Also, im http Thing musst Du eine Base URL eintragen. Das ist
mindestens der FQDN oder die IP von Deinem Zielsystem (also FHEM), mit vorangestelltem http://. Mindestens deshalb, weil Du die URL auch beliebig weiter ergänzen kannst. Die Base URL könnte also
lauten, aber genauso gut auch
Wichtig ist nur, dass alle Channel diese BaseURL für alle URL Felder verwenden, ergänzt um weitere Teilstrings. Im ersten Fall kannst Du also alles auf der IP ansprechen, was auf Port 80 läuft (Standardport...), im 2. Fall nur den Teil, der in der Serverstruktur unterhalb irgendein/Unterordner/ liegt (und dieser Server muss auf Port 8080 lauschen).
Wenn Du nur exakt eine URL ansprechen willst, kannst Du die URL auch vollständig als baseURL eintragen (das sieht auf Deinem Screenshot so aus).
Im nächsten Schritt brauchst Du einen Channel, über den Du den Befehl (bzw. die Information) senden kannst.
Nun muss aber (gerade bei GET) noch irgendwie ein dynamischer Teil in die URL rein, schließlich willst Du nicht pro gemeldetem Zustand ein Thing anlegen. Du musst also fast zwingend im Feld command URL extension etwas eintragen. %2$s ist dabei der Platzhalter, welcher durch den Befehl ersetzt wird. Du kannst an dieser Stelle auch noch eine Manipulation des Befehls vornehmen, das ist z.B. wichtig bei Schaltern, die nur die Befehle ON und OFF kennen. Vielleicht erwartet der http Server aber 1 und 0 statt ON und OFF.
In Deinem Fall wirst Du aber ohnehin mit einem String besser fahren.
Es fehlt noch ein Detail, was gerne bei Neulingen für Verwirrung sorgt, nämlich ein Item. Dieses Item wird mit dem Channel verknüpft.
Dazu muss man wissen, dass openHAB intern einen eigenen "Bus" hat, den openHAB Bus. Alles, was irgendwie gesteuert oder angezeigt werden soll, muss auf diesen Bus. Und Items sind die Speicher des Busses. Ein Item kann einen Status halten (je nach Typ) und Befehle senden und empfangen. Wenn ein Item einen Befehl sendet, dann leitet es diesen Befehl an alle Channel weiter, mit denen es verknüpft ist. Da Du den Channel als String Channel nutzen willst, musst Du auch ein String Item verknüpfen (das ist aber nicht unbedingt zwingend...
)
Der Itemname kann nachträglich nicht geändert werden (genau wie Thing Name und Channel Name), man sollte also direkt beim Anlegen genau überlegen, wie das Item heißen soll, sonst muss man später das Item löschen und neu anlegen.
Verknüpfungen zwischen Channel und Item können hingegen jederzeit geändert werden.
Wenn Du das Item soweit hast, brauchst Du nur noch eine Rule (oder auch mehrere Rules, ganz nach Belieben), die bei Änderung des Thing Status einen String an das Item sendet (welches diesen String dann an den Channel schickt...)
Das sieht sehr komplex aus, die Idee dahinter ist aber einigermaßen sinnvoll. Things repräsentieren in openHAB externe Hardware (wobei der Begriff Hardware hier maximal dehnbar ist - z.B. gibt es mit dem Astro Binding Sonne und Mond als Things, oder auch mit OpenWeatherMap das Wetter an beliebigen Orten. das ist natürlich keine Hardware im klassischen Sinn. Bei Geräten wie einem per mqtt gesteuerten Zwischenstecker ist das aber ganz passend, und daher kommt letztlich das Bild).
Die Channel repräsentieren dann einzelne Eigenschaften dieses Geräts, wie z.B. die Schaltstellung eines Relais oder die Helligkeit einer angeschlossenen Lampe (mitsamt dem Steuerbefehl, um den Zustand zu ändern).
Danach (also in dem Moment, wo diese Channel mit Items verbunden sind) gibt es keine Abhängigkeiten von der verwendeten Hardware mehr, es spielt keine Rolle, ob ich nun Homematic, knx, mqtt, http, zigbee oder zwave verwende, es spielt keine Rolle, ob es um einen Staubsauger, einen Fernseher oder den Rasensprinkler geht. Es gibt nur noch eine sehr begrenzte Anzahl möglicher Befehle, mit denen alles abgedeckt werden kann.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet