Z-Uno Binary Sensor wird vom Homee als Bewegungsmelder erkannt, bei euch auch?

Hallo Community,

ich bin noch nicht lange beim Homee, habe im Nov. 2017 angefangen, um meine Weihnachtsbeleuchtung zu steuern.

Jetzt habe ich mich mal am Z-UNO ausprobiert.
Meine Umgebung:
Hom.ee Version 2.17.1
Arduino IDE 1.8.5.
Z-UNO Firmware 2.11.

Mein Problem ist, dass der Homee jeden Binary-Sensor (egal welche Klasse ich im Script verwendet), als Bewegungsmelder einbindet.

Meine Frage an alle die den Z-UNO im Einsatz haben, ob dies bei euch der Fall ist.
Hat es mit früheren Hom.ee Firmware-Versionen mal funktioniert, oder liegt es auf der Z-UNO?

Danke für eure Hilfe.
Gruß Ralf

PS hier ein einfaches Beispiel für ein Z-UNO Skript:

// variable to store current button state
byte lastButtonState;

// next macro sets up the Z-Uno channels
// in this example we set up 1 sensor binary channel
// you can read more on http://z-uno.z-wave.me/Reference/ZUNO_SENSOR_BINARY/
ZUNO_SETUP_CHANNELS(ZUNO_SENSOR_BINARY(ZUNO_SENSOR_BINARY_TYPE_GENERAL_PURPOSE, getter));

void setup() {
pinMode(LED_PIN, OUTPUT); // set LED pin as output
pinMode(BTN_PIN, INPUT_PULLUP); // set button pin as input
}

void loop() {
// sample current button state
byte currenButtonState = digitalRead(BTN_PIN);

if (currenButtonState != lastButtonState) { // if state changes
lastButtonState = currenButtonState; // save new state
zunoSendReport(ZUNO_CHANNEL_NUMBER_ONE); // send report over the Z-Wave to the controller
if (currenButtonState == LOW) { // if button is pressed
digitalWrite(LED_PIN, HIGH); // shine the LED
} else { // if button is released
digitalWrite(LED_PIN, LOW); // turn the LED off
}
}
}

// function, which returns the previously saved button state
// this function runs only once the controller asks
byte getter(){
if (lastButtonState == 0) { // if button is pressed
return 0xff; // return “Triggered” state to the controller
} else { // if button is released
return 0; // return “Idle” state to the controller
}
}

Binary Sensoren werden nicht nativ unterstützt.
Aber ja sie werden aus Bewegungsmelder erkannt und dann kann man sie so verwenden

Hast du diesen Eintrag durchgelesen?

Dort schreibt @Tobias, dass es geht.

Unter 10 Channels Certified Sketch gibt es einen Beispiel-Sketch, der laufen soll.

1 „Gefällt mir“

Selbstverständlich habe ich die Beiträge durchgelesen. Seit dem sind aber seitens Homee viele neue Softwareaktualisierungen ausgeliefert worden, die ja einen Schwerpunkt auf dem Z-Wave Protokoll hatten.
Meine Frage richtete sich ja an Z-UNO Anwender, ob diese eine Veränderung im Verhalten festgestellt haben oder ob sie den gleichen Effekt wie ich festgestellt haben.

Ich werde mit dem 10-Chanel Beispiel weiterprobieren und meine Erkenntnisse mitteilen.

Gruß Ralf

Ich glaube nicht, dass es hier viele Z-UNO-User gibt, da die Teile doch recht hochpreisig sind im Verhältnis zu purer Arduino-Hardware.

Freue mich auf eine Rückmeldung, falls ich mir doch mal eigene Z-Wave-Hardware bauen will.

Hochpreisig findet ich den gerade nicht, kosten 50 €, jeder andere Z-Wave Sensor/Aktor kostet ähnlich.
Und dafür bietet der Z-UNO eine unschlagbare Flexibilität.

Mein Projekt war, meine beiden Hörmann Garagentore zu steuern. Der Z-UNO implementiert dabei die zwei Taster, mit denen die Tore hoch und runter gefahren werden, und die zwei Sensoren über einfache Reed-Kontakte, um zu erkennen, ob das Tor offen oder zu ist.

Wäre alles so einfach, wenn der Hom.ee nicht immer einen Bewegungsmelder zuätzlich zum Fenstersensor erkennen würde.
Wenn ich das hier angesprochene 10-Chanel Beispiel (da müsste eigentlich jeden Homee-Fan das Herz höher schlagen, 10 Sensoren mir einem kleinen Baustein!!) abspecke und nur den Schalter und den Fenstersensor drin lasse:
ZUNO_SETUP_CHANNELS(
ZUNO_SWITCH_BINARY(getterSwitch1, setterSwitch1),
ZUNO_SENSOR_BINARY_DOOR_WINDOW(getterDoor)
);
sieht es beim Homee wie im Screenshot aus. Und jedes Mal wenn der Fensterkontakt auslöst, wird Bewegungsalarm ausgelöst.

Da ich in anderen Foren zum Z-UNO keinerlei Berichte dazu gelesen habe, war meine Vermutung, es liegt am Hom.ee.

Ich weiß es ist kein unterstütztes Gerät, aber wenn ich hier ein bisschen Werbung mache, wie toll das Teil ist, kommt es vielleicht mal rein.

Ich eventuell sieht es ein Entwickler von Hom.ee und kann mir noch einen Tipp geben.


1 „Gefällt mir“

@Tobias – ich denke mal Dein Bastlerherz hat den Z–Uno schon auf dem Schirm, sobald Du mit der Implementierung des neuen Z–Wave–Stacks durch bist, oder?

Edit: Hier gab es mal Aussagen von Tobias:

