Neues Spielzeug Z-Uno

[Ralf.E]

Hi Andreas,

Hi,Anzahl der Assoziationsgruppen hat aber nichts mit der Anzahl der Kanäle zu tun. Der Z-Uno wird nur eine Gruppe bereitstellen, die Diskussion dazu gab es im Forum schon mal, mehrere Gruppen sind "zu kompliziert"... Dazu müsste dann ja der Report-Befehl auchgeändert werden und die Sorge der Entwickler ist das sie nicht so viele Abfragen einbauen können das verhindert werden kann das der Nutzer damit dann etwas "baut" was nicht mehr ZWave konform ist.

Ich habe es noch nicht ausprobiert, aber mit der mca müsste es auch möglich sein einen Channel an mehrere Empfänger zu senden wenn man z.B.
mcaAdd 1 0 1 1 2 1 eingibt sollte der Endpunkt 1 eigentlich mit Node 1 und mit Node 2 assoziiert sein.

ich bin zwar noch nicht weitergekommen (FTUI kam dazwischen), aber beschreibt https://github.com/OpenZWave/open-zwave/issues/960 vielleicht was wir hier mit der Multi-Channel-Association sehen?

Gruß Ralf

[A.Harrenberg]

Hi,

ja, PoltoS ist einer der Developer von Z-Uno...

Den Thread kannte ich, hatte ihn aber anscheinend erfolgreich verdrängt. Er spricht ja explizit davon das man das NUR über die child-ID 0 einschalten soll/darf.

Gruß,
Andreas.

[krikan]

Spannende Feststellung  :
Demnach muss FHEM während der Inklusion von Geräten mit MCA Version 3 nicht mehr die Association über associationAdd, sondern mit mcaAdd setzen. Das würde auch zum kürzlichen "Problemkind" FGS223 passen.

[A.Harrenberg]

Hi Christian,

ja, und erschwerend kommt hinzu das man weder eine normale Assoziation noch eine explizite Zuweisung für jeden Endpoint per mca machen soll, sondern quasi NUR generisch mit mcaAdd 1 0 1 0 über eine "0" als Child-ID das generell einschaltet.

Die Doku zu MCA ist leider so schwer zu verstehen da es da von "should" nur so wimmelt und man das ganze auch als groben Vorschlag verstehen kann...
Meine beiden Z-UNO sind momentan allerdings belegt und stehen nicht als Testobjekt zur Verfügung, wobei ich meine freie Zeit momentan auch lieber in die Probleme mit dem secStack stecke.

Ich kann mich aber daran erinnern das ich bei den normalen Versuchen auch immer mehrfache Nachrichten an Root-Device und Childs erzeugt habe und das dann erst mit dem mcaAdd 1 0 1 0 richtig funktioniert hat so wie man sich das denkt (außer das Root eine Kopie von Child 1 wird, das ist nicht immer einfach zu verstehen...)

Gruß,
Andreas.

[buspirat]

Habe mir jetzt auch dieses Spielzeug bestellt. So ein A. Harrenberg macht ganz schön Bambule im Forum des Herstellers
Auf lange Sicht will ich über den Z-Uno meine Gira Funkrauchmelder an Z-Wave anbinden, möglichst mit Security und später (sobald verfügbar) sogar mit S2 Security.

Die Z-Uno Erfinder haben es drauf: Allein die Idee den "clang" Compiler als C++ Frontend für den eingeschänkten SDCC C Compiler zu verwenden ist richtig gut. Oder die Speicherbereiche IRAM und XRAM des 8051 Prozessors strikt zwischen der Z-Wave Welt und dem Benutzercode zu trennen, um das Sigma Designs NDA einzuhalten.

Das Interface zwischen dem Z-Wave Stack und dem Benutzercode erfolgt ja über die von Z-Wave.me erdachten "Syscalls". Wenn man dort natürlich einen Pufferüberlauf oder ähnliches finden würde, dann könnte man versuchen den Z-Wave Protokollstack-Binärcode rauszudumpen...

"Making of" Doku des Z-Uno auf Russisch mit Hilfe von google translate:
https://translate.google.ru/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fhabrahabr.ru%2Fpost%2F313898%2F

[A.Harrenberg]

Hi,

Habe mir jetzt auch dieses Spielzeug bestellt. So ein A. Harrenberg macht ganz schön Bambule im Forum des Herstellers
Auf lange Sicht will ich über den Z-Uno meine Gira Funkrauchmelder an Z-Wave anbinden, möglichst mit Security und später (sobald verfügbar) sogar mit S2 Security.

