http post von OH2 auf OH3

[udo1toni]

Stimmt, beim Dimmer ist es so, dass Du den ON-String und den OFF-String setzen kannst, INCREASE und DECREASE wird aber über step auf den Zahlenwert umgesetzt.

Das heißt, Du musst die gewünschte Schrittweite mittels step angeben, dann wird aber immer noch kein INCREASE/DECREASE gesendet, sondern der gewünschte Zahlenwert, abhängig vom aktuellen Status.


Gesendet von iPad mit Tapatalk

[Quautiputzli]

Tja, dann muss ich wohl doch bei http bleiben. Schade, dass das damit nicht mehr so funktioniert wie bei openhab 2.

[udo1toni]

Wie erwähnt sollte es auch möglich sein, einen String Channel zu verwenden, über den dann auch INCREASE und DECREASE verwendet werden.
Die Frage ist für mich aber immer noch, wenn Du doch die "andere Seite" selbst kontrollieren kannst (also den Code), dann sollte es kein Problem sein, das anzupassen.

[Quautiputzli]

Ja das mit den String-Channel dachte ich mir auch, aber da kommt nichts an. Ich denke man kann ein Dimmer Item nicht mit einem String-Channel verbinden.

Geht das dann wenn man es mit einem "Profil" verlinkt?

Die andere Seite kann ich natürlich schon kontrollieren, das ist ja nur ein Python Script. Aber mit dem Zahlenwert kann ich eben nichts anfangen. Ich muss ja zwischen heller und dunkler unterscheiden können.

Ich könnte ja über mqtt nur ein- und ausschalten, und dimmen weiterhin über http, das ist aber dann auch Flickwerk.

Edit:
Laut openhab.org lässt sich ein Dimmer Item auch mit dem mqtt-Rollershutter-Channel verlinken. Vielleicht kann ich einen switch-channel zum schalten, und einen Shutter-Channel zum Dimmen benutzen. Das muss ich probieren, wenn ich wieder zuhause bin.

[udo1toni]

openHAB arbeitet mit absoluten Dimmwerten, weil heller und dunkler nun mal sehr ungenaue Angaben sind.
Für das Steuern über Tasten geht das in Ordnung, aber openHAB möchte zuverlässig und wiederholbar identische Zustände herbeiführen.
Ich nutze knx, auf dem Bus arbeiten die Dimmer ebenfalls ausschließlich mit INCREASE/DECREASE (und ON/OFF), ich habe ohnehin nur Taster ohne Anzeige der Helligkeit, openHAB steuert aber mit Prozentwerten, so dass ich dort volle Kontrolle habe.

Der String Channel sollte funktionieren, ich muss das heute Abend mal testen…


Gesendet von iPad mit Tapatalk

[Quautiputzli]

Ich hab nun vorerst nur das meiste auf mqtt umgestellt. Also Rollos, die funktionieren ja eh, und bei den Lichtern geht nun ON/OFF über mqtt. Dimmen hab ich mal auf http gelassen. Somit kann ich zumindest beim Schalten mit Gruppen arbeiten.

[Homer-S]

Hallo,
der Threat ist zwar schon ein paar Tage alt, aber ich stolpere gerade genau über das Problem.

Ich versuch das xte mal den Umstieg auf v3.x.x und scheitere wieder an dem http-binding.
Die Garage wird mit einem Wemos gesteuert auf dem ESPEasy installiert ist.

Das ist mein 2.5 http Item:

Code: Alles auswählen

Switch  GaragenTorOeffnen        "Garagentor [MAP(garage.map):%s]"	      <switchgarage>	(gGA, gGA_Garage)  { http=">[ON:POST:http://192.168.100.208/control?cmd=LongPulse,13,1,2] >[OFF:POST:http://192.168.100.208/control?cmd=LongPulse,14,1,2]" }
Switch  GaragenTorTeiloeffnung  "Garagentor teilöffnen [MAP(garage.map):%s]"	  <switchgarage>	(gGA, gGA_Garage)  { http=">[ON:POST:http://192.168.100.208/control?cmd=LongPulse,15,1,2]" }
Switch  GaragenTorBeleuchtung   "Garagentor Beleuchtung [MAP(garage.map):%s]"  <switchgarage>	(gGA, gGA_Garage)  { http=">[ON:POST:http://192.168.100.208/control?cmd=LongPulse,12,1,2]" }

Das habe ich in OH3 erstellt, analg den ersten Posts hier, aber leider beklomme ich das Garagentor nicht bewegt und wie ich nur eine Zeile als TRACE Eintrag im Log habe bekomm ich auch nicht hin.

Code: Alles auswählen

UID: http:url:192_168_100_208
label: HTTP Garagensteuerung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: http://192.168.100.208
  delay: 0
  refresh: 1
  commandMethod: POST
  contentType: text/html
  timeout: 3000
  bufferSize: 2048
channels:
  - id: garagetoroeffnen
    channelTypeUID: http:switch
    label: http-GarageTorOeffnen
    description: null
    configuration:
      onValue: 13,1,2
      mode: WRITEONLY
      offValue: 14,1,2
      commandExtension: control?cmd=LongPulse,

Darf ich euch @udo1toni und @Quautiputzli um Hilfe bitten?

[udo1toni]

Ja, das Problem wurde ja auch nicht vollständig gelöst...

