Grundlagen Hilfe zum Thema MQTT erbeten.

Barry Ricoh

Active member
Hallo Forum,
habe mal wieder für mich (Neuland) betreten und komme direkt nicht wirklich weiter.
Da ich ein paar Tamota Steckdosen habe musste ich zwangsweise MQTT und Mosquitto Broker installieren.
Die beiden Sachen wurden ja nur "verbunden" und dann läuft das völlig problemlos weil die Tasmota Integration ja den Rest macht.

Jetzt habe ich gedacht wenn ich ja sowieso schon MQTT integriert habe versuche ich mich mal an einer Integration die selbiges erfordert und zwar die
Smartfriends Bridge zur Integration von Schellenberg Rolloantrieben.

Im Prinzip habe ich die Integration installiert und konfiguriert und sie startet auch ohne Fehler im Log.
Jetzt weiß ich aber nicht wie ich die Entitäten der Integration nach HA bekomme.
Es gibt da eine typeTemplate.json Datei, aber ich weiß absolut nicht was ich damit anfangen soll.

Ist jemand bereit hier Anfänger Hilfe zu leisten?
 
Zuletzt bearbeitet:

Barry Ricoh

Active member
Also in einem anderen Log war doch ein Fehler zu finden und nachdem ich jetzt ein fehlendes Komma "eingebaut" habe bin ich ein Stück weiter.
Ich habe jetzt zumindest 2 Cover Entitäten in HA, aber die "funktionieren" nicht.
Ich habe immer noch nicht kapiert was ich mit der "typeTemplate.json" Datei anfangen soll?
Egal ob ich die original lasse oder bearbeite da ändert sich nichts (für mich sichtbares)
 

blurrrr

Well-known member
Hi :)

Also wenn Du von https://github.com/gimparm/smartfriends-bridge sprichst, dort steht zum Thema Templates:
TypeTemplates are optional but for proper control of most devices it is probably required.
+
For very basic devices like a Zigbee switch or Zigbee door/window sensor that only needs to read the state information and/or send a single sub device command no template is needed.

Ein entsprechendes Beispiel wurde für die Schellenberg-Geschichte auch aufgeführt:
https://github.com/gimparm/smartfriends-bridge#schellenberg-rolladen-1

Weiter oben ist allerdings noch folgender Hinweis:
You must have the .Net 5.0 Runtime installed to use this or you must run as the docker/hassio-addon.
Sind diese Voraussetzungen denn erfüllt?

https://github.com/airthusiast/hassio-addons gäbe es halt auch noch, aber wie Du vllt weisst, bin ich in Sachen HA nicht sonderlich bewandert... 😅
 

Barry Ricoh

Active member
Hi, danke dir.
Da ich HA auf dem Raspi einsetze ist Net unwichtig.
Ja ich habe das alles gelesen (mehrfach) aber ich kapiere es nicht wirklich.
Bin aber schon ein Stück weiter, zumindest funktioniert das Rollo jetzt.
Kämpfe jetzt noch mit dem 0% und 100% Mist.
Da mein Rollo keine Rückmeldung hat habe ich die Erweiterung "cover_rf_time_based" installiert.
Da kann ich zwar mit einem Parameter die Optik anpassen, aber die Anzeige 0% ist "zu" bleibt bestehen.
Das ist aber grundlegend falsch.
 

blurrrr

Well-known member
Naja, da gab es hier ja schon ein paar Threads zu... Im Prinzip ist es grob gesagt darauf hinausgelaufen, dass man es einfach anhand der "Zeit" festgemacht hat... Rollo braucht z.B. 10 Sekunden von "auf" zu "zu", gibst Du nun die Anweisung, dass das Rollo 5 Sekunden lang herunterfahren soll, ist es vermutlich zu 50% geöffnet/geschlossen. Sowas könnte man dann (vermutlich?) in einen Helper schreiben und diesen dann anzeigen lassen bzgl. der %. Ist aber auch nur so eine grobe Idee und ich hab nach wie vor keine Ahnung 😂
 

Barry Ricoh

Active member
Ja das ist alles klar, aber das Fabrikat verhält sich da wohl genau anders rum als andere, deshalb "rechnet" die Integration "falsch".
Ich weiß das es nicht wirklich wichtig ist, aber stört mich halt.
Normal ist Rollo 0% = Offen und 100% = Zu. Die Karte zeigt mir das aber genau anders rum an.

Ich doktor mal weiter.
 

Barry Ricoh

