Versuch via Fhem2Fhem ZWave zum zu verbinden

Begonnen von morph, 17 Juni 2017, 22:26:56

Vorheriges Thema - Nächstes Thema

morph

Hallo Fhemler,

folgendes Scenario bei mir:

Auf einem Haupt RPi Fhem

Nun habe ich einen weitern Raspi bekommen mit einem Razberry Board.

Auf dem Slave habe ich Fhem installiert und dann das Modul geladen:

define ZWAVE1 ZWDongle /dev/ttyAMA0@115200
Internals:
   CallbackNr 4
   Clients    :ZWave:
   DEF        /dev/ttyAMA0@115200
   DeviceName /dev/ttyAMA0@115200
   FD         8
   MaxSendRetries 3
   NAME       ZWAVE1
   NR         18
   PARTIAL
   RAWMSG     00040002055b037d8202
   ReadTime   1497730800.75553
   STATE      Initialized
   SendRetries 0
   SendTime   1497730630.45401
   TYPE       ZWDongle
   WaitForAck 0
   ZWAVE1_MSGCNT 81
   ZWAVE1_TIME 2017-06-17 22:20:00
   homeId     exxxxx57
   nodeIdHex  01
   nrNAck     0
   Matchlist:
     1:ZWave    .*
   Readings:
     2017-06-17 22:15:23   caps            Vers:5 Rev:4 ManufID:0147 ProductType:0400 ProductID:0002 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2017-06-17 22:15:23   ctrlCaps        PRIMARY
     2017-06-17 22:15:23   homeId          HomeId:e5xxxxx7 CtrlNodeIdHex:01
     2017-06-17 20:40:48   isFailedNode_2  yes
     2017-06-17 20:40:52   isFailedNode_3  no
     2017-06-17 20:41:08   nodeInfo_2      ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SENSOR_NOTIFICATION SpecificDevClass:01
     2017-06-17 20:34:49   nodeList        ZWAVE1 UNKNOWN_2
     2017-06-17 22:15:23   random          b85d4515e416e27f82115484b2cd83d1314714a0a86d42c06cb14fd4200f5d91
     2017-06-17 22:15:23   state           Initialized
     2017-06-17 22:15:23   sucNodeId       no
     2017-06-17 20:40:35   version         Z-Wave 4.05 STATIC_CONTROLLER
   SendStack:
Attributes:


Ich kann nun auch die Devices dort anlernen:
Internals:
   CFGFN
   DEF        e58b3a57 5
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     1
   NAME       ZWave_SENSOR_NOTIFICATION_5
   NR         57
   STATE      associationAdd 5 1
   TYPE       ZWave
   ZWAVE1_MSGCNT 1
   ZWAVE1_RAWMSG 00040005087205010f0c021002
   ZWAVE1_TIME 2017-06-17 22:17:08
   ZWaveSubDevice no
   homeId     e58b3a57
   isWakeUp   1
   lastMsgSent 1497730630.45358
   nodeIdHex  05
   Readings:
     2017-06-17 22:17:08   model           FIBARO System FGSD002 Smoke Sensor
     2017-06-17 22:17:08   modelConfig     fibaro/fgsd002.xml
     2017-06-17 22:17:08   modelId         010f-0c02-1002
     2017-06-17 22:17:08   state           associationAdd 5 1
     2017-06-17 22:17:10   timeToAck       0.024
     2017-06-17 22:17:10   transmit        OK
Attributes:
   IODev      ZWAVE1
   classes    ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL WAKE_UP BATTERY ALARM CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL MULTI_CHANNEL_ASSOCIATION APPLICATION_STATUS SENSOR_ALARM SECURITY FIRMWARE_UPDATE_MD
   room       ZWave
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 SECURITY:1 SENSOR_ALARM:1 SENSOR_MULTILEVEL:8 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2


Auf dem Master habe ich ein Dummy und die Verbindung erstellt

define ZWAVE2 FHEM2FHEM 10.233.xx.xxx:7072 RAW:ZWAVE1
define ZWAVE1 ZWDongle none
attr ZWAVE1 dummy 1

Internals:
   CFGFN
   CallbackNr 0
   Clients    :ZWave:
   DEF        none
   DeviceName none
   MaxSendRetries 3
   NAME       ZWAVE1
   NR         6269
   PARTIAL
   STATE      disconnected
   SendRetries 0
   TYPE       ZWDongle
   WaitForAck 0
   errReported 1
   nrNAck     0
   .clientArray:
     ZWave
   Matchlist:
     1:ZWave    .*
   Readings:
     2017-06-17 22:14:36   state           disconnected
   SendStack:
Attributes:
   dummy      1