Inzwischen bin ich aber auch ein Stückchen klüger (hö-hö...) und weiß, dass man in der URL (natürlich...) einen Platzhalter für den zu sendenden wert vorsehen muss.

In Deinem Fall sollte das dann so aussehen:

Code: Alles auswählen

UID: http:url:garage
label: Garagensteuerung
thingTypeUID: http:url
configuration:
  authMode: BASIC
  ignoreSSLErrors: false
  baseURL: http://192.168.100.208/
  delay: 0
  refresh: 1
  commandMethod: POST
  contentType: text/html
  timeout: 3000
  bufferSize: 2048
channels:
  - id: open
    channelTypeUID: http:switch
    label: Tor Oeffnen
    description: null
    configuration:
      onValue: 13
      mode: WRITEONLY
      offValue: 14
      commandExtension: control?cmd=LongPulse,%2$s,1,2
  - id: partial
    channelTypeUID: http:switch
    label: Tor Oeffnen
    description: null
    configuration:
      onValue: 15
      mode: WRITEONLY
      offValue: 14
      commandExtension: control?cmd=LongPulse,%2$s,1,2
  - id: light
    channelTypeUID: http:switch
    label: Tor Oeffnen
    description: null
    configuration:
      onValue: 12
      mode: WRITEONLY
      offValue: 12
      commandExtension: control?cmd=LongPulse,%2$s,1,2

Wie Du siehst steht da statt dem konkreten Wert jeweils ein %2$s, das ist das Command (der Inhalt von onValue bzw. offValue)

Bitte achte auch darauf, dass ich (aus Gründen) die IDs angepasst habe. Ziffern zu Beginn einer ID sind so eine Sache, abgesehen davon hier aber auch keine gute Idee, denn Du könntest - warum auch immer - mal auf die Idee kommen, die IP zu ändern. Dann müsstest Du das Thing komplett weg schmeißen und neu anlegen, denn die ID lässt sich im Nachhinein nicht mehr ändern.
Da die UID hierarchisch aufgebaut ist, gibt es keinen guten Grund, im Label extra auf http hinzuweisen - das ergibt sich immer aus der UID.
Auch eine längliche ID für den Channel ist unnötig, die UID für den Schalter lautet in diesem Fall z.B. http:url:garage:open, das sollte komfortabel ausreichen, um das exakte Ziel des Links auf Anhieb zu erkennen.
Eventuell könnte man auch darüber nachdenken, hier anstatt zweier switch Channel einen number Channel zu verwenden. In der UI kann man dann drei Schaltflächen anlegen, welche die zahlen 13,14, und 15 als Befehl senden (oder gar 4, noch zusätzlich für das Licht).
Gibt es keine Möglichkeit, eine Rückmeldung über den Zustand des Tors und der Leuchte zu bekommen? wäre eigentlich kein Luxus...

Und noch weiter: ESPEasy sollte doch eigentlich auch mqtt unterstützen? Das ist oftmals die einfachere Variante, statt mühsam URLs zusammenzubasteln.

[Homer-S]

Herzlichen Dank für deine Antwort!

Heute Abend werde ich es gleich mal testen.
Das mit den UID und Labels ist noch nicht fertig, ich wollte nur schauen, wo welcher Eintrag landet und das http setze ich wegen der Sortierung oft davor.
Aber, versprech ich dir schau ich mir an.

Ich weiß. meine Steuerung der Garage mit OH ist kompliziert aufgebaut, aber hat bisher funktioniert und ist dem geschuldet, dass ich das hier:

Und noch weiter: ESPEasy sollte doch eigentlich auch mqtt unterstützen? Das ist oftmals die einfachere Variante, statt mühsam URLs zusammenzubasteln.

nicht weiß, wie ich es umsetzen muss.

Bisher steuere ich die 4 Funktionen mittels Switch Items, die http Kommandos senden und mit einer Rule werden die eingehenden (zurückgemeldeten) MQTT Meldungen vom Wemos dann in den Status der Torposition und des Lichts umgesetzt.
Kompliziert, aber mangels fehlendem Wissen doch irgendwie zum Laufen bekommen.

[udo1toni]

meine Steuerung der Garage mit OH ist kompliziert aufgebaut, [...] nicht weiß, wie ich es [mqtt] umsetzen muss.

Bisher steuere ich die 4 Funktionen mittels Switch Items, die http Kommandos senden und mit einer Rule werden die eingehenden (zurückgemeldeten) MQTT Meldungen vom Wemos dann in den Status der Torposition und des Lichts umgesetzt.
Kompliziert, aber mangels fehlendem Wissen doch irgendwie zum Laufen bekommen.

Wenn Du schon Rückmeldungen über mqtt bekommst, sollte das nicht weiter schwer sein.
Du musst lediglich herausfinden, welche Topics Du senden musst. Mutmaßlich wird es sich um ein Topic handeln, über dass Du dann ein JSON Objekt sendest, welches mehr oder weniger dem command entspricht, welches Du momentan mit http schickst. das hier:

Code: Alles auswählen

LongPulse,<zahl>,1,2

sind ja vier Werte, welche alle eine Bedeutung haben. Und genau so ein Kommando musst Du halt per mqtt senden

Aber grundsätzlich: wenn es funktioniert, ist das ja die Hauptsache... Nur manchmal tut man sich unnötig weh nur weil man (noch) nicht weiß, wie es einfacher geht.