Active member
So habe in der Datei "travelcalculator.py" die Berechnung angepasst.
Jetzt Stimmt Status und optische sowie prozentuale Anzeige der "custom shutter card" überein.
Auch funktionieren alle Buttons "Up" / "Down" / "Stop" richtig.
Nur wenn ich manuell mit der Maus das Rollo hoch oder runter ziehe kommt die Sache durch einander.
Zwar wird die Shutter Animation ausgelöst, aber das Rollo fährt nicht wirklich wenn es in einer Endlage (0 oder 100%) ist.
Wenn es in einer Zwischenposition ist wird die falsche Richtung angesteuert.
Weiß jetzt nur nicht ob der "Fehler" jetzt in bei der Karte liegt oder bei der Berechnung der Integration.
Wie kann ich das denn rauskriegen?
 

alexamend

Active member
Dieses Verhalten wird in HA schon lange diskutiert,... ein template schafft hier Abhilfe.

Damit wir aus
Offen = 100% / Geschlossen = 0%
Inverterzu
Offen = 0% / Geschlossen = 100%

YAML:
template:
  - platform: cover
    covers:
      tapparella_sala_invertita:
        friendly_name: "Tapparella Sala (Inverse)"
        position_template: >
          {{100 - (state_attr('cover.rolling_shutter_switch_1_2','current_position')|int)}}
        set_cover_position:
          service: cover.set_cover_position
          data_template:
            entity_id: cover.rolling_shutter_switch_1_2
            position: >
              {{100 - position}}
      tapparella_cucina_invertita:
        friendly_name: "Tapparella Cucina (Inverse)"
        position_template: >
          {{100 - (state_attr('cover.rolling_shutter_switch_2_2','current_position')|int)}}
        set_cover_position:
          service: cover.set_cover_position
          data_template:
            entity_id: cover.rolling_shutter_switch_2_2
            position: >
              {{100 - position}}
 

Barry Ricoh

Active member
Soweit man einen Positionssensor hat bin ich da bei dir, aber das nutzt mir hier nichts da ich ja nicht wirklich eine Position in einer Entität, bzw. einem Attribut habe, sondern die Position innerhalb der der Phyton Datei aufgrund der Zeit nur berechnet wird, musste ich letztendlich in der "cover.py" der Timebased Integration" nur noch die Richtung bei relativem Verfahren tauschen. Ist die relative Pos. negativ muss eben hoch gefahren werden, und sonst runter.
Also einmal größer (>) mit kleiner (<) getauscht und umgekehrt hat dann die Lösung gebracht.
Auf jeden Fall funktioniert nun alles wie gewollt.
Status, Optik der Karte, Button, Anzeige der Prozente und Maus ziehen passt alles zusammen.
 

alexamend

Active member
Wenn es per MQTT eingebunden ist, sollten auch dort entsprechende entity vorhanden sein.

Vom Prinzip her ist das nichts anderes als mein Roto Dachfenster Rollo den ich auch nur über Zeit auf die gewünschte Position fahren kann, da dieser kein Feedback system hat.

Ich habe mir einen Helper erstellt mit dem ich die Zeit für das zu fahren bestimme, 0 sec. = 0% und 20 sec. = 100% Geschlossen,
Damit befüllen ich eine Variable

Jetzt gibt es in der Ansicht
1. AUF = 0%
2. ZU = 100%
3. STOP
4. AUF POSITION ( mit Schieberegler )

Bei auf Positon wird die Variable genutzt,
da der Rollo auch manuell (über Funk Taster) gestreut werden kann, ist mir die Position nie bekannt und ich muss eine Referenz anfahren.

Wird auf Position fahren angewandt
Ablauf:
Rollo öffnen,
da ich nicht weiß auf welcher Position er gerade ist 21 sec. warten um sicher zu sein das er jetzt offen ist,
dann wirt zu fahren auf Zeit gestartet z.B. 10sec. = 50%
danach Stop.

Das ganze nutzt ich auch im Sommer wenn es im Zimmer zu warm wird.
 

Barry Ricoh

Active member
Guten Morgen, vielen Dank für deine Beschreibung.
ich meinte aber eher wie so ein Script was in yaml aussieht.
Da muss ja mit payload und MQTT Publish gearbeitet werden.
Ich habe ja nur eine Entität, das Cover.


Ja und wieder einen Gedankenfehler.
Ich muss ja nicht ja MQTT Cover per Script ansprechen, dann geht ja wieder die Position verloren, sondern das "cover_rf_time_based"
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
1.725
Beiträge
21.438
Mitglieder
1.234
Neuestes Mitglied
Doneinei
Oben