Internals:
   CFGFN
   Clients
   DEF        10.233.30.200:7072 RAW:ZWAVE1
   FD         113
   Host       10.233.xx.xxx:7072
   NAME       ZWAVE2
   NR         6120
   PARTIAL
   STATE      connected
   TYPE       FHEM2FHEM
   informType RAW
   rawDevice  ZWAVE1
Attributes:



Nun sollten doch die Devices automatisch wenn im Slave angelegt im Master mit angelegt werden?

Vielleicht kann mir einer helfen, das zum laufen zu bekommen.
Danke

rudolfkoenig

Ich gehe davon aus, dass man ZWave ueber FHEM2FHEM:RAW nicht sorgenfrei betreiben kann. Folgende Probleme sehe ich:
- da ZWawe1 nach ZWave2 definiert ist, wird ZWave1 vorzugsweise als IODev verwendet
- da ZWave2 kein homeId Internal hat, werden die Nachrichten in ZWave Modul beim Parsen sofort abgewiesen (mit Meldung im Log).
- die FHEM-ZWave-Warteschlange kommt durcheinander, falls ACKs von Befehlen eintreffen, die eine anderen ZWave-Instanz generiert hat.
- nach der Inklusion schickt das ZWave Modul auf beiden Rechnern etliche Befehle (get model, etc) zweimal los, das fuehrt auch zu Chaos.

Bevor ich Gedanken ueber fixen dieser Probleme mache, wollte ich wissen warum einer der folgenden Alternativen nicht praktikabel ist:
- FHEM2FHEM auf dem Master in Log-Mode
- Auf dem slave keine FHEM-Instanz, und der Razberry wird per socat/ser2net auf dem Master eingebunden.

morph

Hi,

Danke das du dir die Zeit genommen hast.

Die 4 Punkte nehme ich mal als ein ist momentan nicht so ohne weiteres einsetzbar auf. Ok, Danke. Dann lag/liegt es nicht an mir.

Zum zweiten:

Reichen die Logs denn dafür aus? Theoretisch wahrscheinlich dann schon? Z-Wave soll bei mir die Überwachung machen, Sirene, Feuermelder, Fernbedienung um die Alarmanlage ein aus zu schalten, usw.

Das mit Socat/ser2net lese ich zum ersten mal und ist mir neu, bzw. hab ich mich nicht eingelesen.

rudolfkoenig

ZitatDas mit Socat/ser2net lese ich zum ersten mal und ist mir neu, bzw. hab ich mich nicht eingelesen.

Siehe https://wiki.fhem.de/wiki/CUL_ueber_Netz
Die Baudrate ist 115200, die ZWDongle Definition lautet dann
define ZWDongle_0 ZWDongle hostname:port

morph

Lol....

Warum auch einfach wenn es kompliziert geht.

So eingebunden auf dem Slave-Raspi?!

2000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE

So definiert auf dem Master Raspi?!

define Z_Wave_CUL ZWDongle 10.xxx.xx.200:2000
attr Z_Wave_CUL room ZWave
define Rauchmelder_Wohnen ZWave e5xxxx7 7
attr Rauchmelder_Wohnen IODev ZWDongle_0
attr Rauchmelder_Wohnen classes ZWAVEPLUS_INFO BASIC VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL WAKE_UP BATTERY ALARM CRC_16_ENCAP CONFIGURATION SENSOR_MULTILEVEL MULTI_CHANNEL_ASSOCIATION APPLICATION_STATUS SENSOR_ALARM SECURITY FIRMWARE_UPDATE_MD
attr Rauchmelder_Wohnen room ZWave
define FileLog_Rauchmelder_Wohnen FileLog ./log/Rauchmelder_Wohnen-%Y.log Rauchmelder_Wohnen
attr FileLog_Rauchmelder_Wohnen logtype text
attr FileLog_Rauchmelder_Wohnen room ZWave


Und gleichzeitig den Rauchmelder eben mal eingebunden....

Oh man...

So ist das alles richtig?

rudolfkoenig

Wenn es funktioniert, dann ja. Ich kenne es auch nur aus der Theorie. :)

morph

Also die erste Schaltung hab ich einfach mal ausgelöst und es hat getudelt.... zwar mit 1-2 sek Verzögerung. Aber Wayne interessiert das bei dem was ich damit vorhabe?!

Oder was meinst du?

rudolfkoenig

Ich weiss nicht, wie das zweiter RPi angebunden ist, aber 1-2 Sekunden kommen mir zu viel vor, ich meine 10-100ms ist normal. Wir hatten das 1-2s auch mit direkt angebundenen ZWave-Sticks, wo die Zwave Nachrichten einen abenteuerlichen Weg durch mehrere ZWave-Repeater genommen haben.

morph

Ok, das schau ich mir dann noch an, ob da irgendwo was falsch geleitet wird.

Jetzt gehts erstmal ans Einbinden ;-)