1 „Gefällt mir“

@hblaschka
Den Link hatte ich @Rkluch schon mit auf den Weg gegeben.

@Rkluch
Klar kostet ein Z-Wave-Komplett-Aktor/Sensor auch seinen Preis, aber da ist schon alles “Am Stück”. Beim Z-UNO für 50-60€ werden halt noch Teile benötigt, um einen/mehrere Sensoren zu bekommen und Relais um 240V zu schalten ist auch eine Sache, die Vorsicht benötigt.

Wenn es aber so ist, dass der Bewegungsalarm (Das ist definitv eine homee-Sache - Komischerweise erscheint der bei vielen nicht direkt unterstützten Z-Wave-Geräten - Bei mir beim Co-Melder und bei den Wassermeldern) nur mit erscheint und die sonstiges Stati korrekt angezeigt werden, dann komme ich doch schon wieder in Versuchung mir ein Z-Wave <-> 433MHz-Gateway zu basteln. Ich habe das bisher provisorisch über einen Arduino, 433MHz Sender und Webhooks realisiert, aber das überzeugt mich nicht so ganz, da ich massig HGs für jede Steckdose bauen muss: Ein, Aus, Status-HG. So könnte ich direkt über HGs schalten.

Wenn es auch bei anderen Geräten dazu kommt, das ein Bewegungsmelder mit zusätzlich auftaucht, dann scheint es ja ein Hom.ee Bug zu sein …

Damit könnte man schnell den ganzen „nicht direkt“ unterstützten Geräten eine Unterstützung zukommen lassen. Community macht, @homee prüft und schon ist ein Gerät im nächsten Update drin.

Von neuen, komplett unterstützten Geräten war in den letzten Updates nicht viel zu sehen…

1 „Gefällt mir“

Hi,

Mein Problem ist, dass der Homee jeden Binary-Sensor (egal welche Klasse ich im Script verwendet), als Bewegungsmelder einbindet.

homee / OpenZwave kann nur Sensor Binary Version 1, die verschiedenen Klassen sind erst mit Version 2 dazu gekommen. Allerdings ist die Sensor Binary Command Class nun auch schon eine ganze Weile DEPRECATED, bin daher nicht sicher ob es noch Sinn macht die CC auf Version 2 zu ziehen. Für neue Geräte sollte daher eher die Alarm/Notification CC verwendet werden. Weißt du, ob da von Zuno was geplant ist?

homee verwendet als standard Attribute für Sensor Binary einen Bewegungsmelder, da viele Geräte aus der Zeit den Sensor Binary eben auch Bewegungsmelder waren.

ZUNO_SETUP_CHANNELS(
ZUNO_SWITCH_BINARY(getterSwitch1, setterSwitch1),
ZUNO_SENSOR_BINARY_DOOR_WINDOW(getterDoor)
);

Das erzeugt bei dir 1 Schalter, 1 Bewegungsalarm und 1 Fensterzustand? Das wundert mich dann doch ein bisschen :confused:

Ja genau so wie im Screenshot zu sehen…

Hab mal ein wenig im Z-Uno Core Code gestöbert und deinen Sketch Zuhause nachgestellt (es fehlen in deinem Beispiel übrigens ein paar #defines).
Dabei ist mir aufgefallen, dass der Z-Uno sowohl die Sensor Binary als auch die Alarm/Notification Command Class ausgibt. Dann ist mir auch klar, woher die 3 Attribute kommen.
Switch_Binary -> Schalter :white_check_mark:
Sensor_Binary -> Bewegungsmelder :white_check_mark: :question:
Alarm Event Door/Window -> Zustand :white_check_mark:

Die entsprechenden Stellen im Zuno Core wären wohl diese hier:

Das ist also von Z-Uno so beabsichtigt.

Wäre nun die Frage was homee in dem Fall unternehmen soll.

Eine Möglichkeit wäre den Sensor Binary einfach zu ignorieren und kein Attribute dafür anzulegen, da der Status ja auch über die Notification CC gesendet wird.

Eine weitere Möglichkeit wäre wohl auch, die Sensor Binary V2 CC in OpenZwave einzubauen, denn homee kann verschiedene Command Classes auf das gleiche Attribute mappen, allerdings müssen diese zusammen passen ( Sensor Binary -> Bewegeungsmelder und Alarm Event Bewegung sollten nur 1 Bewegungsattribute erzeugen). Freiwillige vor? :slight_smile:

Gruß

Tobias

Ich mische mich mal aus Interesse mit ein.

Ja, bei ZUNO_SENSOR_BINARY() wird die Notification mit eingebaut:

https://z-uno.z-wave.me/Reference/ZUNO_SENSOR_BINARY/

Channel generated using this macro will have Z-Wave Device Class GENERIC_TYPE_SENSOR_NOTIFICATION / SPECIFIC_TYPE_NOTIFICATION_SENSOR with Notification and Sensor Binary (for legacy suport) Command Classes.

Ich denke, @Rkluch hat das Beispiel-Sketch von 10 Channels Certified Sketch als letztes Beispiel mit den Screenshots verwendet und dort alles rausgenommen ausser:

ZUNO_SWITCH_BINARY(getterSwitch1, setterSwitch1),
ZUNO_SENSOR_BINARY_DOOR_WINDOW(getterDoor)

Hier nutzt er aber ZUNO_SWITСH_BINARY()

https://z-uno.z-wave.me/Reference/ZUNO_SWITCH_BINARY/

Hier finde ich in den defines nichts von ZUNO_NOTIFICATION_TURNED_ON, nur getter und setter. Das sollte einen Bewegungs-Alarm von Seiten Z-UNO nicht erklären.