also S2 wird 'ne ganze Weile dauern...
Das ist alles recht komplex und ich bin auch nicht gerade Fachmann für Kryptographie...
Vorteil von S2 ist ja (soweit ich das vertehe) vor allem das nicht für jede Transaktion eine neue NONCE benötigt wird und damit der Ablauf wieder "schlanker" wird. WIE das allerdings im Detail realisiert wird habe ich noch genauer nachgelesen.
Was für ein Protokoll "sprechen" denn die Gira Funkmelder?

Wenn man dort natürlich einen Pufferüberlauf oder ähnliches finden würde, dann könnte man versuchen den Z-Wave Protokollstack-Binärcode rauszudumpen...

Na ja, ob man damit glücklich wird... Dann kann Du genausogut auch ein Firmwareupdate-file analysieren, da steht nicht viel anderes drin. Die Hersteller werden sich bei den Systemsachen sicher an die Library von Sigma halten.

Viel Spaß damit, ich habe mir jetzt den dritten geholt da meine beiden anderen "belegt" sind. Den einen habe ich testweise als 9-Kanal Sensor/Aktor in Betrieb, inklusive OLED. Am zweiten hängt so ein billiger RFID-Leser, die Library dazu sprengt aber den Stack von dem Z-Uno und muss wahrscheinlich vollständig neu geschrieben werden.
Den neuen wollte ich u.a. als Testobjekt für den Umbau des Security SendStacks nutzen.

Gruß,
Andreas.

[buspirat]

Das ist alles recht komplex und ich bin auch nicht gerade Fachmann für Kryptographie...

es gibt da ein sehr gutes Krypto-Buch:
"Niels Ferguson, Bruce Schneier, Tadayoshi Kohno - Cryptography Engineering"
(https://www.amazon.de/Cryptography-Engineering-Principles-Practical-Applications/dp/0470474246)
Das beleuchtet die Sache verständlich mathematisch und mit praktischen Angriffsszenarien auf Block Ciphers, Hash Funktionen usw. Es hat mich für ein Projekt auf der Arbeit definitiv weiter gebracht, so das der externe Krypto-Reviewer nur noch Peanuts gefunden hat

Was für ein Protokoll "sprechen" denn die Gira Funkmelder?

Leider ein prorietäres Protokoll. Es wird direkt in Hardware von einem "Radiocrafts RC1540" Chip erledigt, der setzt RS232 Kommunikation in Funk um und kann auch Mesh-Networking. Gira hat sich da eine custom-Version des Chips auflegen lassen, zumindest gibt es den Chip nicht beim Hersteller auf der Homepage.

Für die Vorgängermodelle gibt es die "gira-utils" und ich war der Hoffnung, daß das Protokoll nicht stark verändert wurde. Ich werde mir das nochmal gut überlegen, ob ich mir das mit dem Reverse Engineering wirklich antue, oder ob es z.B. Z-Wave Rauchmelder von POPP werden. Das sind im Endeffekt die Testsieger aus der Stiftung Warentest + Funkmodul von zwave.me. Kann man schon auf der "products.zwavealliance.org" Seite nachsehen, die gleichen Rauchmelder wurden einige Monate vorher von zwave.me zur Zertifizierung abgegeben. Fertige Z-Wave Rauchmelder sind definitiv billiger als meine Zeit für das reverse Engineering...

Zurück zum Thema: Die LED des ZUNO kann ich jetzt auch per Funk steuern 

Hoffe die Firmware-Version 2.08 kommt bald. Ich wette darauf, daß nichtmaskierte Interrupts die I2C Kommunikation, ADC Auswertung usw. gestörte hatten. Das Problem gibt's auch bei normaler Arduino-Programmierung mit dem ADC.

Viele Grüße
Thomas

[A.Harrenberg]

Hi,

es gibt da ein sehr gutes Krypto-Buch:
"Niels Ferguson, Bruce Schneier, Tadayoshi Kohno - Cryptography Engineering"

puh, bei mir stapeln sich schon die Bücher die ich noch lesen muss... Aber realistisch gesehen wird mir da ein wenig Erklärung gut tun. Aber wenn Du doch jetzt schon alles weißt... 

Fertige Z-Wave Rauchmelder sind definitiv billiger als meine Zeit für das reverse Engineering...

Tja, das ist immer das Problem. Wenn man das nicht auch als Hobby oder "Education" sieht, lohnt sich das in den meisten Fällen nicht da irgendwas selber zu machen. Und es bleibt ja auch ein gewisses Restrisiko das es nachher doch nicht funktioniert. Und reverese Engineering kann schon ziemlich nervig sein. ZWave war zu Anfang ja quasi nur reverese Engineering mit ein paar veralteteten Informationen die im Internet aufgetaucht sind...
Und auch das Thema mit der Stromversorgung ist ja nicht ganz so ohne. Du brauchst ja auch noch irgendwie Batterien für die zusätzliche Hardware und dann muss das ganze ja auch noch einen akzeptablen WAF haben...

Zurück zum Thema: Die LED des ZUNO kann ich jetzt auch per Funk steuern 

Hoffe die Firmware-Version 2.08 kommt bald. Ich wette darauf, daß nichtmaskierte Interrupts die I2C Kommunikation, ADC Auswertung usw. gestörte hatten. Das Problem gibt's auch bei normaler Arduino-Programmierung mit dem ADC.

2.0.8 ist heute rausgekommen. Habe es eben gelesen aber noch nichts runtergelanden oder Firmware upgedatet. Bei dem 9-Kanal Testaufbau werde ich das auch erst mal nicht machen, das Anlegen der ganzen Kanäle etc. war schon eine ziemliche Arbeit. Ich denke da muss ich mal sehen wie ich das ganze per Replace_Node machen kann damit ich das nicht noch mal von vorne anlegen muss. Das kann ich dann ja mit Z-Uno #3 testen 

Na das die Pins 17-22 auf Low gezogen werden sobald per ZWave gesendet wird könnte schon mit dem Interrupt handling zusammenhängen. Insgesamt ist die Feature-list von 2.0.8 aber deutlich kürzer ausgefallen als mal angekündigt. Mich hätte ja die Config-Parameter, eine erste S2 Implementierung und die Tools zum Stack-handling interessiert. Aber es wäre schon mal gut wenn die Bugfixes jetzt wirklich helfen und zumindest mal die I/O Sachen vernünftig laufen ohne das man an seinem Verstand zweifeln muss.

Wenn ich keinen Logic-Analyzer zur Verfügung gehabt hätte wäre ich an dem Verhalten der Pins 17-22 wahrscheinlich verzeifelt weil es keinen logischen Grund gab warum es nicht hätte funktionieren sollen. So konnte ich es wenigstens messen und beweisen.

Gruß,
Andreas.

[T3mplate]

Hat jemand gefunden ob man an den Z-Uno ein Touchdisplay anschließen kann?
Ich hätte gerne ein ZWave Gerät ähnlich diesem:

http://www.avolta.de/elektro-shop/knx/sensorik/glas-tastsensoren/mdt-begt20s01-glastaster-smart-6fach-sensor-farbdisplay-schwarz

Ich weiß das man das mit einem Raspberry, Display und WLAN-Stick realisieren kann.
Ich hätte es aber gerne, dass bei einem Klick ein ZWave Signal erzeugt wird (und nicht per WLAN an fhem)

[A.Harrenberg]

Hi,

Hat jemand gefunden ob man an den Z-Uno ein Touchdisplay anschließen kann?
Ich hätte gerne ein ZWave Gerät ähnlich diesem:

http://www.avolta.de/elektro-shop/knx/sensorik/glas-tastsensoren/mdt-begt20s01-glastaster-smart-6fach-sensor-farbdisplay-schwarz

soweit mir bekannt ist hat bisher keiner eine Lib für ein Touchdisplay portiert. Aktuell habe ich nur ein kleines OLED (ohne Touch) per I2C angeschlossen. Größere Displays werden wohl meist über SPI angesprochen, eine entsprechende Lib für den Zuno kenne ich aber auch noch nicht. Wie bei einem TouchDisplay dann der Touch ausgewertet bin kann ich auch nicht sagen...

Wie die Ansteuerung des von Dir verlinkten Displays gelöst ist geht aus der Beschreibung ja auch nicht hervor, da steht nur was von "Busankopplung".

Wenn Du Mikrocontroller zumindest grundlegend programmieren kannst, und das ist Voraussetzung für den Z-Uno, dann solltest Du mal schauen was für Displays für Dich in Frage kommen und was für ein  Interface die haben. Für SPI, I2C, UART und OneWire bietet der Z-Uno auf jeden Fall schon mal entsprechende Libraries/Funktionen an. Eine Library z.B. vom Arduino zu portieren ist aber nicht immer trivial, der Z-Uno hat aufgrund der Architektur und der Tatsache das das ja noch eine ZWave-Schicht drauf läuft nicht so viel Stack und das kann leider zum Showstopper werden.

Einige Beispiele gibt es hier, ansonsten kann ich auch das Forum empfehlen, da ist einer der Entwickler (PoltoS) sehr aktiv.

Gruß,
Andreas.