Hi,
irgendwie konnte ich nicht wiederstehen...
Ein neues Spielzeug hat seine Verbinung mit meinem ZWave Netz aufgenommen ,-)
Habe mir einen Z-Wave.me Z-Uno zugelegt und den gerade mal mit Strom versorgt und inkludiert. Jetzt blinkt da ein Testsketch munter rum und soll sich eigentlich auch per "dim" in der Geschwindigkeit ändern lassen, das habe ich aber noch nicht hinbekommen...
Im Beispielsketch meldet der sich mit einem Subdevice an:
Internals:
CFGFN
DEF e015dfed 10
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 3
NAME ZWave_SWITCH_MULTILEVEL_10
NR 50
STATE dim 86
TYPE ZWave
ZWDongle_0_MSGCNT 3
ZWDongle_0_RAWMSG 0004000a06600a01110126
ZWDongle_0_TIME 2016-09-13 21:51:27
ZWaveSubDevice no
homeId e015dfed
isWakeUp
lastMsgSent 1473796526.25728
nodeIdHex 0a
Readings:
2016-09-13 21:51:27 mcCapability_01 SWITCH_MULTILEVEL
2016-09-13 21:51:27 mcEndpoints total 1, different
2016-09-13 21:51:27 model Z-Wave.Me Z-Uno
2016-09-13 21:51:27 modelConfig zwave.me/ZUno.xml
2016-09-13 21:51:27 modelId 0115-0110-0001
2016-09-13 21:54:04 state dim 86
2016-09-13 21:55:26 timeToAck 0.688
2016-09-13 21:55:26 transmit OK
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO BASIC SWITCH_MULTILEVEL CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC
room ZWave
vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SWITCH_MULTILEVEL:1 VERSION:2 ZWAVEPLUS_INFO:2
und
Internals:
CFGFN
DEF e015dfed 2561
IODev ZWDongle_0
NAME ZWave_SWITCH_MULTILEVEL_10.01
NR 53
STATE dim 0
TYPE ZWave
ZWaveSubDevice yes
homeId e015dfed
nodeIdHex 0a01
Readings:
2016-09-13 21:55:26 state dim 0
Attributes:
IODev ZWDongle_0
classes SWITCH_MULTILEVEL
room ZWave
Momentan werden noch nicht soo viele Klassen unterstützt, aber zum Spielen reicht es auf jeden Fall schon mal aus, alleine mit SWITCH_BINARY, SWITCH_MULTILEVEL kann man schon 'ne Menge machen.
Jetzt muss ich mir mal diese IDE installieren und dann verstehen wie das mit dem Multi_Channel funktioniert um da auch die Blinkfrequenz einstellen zu können. ,-)
@Christian: Wollte Dir gerade anbieten das Ding auch in die XML einzubinden, dabei ist mir aufgefallen das es schon erkannt wird ,-)
Gruß,
Andreas.
Koennte man das Ding zum ueben von Firmware-Update verwenden?
Hi Rudi,
denke nicht... Habe gerade ein wenig danach geschaut und das Firmware-Update bezieht sich wohl auf die untersten Layer auf dem ZWave-Chip an die man ja nicht dran kommt. Da ist auch kein "Frontend" für in der IDE vorhanden.
Ich kann da aber in dem Z-Uno Forum mal nachfragen um das zu bestätigen.
Gruß,
Andreas.
Hi Rudi,
vielleicht kann man da doch was machen...
Anscheinend ist geplant das auch der Sketch updatedated werden kann, dann müsste es einfach sein eine entsprechende Datei zu erstellen und damit zu spielen. Ob man das Ding dabei auch "bricken" kann weiß ich nicht...
Gruß,
Andreas.
Zitat
Sketchupdate via FIRMWARE_UPDATE_MD class?
Postby A.Harrenberg » 15 Sep 2016 06:15
Hi,
I did not found a description of the FIRMWARE_UPDATED_MD class, but I expect that this function will only update the core of the Z-UNO, like the ZWave-Network and application layer as well as the sketch bootloader but not the sketch itself.
Is this correct?
Is there or will there be a possibility to also update the sketch via the update class?
Thnx,
Andreas.
A.Harrenberg
Re: Sketchupdate via FIRMWARE_UPDATE_MD class?
postby PoltoS » 16 Sep 2016 23:26
Correct, currently only core part csn be updated. In october we plan to add this function to also alow update the sketch.
Hi,
SECURITY lässt sich an dem Z-Uno nur generell (für alle Klassen) ein- oder ausschalten, man kann nicht wählen ob bestimmte Klassen non-secure bleiben sollen.
Ich habe eine Anfrage hierzu in das Z-Uno Forum gestellt, Rückmeldung ist aber das dies zu viel Komplexität in den Z-Uno bringen würde... ,-(
Ich habe noch mal gefragt ob es nicht doch über eine Art Expertenmenü machbar wäre, mal sehen ob was passiert, ich erwarte dort aber nichts.
Wer also vorhat mit dem Ding irgendwas zu implementieren was er mit SECURITY machen möchte sollte sich darüber im Klaren sein das es ganz oder gar nicht ist.
"Lustig" ist das Ding aber dennoch ,-) Ich kann jetzt verschlüsselt die on-board LED dimmen ;-)
Gruß,
Andreas.
Bei welcher Szenario ist eine Teilverschluesselte Anbindung interessant?
Hi Rudi,
ich könnte mir z.B. eine Türverriegelung vorstellen bei der die Befehle zum Öffnen natürlich verschlüsselt sind, der Status der Tür aber auch unverschlüsselt z.B. an eine Lampe geschickt werden kann um ein "coming home light" zu realisieren.
Das kann natürlich auch über Notify gemacht werden, aber security Nachricht = ca. 3x mehr Funklast + zusätzliche non-secure Nachricht ist overhead der nicht immer sinnvoll ist.
Gruß,
Andreas.
Hi Rudi,
Zitat von: rudolfkoenig am 14 September 2016, 07:01:54
Koennte man das Ding zum ueben von Firmware-Update verwenden?
könnte jetzt gehen...
Der Z-Uno unterstützt jetzt Over-the-Air upgrade (https://z-uno.z-wave.me/z-wave/ota/), man kann sowohl nur den Sketch als auch die Firmware hochladen, man muss dann wohl entweder target 0 oder target 1 auswählen... Das ganze geht aber nur für FIRMAWARE_UPDATE_MD Version 3, die Versionen sind ja anscheinend nicht untereinander kompatibel.
Gruß,
Andreas.
P.S.: Ich überlege ernsthaft mir noch einen zweiten zu kaufen und den an Z-Way anzubinden um vergleichen zu können... Für den ersten habe ich mir einen haufen kleiner Sensor-Shields bestellt ,-) So ein DHT11 ist schon angekommen und angeschlossen. ,-)
Hi Andreas,
wie zufrieden bist Du inzwischen mit dem Z-Uno? Lohnt es sich darauf eigene Sensoren aufzubauen? Hast Du evtl. auch schon Erfahrungen mit einem Outdoor-Einsatz (Batteriebetrieb) gemacht?
Gruß Ralf
Hi Ralf,
Meine anfängliche Euphorie beginnt etwas zu schwinden... Es gibt noch ein paar unschöne Bugs im low-level Bereich... Zum Beispiel gibt es 4 Pins die auf Low gezogen werden sobald etwas auf Zwave passiert. Wenn man zufällig genau diese Pins benutzt um andere Hardware anzusprechen wird es interessant...
Aber die Jungs sind hoch motiviert und wenn man was meldet arbeiten sie wirklich daran das zu beheben.
Ich denke das es aber noch 1-3 Releases braucht um die aktuellen Probleme zu lösen.
Batterie Betrieb und Flirs habe ich bisher noch gar nicht ausprobiert.
Ich habe aber aktuell einen Dht11 (Temp+Humidity), einen Bmp XXX (Temp + Drück, einen PIR motion sensor, zwei Helligkeitssensoren und ein OLED in Betrieb und das funktioniert erstaunlich gut!
Was hast Du denn vor?
Gruß,
Andreas.
Zitat von: A.Harrenberg am 10 Januar 2017, 16:22:39
Was hast Du denn vor?
Ich habe (immer) noch keinen Temperatur- und Helligkeitssensor gefunden, welchen ich mir ans Carport schrauben kann und >= IP44 ist. Bei enOcean gibt es etwas in der Richtung, aber ich möchte dafür nicht ein weiteres Interface aufsetzen.
Daher die Idee dort etwas mit einem Z-Uno zu bauen und da lassen sich dann auch gleich 2 Temperatursensoren realisieren.
Welche Helligkeitssensoren hast Du verwendet?
Gruß Ralf
Hi,
Ich bin momentan unterwegs und suche das in 2 Wochen mal raus. Das sind alles so Billigteile.
Am besten fragst du mich in 2 Wochen mal per PM damit ich daran denke.
Gruß,
Andreas
Hi,
Zitat von: reb am 10 Januar 2017, 18:14:31
Welche Helligkeitssensoren hast Du verwendet?
also zum einen den BH1750, er ist per One-Wire verdrahtet. Ich haben meinen hier (https://www.roboter-bausatz.de/299/bh1750fvi-digitaler-lichtintensitaet-sensor-kompatibel-mit-arduino) bestellt.
Mit dem habe ich aber noch nicht so viel rumgespielt, der hängt momentan an dem zweiten Z-Uno und dient mir momentan nur als Testobjekt für die Portierung einer SPI-Library für einen billigen RFID-Reader.
Der andere Sensor ist ein billiger Analoger Sensor, aus der gleichen Quelle, zu finden hier (https://www.roboter-bausatz.de/149/lichtsensor-modul). (Geliefert wird der allerdings frecherweise ohne die Kabel...). Der wird dann ganz normal analog ausgelesen. Man kann auch eine Schwelle per Poti einstellen und einen digitalen Ausgang nutzen, das ist aber "fummelig" und der Ausgang hat so gut wie keine Hysterese, d.h. im Grenzbereich toggelt das Signal wie wild. Ich habe nur das analoge Signal genutzt und mir da auf 0-100% skaliert. Das Signal muss man sicherlich je nach Einbaulage / Ausrichtung anders interpretieren, die Auflösung ist aber eigentlich schon ok so, ich habe mal ein Diagramm angehängt wie das so über Tag aussieht. Momentan sind da die Messwerte sowie eine Glättung im Diagramm, die ca. 40% ist dann die Helligkeit bei eingeschalteter Deckenlampe, das Ding zeigt momentan nach oben...
Bei den ersten Tests mit dem BH1750 schien mir der recht winkelabhängig zu sein, momentan kann/will ich damit aber nicht rumspielen da der Z-Uno dort momentan für was anderes verwendet wird.
Die Entwickler des Z-Uno sind aber weiterhin sehr fleißig, der von mir beschriebene Bug mit den Pins die durch "Funkverkehr" auf Low gezogen werden ist wohl schon gefunden und wird im nächsten Release dann behoben sein.
Allerdings tauchen jetzt einige Unschönheiten/Bugs im verwendeten Pre-Compiler auf die nur sehr schwer nachzuvollziehen sind...
Ein Analog-Sensor und entsprechend One-Wire Sensoren anzubinden stellt aber kein Problem dar. ,-)
Gruß,
Andreas.
Hi,
Zitat von: A.Harrenberg am 18 Januar 2017, 17:48:10
also zum einen den BH1750, er ist per One-Wire verdrahtet.
den habe ich inzwischen auch gefunden und kurz angetestet.
Inzwischen habe ich mich auch mit dem Z-Uno weiter beschäftigt und im Z-Uno Forum gelesen bzw. geschrieben. Soweit ich das bisher durchblicken konnte gibt es beim Z-Uno noch einiges zu tun:
- Doku ist nicht immer ganz vollständig bzw. verständlich
- Libraries gefühlt teilw. noch im Beta-Status
- das Thema Battery-powered/wakeup devices könnte noch ein paar Erweiterungen/Erläuterungen gebrauchen
Mal sehen was die nächste Version mitbringt...
Gruß Ralf
Hi Ralf,
das Ding ist sicherlich nichts für Anfänger. Man sollte etwas von ZWave verstehen UND auch Microcontroller programmieren können. Grundwissen in Assembler schaden da auch nicht, vor allem wenn man größere Projekte/Libraries vom Arduino anpassen möchte. Mit "gesundem Halbwissen" bekommt man aber auch einfachere Sachen wie die Temperatursensoren, Analogeingänge oder auch ein OLED hin. Für diese "normalen" Sachen gibt es funktinierende Libraries und auch Beispiele.
Die Doku ist teilweise etwas verstreut, manchmal auch etwas unverständlich, aber auf Nachfragen wurde bisher alles klargestellt und bereinigt.
Libraries lassen sich leider nicht so ohne weiteres vom Arduino übernehmen. Zum einem muss man ein paar Besonderheiten beim Compiler beachten, zum anderen gibt es das Problem mit dem relativ kleinen Stack des 8051. Daran scheitert gerade mein Versuch eine Library für einen billigen RFID-Leser zu portieren.
Ja mal sehen was die nächste Version so bringt. Immerhin ist der Bug mit den 4 IO Leitungen gefunden die bei Funkbetrieb einfach mal so auf Low wechseln...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 22 Januar 2017, 17:58:08
das Ding ist sicherlich nichts für Anfänger. Man sollte etwas von ZWave verstehen UND auch Microcontroller programmieren können.
Hi Andreas,
das ist wohl war - da scheint es mehrere Pitfalls zu geben.
Mit besonderem Z-Wave-Wissen kann ich leider nicht aufwarten und stolpere gerade darüber, dass ein Multi-Channel-Device (3 Channels) in Fhem das Master und 3 Slave-Devices anlegt, ein vom Z-Uno gesendetes Update (unsolicited, always powered) aber nicht bei den zugehörigen Endpoints landet :-/
Hast Du eine Idee was fehlen könnte?
Gruß Ralf
Hi,
Zitat von: reb am 22 Januar 2017, 21:05:09
das ist wohl war - da scheint es mehrere Pitfalls zu geben.
ja, und das "dumme" daran ist das man in vielen Fällen gar nichts dafür kann, weil es momentan meist noch Bugs in der low-level Firmware sind oder der Compiler da was verbockt...
Zitat von: reb am 22 Januar 2017, 21:05:09
Mit besonderem Z-Wave-Wissen kann ich leider nicht aufwarten und stolpere gerade darüber, dass ein Multi-Channel-Device (3 Channels) in Fhem das Master und 3 Slave-Devices anlegt, ein vom Z-Uno gesendetes Update (unsolicited, always powered) aber nicht bei den zugehörigen Endpoints landet :-/
Hast Du die Assoziationen per mca-add gemacht? Ich habe das damals auch mal falsch gehabt und recht merkwürdige Effekte gehabt. Danach ist was an FHEM umgestellt worden und ich habe die Endpoints einzeln per mca-add hinzugefügt. Momentan geht es bei mir, ich kann aber nicht mehr genau sagen was ich gemacht habe...
Die Events für Endpoint 1 kommen aber trotzdem beim Master an...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 22 Januar 2017, 21:35:29
Hast Du die Assoziationen per mca-add gemacht?
Habe es gerade mal probiert, aber wie unten zu sehen ist gibt dort nur einen Channel - wie sieht das bei Deinem Device aus?
Internals:
CFGFN
DEF eec660ff 11
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 29
NAME ZWave_SENSOR_MULTILEVEL_11
NR 94
STATE mcaAdd 3 0 1 2
TYPE ZWave
ZWDongle_0_MSGCNT 29
ZWDongle_0_RAWMSG 0004000b06600a03210131
ZWDongle_0_TIME 2017-01-22 23:04:51
ZWaveSubDevice no
endpointChildren ZWave_SENSOR_MULTILEVEL_11.01,ZWave_SENSOR_MULTILEVEL_11.02,ZWave_SENSOR_MULTILEVEL_11.03
homeId eec660ff
isWakeUp
lastMsgSent 1485122691.64383
nodeIdHex 0b
Readings:
2017-01-22 22:54:32 assocGroup_1 Max 5 Nodes ZWDongle_0
2017-01-22 22:54:32 assocGroups 1
2017-01-22 22:54:38 configBlinkServiceLED Enabled
2017-01-22 22:54:38 configDebugMode Disabled
2017-01-22 23:04:51 mcCapability_01 SENSOR_MULTILEVEL
2017-01-22 23:04:51 mcCapability_02 SENSOR_MULTILEVEL
2017-01-22 23:04:51 mcCapability_03 SENSOR_MULTILEVEL
2017-01-22 23:04:51 mcEndpoints total 3, different
2017-01-22 23:01:52 mcaGroups 1
2017-01-22 23:01:52 mca_1 Max 5 Nodes ZWDongle_0
2017-01-22 22:55:14 model Z-Wave.Me Z-Uno
2017-01-22 22:55:14 modelConfig zwave.me/ZUno.xml
2017-01-22 22:55:14 modelId 0115-0110-0001
2017-01-22 23:01:44 state mcaAdd 3 0 1 2
2017-01-22 22:54:17 temperature 23.1 C
2017-01-22 23:04:51 timeToAck 0.027
2017-01-22 23:04:51 transmit OK
2017-01-22 22:55:23 zwavePlusInfo version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0d00 userIcon:0d00
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO BASIC SENSOR_MULTILEVEL CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC
room ZWave
vclasses ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SENSOR_MULTILEVEL:7 VERSION:2 ZWAVEPLUS_INFO:2
Hi,
Zitat von: reb am 22 Januar 2017, 23:14:51
Habe es gerade mal probiert, aber wie unten zu sehen ist gibt dort nur einen Channel - wie sieht das bei Deinem Device aus?
also bei mir gibt es auch nur einen mca, aber mein Wert sieht anders aus...
Internals:
DEF e015dfed 64
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 2500
NAME ZWave_SWITCH_MULTILEVEL_64
NR 34
STATE off
TYPE ZWave
ZWDongle_0_MSGCNT 2500
ZWDongle_0_RAWMSG 000400400b7105000000ff0700010800
ZWDongle_0_TIME 2017-01-23 07:30:48
ZWaveSubDevice no
endpointChildren ZWave_SWITCH_MULTILEVEL_64.01,ZWave_SENSOR_MULTILEVEL_64.02,ZWave_SENSOR_MULTILEVEL_64.03,ZWave_SENSOR_MULTILEVEL_64.04,ZWave_ALARM_64.05,ZWave_SWITCH_BINARY_64.06,ZWave_SENSOR_MULTILEVEL_64.07,ZWave_SENSOR_MULTILEVEL_64.08,ZWave_Node_64.9,ZWave_Node_64.39
homeId e015dfed
isWakeUp
lastMsgSent 1485152965.85592
nodeIdHex 40
Readings:
2017-01-22 19:46:23 UNPARSED APPLIANCE 0a640d030031058522015e
2017-01-23 07:30:48 alarm HomeSecurity: Event cleared: Motion Detection - Unknown Location, arg 010800
2016-12-31 16:46:29 configBlinkServiceLED Enabled
2016-10-09 11:48:22 configDebugMode Enabled
2016-10-29 11:04:38 glassBreak off
2017-01-18 00:50:26 luminance 18.6 %
2016-10-09 10:45:02 mcCapability_01 SWITCH_MULTILEVEL
2016-10-09 10:45:02 mcCapability_02 SENSOR_MULTILEVEL
2016-10-09 10:45:02 mcCapability_03 SENSOR_MULTILEVEL
2016-10-09 10:45:02 mcCapability_04 SENSOR_MULTILEVEL
2016-10-09 10:45:02 mcCapability_05 ALARM SENSOR_BINARY
2016-10-09 10:45:02 mcCapability_06 SWITCH_BINARY
2016-10-09 10:45:02 mcCapability_07 SENSOR_MULTILEVEL
2016-10-09 10:45:02 mcCapability_08 SENSOR_MULTILEVEL
2016-10-09 10:45:02 mcCapability_09 SENSOR_MULTILEVEL
2016-10-09 10:45:02 mcEndpoints total 9, different
2017-01-23 07:29:26 mca_1 Max 5 Nodes ZWDongle_0 ZWDongle_0:0
2016-10-08 16:34:51 model Z-Wave.Me Z-Uno
2016-10-08 16:34:51 modelConfig zwave.me/ZUno.xml
2016-10-08 16:34:51 modelId 0115-0110-0001
2017-01-23 07:30:48 motion off
2017-01-01 12:04:16 reportedState off
2017-01-01 12:04:16 state off
2017-01-23 07:30:32 temperature 20.0 C
2017-01-23 07:29:26 timeToAck 0.219
2017-01-23 07:29:26 transmit OK
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO BASIC SWITCH_BINARY SWITCH_MULTILEVEL SENSOR_BINARY ALARM SENSOR_MULTILEVEL CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC
neighborListPos 8.562616990831259,152.07853627485053
room ZWave
vclasses ALARM:5 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:7 SWITCH_BINARY:1 SWITCH_MULTILEVEL:1 VERSION:2 ZWAVEPLUS_INFO:2
Du hast nur das root-device drin stehen:
2017-01-22 23:01:52 mca_1 Max 5 Nodes ZWDongle_0
Ich habe es irgendwie geschafft dort auch eine Art Endpoint definition drin zu haben:
2017-01-23 07:29:26 mca_1 Max 5 Nodes ZWDongle_0 ZWDongle_0:0
Das dürfte der "Trick" sein. Ich bekomme auf allen Endpoints die jeweiligen Reports geliefert.
Ich kann jetzt aber nicht mehr sagen wie ich das gemacht habe... Ich denke mit "mca add 1 0 1 0".
Dein "mcaAdd 3 0 1 2" verstehe ich nicht, das müsste eigentlich eine Assoziation mit node 3 und eine Endpointverknüpfung des channel 2 mit der Node 1 herstellen...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 22 Januar 2017, 21:35:29
Danach ist was an FHEM umgestellt worden und ich habe die Endpoints einzeln per mca-add hinzugefügt.
Die Änderung ist mWn wieder zurückgedreht, da die Theorie praktisch nicht funktionierte. Momentan ist die Zuordnung nach meiner Interpretation des Standards nicht sauber, aber ich habe keine bessere Idee.
Gruß, Christian
Zitat von: A.Harrenberg am 23 Januar 2017, 07:48:21
Dein "mcaAdd 3 0 1 2" verstehe ich nicht, das müsste eigentlich eine Assoziation mit node 3 und eine Endpointverknüpfung des channel 2 mit der Node 1 herstellen...
Soweit ich multi-channel-association meine verstanden zu haben, hätte ich jetzt beim Z-Uno erwartet für jeden Channel eine Association via "mcaAdd" hinzufügen zu können. Ist das nun der Z-Uno, welcher da etwas missen lässt?
Gruß Ralf
Zitat von: A.Harrenberg am 23 Januar 2017, 07:48:21
Dein "mcaAdd 3 0 1 2" verstehe ich nicht, das müsste eigentlich eine Assoziation mit node 3 und eine Endpointverknüpfung des channel 2 mit der Node 1 herstellen...
Node 3? Ich war bisher davon ausgegangen, dass der erste Parameter sinngemäß dem Channel entspricht - zumindest passt dieser Gedanke zu einem WallC.
Mit einem "mcaAdd 1 0 1 0" bekommt man es tatsächlich hin, dass alle Child-Nodes (2x Temperatur - Chn 1+2, 1x Luminance - Chn 3) bedient werden:
2017-01-23 20:45:00 ZWave ZWave_SENSOR_MULTILEVEL_11.03 luminance: 241 Lux
2017-01-23 20:45:14 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 25.5 C
2017-01-23 20:45:14 ZWave ZWave_SENSOR_MULTILEVEL_11.01 temperature: 25.5 C
2017-01-23 20:45:14 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 25.5 C
2017-01-23 20:45:14 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 25.5 C
2017-01-23 20:45:15 ZWave ZWave_SENSOR_MULTILEVEL_11.02 temperature: 23.1 C
2017-01-23 20:45:44 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 23.8 C
2017-01-23 20:45:44 ZWave ZWave_SENSOR_MULTILEVEL_11.01 temperature: 23.8 C
2017-01-23 20:45:44 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 23.8 C
2017-01-23 20:45:44 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 23.8 C
2017-01-23 20:45:45 ZWave ZWave_SENSOR_MULTILEVEL_11.02 temperature: 27.4 C
2017-01-23 20:46:15 ZWave ZWave_SENSOR_MULTILEVEL_11.02 temperature: 24.0 C
2017-01-23 20:46:51 ZWave ZWave_SENSOR_MULTILEVEL_11.02 temperature: 23.4 C
2017-01-23 20:46:56 ZWave ZWave_SENSOR_MULTILEVEL_11.03 luminance: 7 Lux
2017-01-23 20:49:31 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 22.6 C
2017-01-23 20:49:31 ZWave ZWave_SENSOR_MULTILEVEL_11.01 temperature: 22.6 C
2017-01-23 20:49:31 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 22.6 C
2017-01-23 20:49:31 ZWave ZWave_SENSOR_MULTILEVEL_11 temperature: 22.6 C
2017-01-23 20:50:07 ZWave ZWave_SENSOR_MULTILEVEL_11.02 temperature: 22.8 C
2017-01-23 20:54:43 ZWave ZWave_SENSOR_MULTILEVEL_11.03 luminance: 284 Lux
2017-01-23 20:55:39 ZWave ZWave_SENSOR_MULTILEVEL_11.03 luminance: 279 Lux
Bei Änderungen auf dem ersten Channel wird auch der Parent-Node aktualisiert und statt einer kommen 4 Messages:
2017.01.23 20:59:09 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b063105012200f0 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.01.23 20:59:09 5: SW: 06
2017.01.23 20:59:09 5: ZWDongle_0: dispatch 0004000b063105012200f0
2017.01.23 20:59:09 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:063105012200f0 CB:00
2017.01.23 20:59:09 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b0a600d01003105012200f0 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.01.23 20:59:09 5: SW: 06
2017.01.23 20:59:09 5: ZWDongle_0: dispatch 0004000b0a600d01003105012200f0
2017.01.23 20:59:09 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:0a600d01003105012200f0 CB:00
2017.01.23 20:59:09 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b063105012200f0 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.01.23 20:59:09 5: SW: 06
2017.01.23 20:59:09 5: ZWDongle_0: dispatch 0004000b063105012200f0
2017.01.23 20:59:09 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:063105012200f0 CB:00
2017.01.23 20:59:09 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b063105012200f0 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.01.23 20:59:09 5: SW: 06
2017.01.23 20:59:09 5: ZWDongle_0: dispatch 0004000b063105012200f0
2017.01.23 20:59:09 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:063105012200f0 CB:00
Warum das so ist?!?
Gruß Ralf
Hi,
Zitat von: reb am 23 Januar 2017, 21:02:20
Node 3? Ich war bisher davon ausgegangen, dass der erste Parameter sinngemäß dem Channel entspricht - zumindest passt dieser Gedanke zu einem WallC.
Mit einem "mcaAdd 1 0 1 0" bekommt man es tatsächlich hin, dass alle Child-Nodes (2x Temperatur - Chn 1+2, 1x Luminance - Chn 3) bedient werden:
also meine Interpretation ist das die Zahl vor der "Null" die Node ist mit der mehr oder weniger ganz normal assoziiert wird. Nach der "Null" kommen dann paare mit Ziel-Node / Endpoint. Das man hier
mit Angabe einer 0 als Endpoint ans Ziel kommt liegt daran das dass Gerät dann dadurch erkennt das es jeweils an eine entsprechende Endpoint Adresse senden soll.
Zitat von: reb am 23 Januar 2017, 21:02:20
Bei Änderungen auf dem ersten Channel wird auch der Parent-Node aktualisiert und statt einer kommen 4 Messages:
Warum das so ist?!?
Das ist von ZWave so gewollt / spezifiziert. Das Root-Device soll alle Funktionen des ersten Endpoints "spiegeln". Das soll wahrscheinlich für Geräte mit nur einem Kanal die Funktionen im Hauptdevice anbieten sodaß man dann evtl. auf den Endpoint "verzichten" kann.
Gruß,
Andreas.
Zitat von: A.Harrenberg am 23 Januar 2017, 21:21:52
also meine Interpretation ist das die Zahl vor der "Null" die Node ist mit der mehr oder weniger ganz normal assoziiert wird.
Kenne den Z-Uno zwar nicht, aber bei MULTI_CHANNEL_ASSOCIATION Set-Command ist die 3 vor dem Trenner 0 mMn der Grouping Identifier (=AssociationGroup). Zwischen 3 und Trenner könnte man noch NodeIds zur Assoziierung aufnehmen, statt nur NodeId:Endpoint-Assoziationen nach dem Trenner. Wobei ich mich gerade frage, ob das nicht vielleicht sogar Pflicht sein könnte...
Gruß, Christian
Hi Krikan,
Du hast Recht, wenn man zur Abwechslung mal in die Doku schaut...
mcaAdd groupId node1 node2 ... 0 node1 endPoint1 node2 endPoint2 ...
Der erste Wert ist die Assoziationsgruppe, davon hat der Zuno nur eine, da passt es dann wahrscheinlich das der WallC mehrere hat und daher die 3 richtig sein könnte.
Wie immer, lesen bildet...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 23 Januar 2017, 21:21:52
Das ist von ZWave so gewollt / spezifiziert. Das Root-Device soll alle Funktionen des ersten Endpoints "spiegeln". Das soll wahrscheinlich für Geräte mit nur einem Kanal die Funktionen im Hauptdevice anbieten sodaß man dann evtl. auf den Endpoint "verzichten" kann.
Da war meine Frage an der falschen Stelle - sie bezog sich darauf, warum bei Änderungen auf EP1 insgesamt 4 Messages kommen, bei den EP2+3 aber je nur 1 Message...
Gruß ralf
Zitat von: A.Harrenberg am 23 Januar 2017, 21:51:15
mcaAdd groupId node1 node2 ... 0 node1 endPoint1 node2 endPoint2 ...
Der erste Wert ist die Assoziationsgruppe, davon hat der Zuno nur eine, da passt es dann wahrscheinlich das der WallC mehrere hat und daher die 3 richtig sein könnte.
Wäre mal spannend, ob der Z-Uno bei Konfiguration von Assoziationsgruppen vielleicht auch automatisch MCA's in passender Anzahl bereitstellt?
Gruß Ralf
Hi,
Zitat von: reb am 23 Januar 2017, 23:07:15
Da war meine Frage an der falschen Stelle - sie bezog sich darauf, warum bei Änderungen auf EP1 insgesamt 4 Messages kommen, bei den EP2+3 aber je nur 1 Message...
liegt wahrscheinlich daran das Du auch noch das Root-Device in der MCA drin hast.
2017-01-23 07:29:26 mca_1 Max 5 Nodes ZWDongle_0 ZWDongle_0:0
Versuch mal ob Du das mit "mcaDel 0" ALLE assoziationen löschen kannst und dann mal nur ein "mcaAdd 1 0 1 0".
Gruß,
Andreas.
Hi,
Zitat von: reb am 23 Januar 2017, 23:10:09
Wäre mal spannend, ob der Z-Uno bei Konfiguration von Assoziationsgruppen vielleicht auch automatisch MCA's in passender Anzahl bereitstellt?
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.
Aber man kann halt keine Gruppen unterschiedlich konfigurieren.
Gruß,
Andreas.
Moin,
Zitat von: A.Harrenberg am 24 Januar 2017, 07:53:45
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.
war nur eine Idee, da bei mcaAdd ja eine Group-ID verwendet wird, welche mit der AssociationGroup korrespondiert - Dein anderen Vorschlag werde ich mal testen...
Gruß Ralf
Hi Andreas,
Zitat von: A.Harrenberg am 24 Januar 2017, 07:53:45
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 (https://github.com/OpenZWave/open-zwave/issues/960) vielleicht was wir hier mit der Multi-Channel-Association sehen?
Gruß Ralf
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.
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.
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.
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
Hi,
Zitat von: buspirat am 15 Februar 2017, 00:06:20
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?
Zitat von: buspirat am 15 Februar 2017, 00:06:20
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.
Zitat von: A.Harrenberg am 15 Februar 2017, 07:21:25
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 :)
Zitat von: A.Harrenberg am 15 Februar 2017, 07:21:25
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 ;D
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
Hi,
Zitat von: buspirat am 22 Februar 2017, 22:46:10
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... ;D
Zitat von: buspirat am 22 Februar 2017, 22:46:10
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...
Zitat von: buspirat am 22 Februar 2017, 22:46:10
Zurück zum Thema: Die LED des ZUNO kann ich jetzt auch per Funk steuern ;D
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 ;D
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.
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)
Hi,
Zitat von: T3mplate am 02 März 2017, 19:03:45
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 (http://z-uno.z-wave.me/examples/), ansonsten kann ich auch das Forum (https://forum.z-wave.me/viewforum.php?f=3427) empfehlen, da ist einer der Entwickler (PoltoS) sehr aktiv.
Gruß,
Andreas.