Puh…, hat wieder sehr viel Zeit und Arbeit beansprucht bis ich das umgesetzt bekommen habe, aber es funktioniert.
Vielen Dank!
@Mathias, eventuell funktioniert das bei Dir unter ZHA auch?
Ja, evtl
Aber ich versteh nur Bahnhof 
Ich bin da von der Fraktion faule Sau.
Ich hab die Dinger an Homey angemeldet und jag sie per MQTT zu HA. Keine Probleme und alle Entientäten sind da.
Sorry, jetzt erst gesehen.
Ich hätte das genauso mit der Neuinstallation vom Broker gemacht.
1 Like
Mathias hat doch alle Zigbee Geräte von Homey zu HA umgezogen. Deshalb ist es eigentlich keine Option, den Sensor mit Homey zu verbinden (fehlende Verbindung, kein Mesh)
@Mathias, wir können morgen mal versuchen das gemeinsam hinzubekommen, ok? So von HA Anfänger zu HA Anfänger. 
@Mathias, ich versuche mal die notwendigen Schritte zu erklären.
Ich gehe jetzt erstmal davon aus, dass Du Zugriff auf das HA config Verzeichnis hast. Sollte das nicht der Fall sein, bitte melden.
In dem config Verzeichnis musst Du eine Datei namens template.yaml erstellen, falls noch nicht vorhanden.
In diese Datei bitte folgenden Code kopieren…
# Aqara Vibration Sensor
- sensor:
- name: Aqara Vibrationssensor
state: |
{{ state_attr('binary_sensor.aqara_vibrationssensor', 'orientation')[0]}}
unique_id: aquara_vibration_1_x
- name: Vibration Y
state: |
{{ state_attr('binary_sensor.aqara_vibrationssensor', 'orientation')[1]}}
unique_id: aquara_vibration_1_y
- name: Vibration Z
state: |
{{ state_attr('binary_sensor.aqara_vibrationssensor', 'orientation')[2]}}
unique_id: aquara_vibration_1_z
- name: Vibration Tiltangle
state: |
{{ state_attr('binary_sensor.aqara_vibrationssensor', 'tiltangle')}}
unique_id: aquara_vibration_1_tiltangle
- name: Vibration Vibrarion
state: |
{{ state_attr('binary_sensor.aqara_vibrationssensor', 'vibrationstrength')}}
unique_id: aquara_vibration_1_vibrationstrength
…und folgende Anpassungen durchführen:
name: Aqara Vibrationssensor durch den von Dir verwendeten Namen für den Aqara Vibration Sensor ersetzen
'binary_sensor.aqara_vibrationssensor' durch den Entitätsnamen Deines Aqara Vibration Sensors ersetzen:
Anschließend die template.yaml Datei speichern.
Jetzt muss noch in die configuration.yaml Datei folgender Eintrag vorgenommen werden:
template: !include template.yaml
Speichern
Bei den Codes in den YAML-Dateien ist es u.A. wichtig, dass die Anzahl der Leerstellen stimmen. Eine generelle Überprüfung der YAML-Konfiguration kann man hier vornehmen:
Sollte dort ein Fehler gemeldet werden, hat sich irgendwo ein Fehler eingeschlichen.
Wenn alle OK ist, in diesem Fenster auf NEU STARTEN klicken (bin mir grade nicht sicher, ob das wirklich gemacht werden muss… 
).
Nachdem HA wieder bereit ist, kann man das Verhalten, also die Änderungen der Werte wenn der Sensor bewegt wird, im Dashboard u.A. mit der Entitäten-Karte sichtbar machen:
– Bei Entität die binary_sensor.Entität auswählen
– Bei Attribute das entsprechende Attribut auswählen
Temperatur und Batterie können als Elemente-Karten hinzugefügt werden, da diese separate Entitäten zur Verfügung stellen.
Jetzt zu den Automatisierungen (was ich selber noch nicht gemacht habe).
@Osorkon hatte in seinem Post aber ja bereits ein Beispiel aufgezeigt:
Am einfachsten ist es meiner Meinung nach die Automatisierung im Editor zu erstellen. Dabei muss als Auslöser { } Template ausgewählt werden. In die Zeile braucht man dann nur noch diese Zeile einfügen:
{{ state_attr('binary_sensor.aqara_vibrationssensor', 'orientation')[0] > 4 }}
Eine weitere Möglichkeit ist es die Automatisierung direkt auf YAML-Code umzustellen und den o.g. Code einzufügen…
description: ""
mode: single
trigger:
- platform: template
value_template: "{{ state_attr('binary_sensor.aqara_vibrationssensor', 'orientation')[0] > 4 }} "
condition: []
action: []
…und anschließend eventuell wieder auf die Editorbearbeitung umschalten.
Bei beiden Varianten muss wieder darauf geachtet werden, dass der Name der Entität korrekt ist.
binary_sensor.aqara_vibrationssensor also bitte durch den Namen Deiner Entität ersetzen.
Natürlich müsste je nach Anwendungsfall auch orientation durch tiltangle oder vibrationstrength ersetzt werden. Dementsprechend muss der Wert, ab wann getriggert werden soll, auch angepasst werden.
Ich hoffe, dass das einigermaßen verständlich ist und ich keine Fehler eingebaut habe.
Wenn Du Dir schon die Mühe gemacht hast, und für jedes einzelne Attribute ein Template Sensor angelegt hast. Kannst Du bei den Automatisierungen direkt die Template Sensoren als Triggeer und oder Bedingungen nutzen.
trigger:
- platform: numeric_state
entity_id: sensor.aqara_vibrationssensor
above: 4
Verstehe ich nicht, sorry… 
Hast Du doch auch gemacht. Gibt’s eine andere, einfachere Lösung? Habe ich was falsch gemacht?
Fehlt da nicht das Attribut? above: 4 könnte jetzt doch Vibrationstrength, Tiltangle etc. sein, oder?
Wenn man im Editor anstelle sensor.aqara_vibrationssensor die Entität binary_sensor.aqara_vibrationssensor nutzt, dann kann man auch das notwendige Attribut auswählen und die Grenzwerte festlegen:
@Mathias, das wäre dann ein möglicher Weg eine Automatisation ohne YAML-Code zu erstellen.
In YAML sähe der Auslöser dann z.B. so aus:
platform: numeric_state
entity_id: binary_sensor.aqara_vibrationssensor
attribute: tiltangle
above: 170
Verstehe ich es richtig dass der skyconnect Stick dann bspw. den Conbee ersetzt und der Tausch der Hardware von Conbee auf skyconnect problemlos möglich sein wird?
Welche Vorteile hat der skyconnect ggü. Conbee, abgesehen davon dass dieser zukünftig auch matter unterstützen soll?
Ja, er ersetzt den Conbee 2. Ob der Wechsel problemlos möglich ist, glaube ich nicht. Zumindest musst du deine ganzen Zigbees neu anlernen und deine Automatitionen korrigieren.
Vermutlich keine, ausser das er Thread und Matter kann.
Der kann Zigbee und Thread. Wenn du den deconz Stick mit der HA Zigbee Integration ZHA nutzt, könnte das evtl. mit der Übernahme der Geräte gehen. Ganz sicher bin ich mir aber nicht.
Wenn du allerdings Phoscon nutzt, dann wirst du alle Geräte umziehen müssen.
Ich hab mir den Stick mal vorbestellt um die Thread Unterstützung zu haben.
Ich bleibe beim Zigbee Stand jetzt bei der deconz Integration, die läuft bei mir am besten.
Jetzt komme ich mal wieder mit einer doofen Frage… habe es endlich geschaftt bei HA die Lüftungseinheit des Hauses wieder einzubinden. Habe ich dann exportiert zu Homey… Da wird dann zum Beispiel die Raumabluft Temperatur angezeigt. Allerdings steht da nicht Grad Celsius sondern “value”… wie kriege ich das denn geändert??
Bisschen mehr Details bitte
Wie exportierst du nach Homey?
- HA App (Athom)
- HA App (Community)
- MQTT Hub
- MQTT Client
???
Uns ein Screenshot wäre gut. Ich weiß z.B. nicht, was du mit “value” meinst. Dann bekommst du sicher auch hilfreiches Feedback 
Mann…ich bin doch Noob :-)… Also HA App Community…Mqtt Client und Broker habe ich auch installiert aber wohl irrelevant.
So sieht das dann aus…
Aussentemperatur sollten ja Celsiussein oder bei Fan Speed rpm, bei Filter Tage …
Gute Frage. Kann ich mir mal anschauen. Bin sowieso gerade beim Upgrade der App. Vermutlich werden bei der Übernahme der Entitäten die Capabilitäts-Parameter nicht komplett übernommen.
Ich denke, der Entity-Name wird als Gerätename übernommen. Die Entity hat ja nur einen Wert. Deshalb vermutlich “value” als Capability-Name. Die Einheit kann ich prüfen. Aber bei “value” hätte ich spontan auch keine Idee, was man sonst nehmen könnte.
Hi,
wenn in HA typisierte Entitäten, verwendet werden, dann wird der korrekte Wert verwendet.
Wie ist denn die Entity in HA definiert? Wird es dort als Temperatur angezeigt oder als reiner Zahlenwert?
Bei Werten, die auch in HA ohne Einheit definiert sind, erfolgt die Anzeige in Homey ohne Einheit:
vielleicht ist das aber auch ein untypisierter Wert (also nur numerisch) mit Einheit. Ich werde das noch ergänzen, dass wenn keine Homey-Capability verwendet wird (wie measure_temperature), die Einheit von HA übernommen wird.
1 Like
Hallo Ronny…da wird bei der Temperatur Grad Celsius angezeigt…bei der Geschwindigkeit rpm und bei dem Filter Tage.
Dann hat die Entität zwar eine Einheit, aber keinen Typ. Hier ist ein Beispiel für eine Variante mit korrektem Typ, der dann in der App auf die Homey-Capability measure_temperature gemappt wird:
Dazu in den Entwicklerwerkzeugen die Details aufrufen:
Wenn Geräte keinen Typ besitzen, dann wird versucht, über die Einheit den Typ zu bestimmen. Da habe ich nun “°C”, “mbar” und “lx” ergänzt, so dass diese Elemente den korrekten Homey-Typ bekommen sollten.
Ansonsten sollte in Zukunft zumindest bei numerischen Werten die HA-Einheit in das Homey-Gerät übernommen werden.
Komplett sicherstellen kann ich das allerdings nicht. HA hat als Typ nur “state_class: measurement”. Das kann numerisch oder alphanumerisch sein. Ich habe in meinem HA daher Entitäten, die gemischt gefüllt werden. Z.B. ein Luftgütesensor kann NO-Werte numerisch liefern incl. Einheit. Wenn das Gerät ausgeschaltet ist, ist der Wert allerdings “off”. Wenn der Sensor in diesem Zustand in Homey eingebunden wird, dann wird aufgrund des Wertes “off” eine alphanumerische Capability eingefügt. Zwar auch mit Einheit, allerdings zeigt Homey die Einheit dann nicht an. Es kommt beim Einfügen in Homey also auch auf den alktuellen Wert an (numerisch/alphanumerisch).
Soviel zur Theorie. Das ganze muss sich dann beweisen, wenn die App im HCS online ist.
Hier noch ein Beispiel für eine “exotische” numerische Entität mit Einheit:
