Hi,
ich nutze das Reading reportedstate um im TabletUI den Rolladen status abzubilden.
Leider musste ich feststellen das bei zwei Rollläden das Reading reportedstate nicht mit dem Reading state nicht über ein stimmt.
Somit stimmt die aktuelle Position mit dem Reading reportedstate nicht über ein.
Meine Vermutung ist einfach, dass der Aktor(rollershutter 2) den Controller nicht erreichen kann. Da dies aber anders rum funktioniert, bin ich ein wenig verwundert. Die Route des Aktors habe ich schon gecheckt, dass sollte ok sein.
Werde morgen nochmal testen, ob es geht, wenn nicht alle Rollläden gleichzeitig hoch gehen. Vielleicht liegt es an den vielen gleichzeitig ankommenden Statusmeldungen der Aktoren.
Werde nochmal Berichten.
Wenn sonst wer Ideen hat, sind diese gerne Willkommen.
Schonmal Danke und Gruß,
Fixel
Kannst du bitte sagen, jeweils was in den Readings steht? Eigentlich wird reportedstate automatisch auf state gesetzt.
reportedState dim 35 2017-07-22 21:43:56
state on 2017-07-23 10:30:00
Hier die beiden Readings.
Das reportedstate Reading wurde das letze mal gestern Abend aktualisiert, obwohl der Rollladen um 10:30 hochgefahren wurde. für 10:30 müsste doch eigentlich auch ein Reportedatate Reading vorliegen.
Hier nochmal ein List, das Phänomen tritt nur auf, wenn mehrere Rollläden gleichzeitig gesteuert werden. Wahrscheinlich kommt der Aktor nicht zur Zentrale durch (zu viel Funkverkehr?).
Internals:
CFGFN
DEF c72e3103 17
IODev ZWDongle_Fibaro
LASTInputDev ZWDongle_Fibaro
MSGCNT 743
NAME 1OG.Bad
NR 133
STATE up
TYPE ZWave
ZWDongle_Fibaro_MSGCNT 743
ZWDongle_Fibaro_RAWMSG 000400110a320221440000002e0000
ZWDongle_Fibaro_TIME 2017-07-24 08:03:22
ZWaveSubDevice no
homeId c72e3103
isWakeUp
lastMsgSent 1500874200.2512
nodeIdHex 11
READINGS:
2017-02-11 16:35:10 CMD ZW_APPLICATION_UPDATE
2017-06-16 10:30:05 UNPARSED SENSOR_BINARY 06300504220660
2017-05-25 19:36:23 assocGroup_1 Max 16 Nodes ZWDongle_Fibaro
2017-05-25 19:36:23 assocGroup_2 Max 16 Nodes
2017-05-25 19:36:24 assocGroup_3 Max 1 Nodes ZWDongle_Fibaro
2017-05-25 19:36:23 assocGroups 3
2017-07-24 08:03:22 energy 0.46 kWh
2017-02-11 16:35:25 model FIBARO System FGR222 Roller Shutter Controller 2
2017-02-11 16:35:25 modelConfig fibaro/fgr222.xml
2017-02-11 16:35:25 modelId 010f-0302-1000
2017-06-05 15:18:38 neighborUpdate done
2017-05-29 21:45:41 position 35
2017-07-24 07:30:15 power 0.0 W
2017-06-05 02:07:35 protection Local: unprotected RF: unprotected
2017-07-23 21:42:29 reportedState dim 35
2017-07-24 07:30:00 state on
2017-07-24 07:30:01 timeToAck 1.409
2017-07-24 07:30:01 transmit OK
Tippe auf zu viel Funkverkehr und damit einhergehende Telegrammverluste, Wiederholungen. Sieht man normalerweise im verbose 5 Log von ZWDongle (zumindest die Indizien). timeToAck deutet auch darauf hin.
Reduziere zunächst Funknachrichten durch Löschen der vermutlich unnötigen Assoziation mit Assogroup 1. Damit hast Du schon einmal weniger Nachrichten.
Wenn es dann noch nicht funktioniert, zum gleichzeitigen Schalten structure mit erhöhtem async_delay nutzen.
Gruß, Christian
Zitat von: krikan am 24 Juli 2017, 08:45:14
Tippe auf zu viel Funkverkehr und damit einhergehende Telegrammverluste, Wiederholungen. Sieht man normalerweise im verbose 5 Log von ZWDongle (zumindest die Indizien). timeToAck deutet auch darauf hin.
Reduziere zunächst Funknachrichten durch Löschen der vermutlich unnötigen Assoziation mit Assogroup 1. Damit hast Du schon einmal weniger Nachrichten.
Gruß, Christian
Hi Christian,
die associationen mit Gruppe 1 sind tatsächlich nicht nötig. Mir war nicht bewusst in wie fern das den Funkverkehr belastet.
Mit associationdel
<gruppe, in meinem Fall die 1> <NodeID des devices was bisher eingetragen ist> kurz gesagt:
set attr associationDel 1 15sollte ich doch den Controller aus der Gruppe 1 entfernen können?
wenn ich anschließend mit get associationall abfrage, ist der controller allerdings immernoch in der Gruppe 1 zu sehen.
Mir ist nicht so ganz bewusst, ob ich nun die NodeID in Hex oder dezimal eingeben muss. Ich habe beides ohne Erfolg probiert.
Zitat von: krikan am 24 Juli 2017, 08:45:14
Wenn es dann noch nicht funktioniert, zum gleichzeitigen Schalten structure mit erhöhtem async_delay nutzen.
Was genau kann man unter async_delay verstehen? Heißt das zumindest, dass das senden von Zwave befehlen zu mehreren Aktoren aus einem structure anders behandelt wird? Sprich weniger Funklast erzeugt?
Schon mal vielen Dank!
Gruß,
Fixel
Zitat von: Fixel2012 am 24 Juli 2017, 10:26:14
die associationen mit Gruppe 1 sind tatsächlich nicht nötig. Mir war nicht bewusst in wie fern das den Funkverkehr belastet.
Dadurch verschickt der Aktor zusätzlich alle Nachrichten der Assogroup 1 an den Controller. Sollte unnötig sein, da diese Infos, wenn auch unter Umständen über andere Command Classes- bereits über Assogroup 3 kommen. Ob und wann jetzt tatsächlich beim FGRM Nachrichten über Assogroup 1 verschickt werden, habe ich nicht kontrolliert. Unnötige Assoziationen mit dem Controller mag ich einfach nicht, da die eine Problemursache sein können. ;)
ZitatMit associationdel <gruppe, in meinem Fall die 1> <NodeID des devices was bisher eingetragen ist> sollte ich doch den Controller aus der Gruppe 1 entfernen können?
set <device> associationDel 1 <ZWDongleDeviceDecimalId>sollte funktionieren.
Zitatwenn ich anschließend mit get associationall abfrage, ist der controller allerdings immernoch in der Gruppe 1 zu sehen.
Dann hat etwas nicht funktioniert.
Zitat
Mir ist nicht so ganz bewusst, ob ich nun die NodeID in Hex oder dezimal eingeben muss. Ich habe beides ohne Erfolg probiert.
Eigentlich sollte es überall Dezimal sein.
ZitatWas genau kann man unter async_delay verstehen? Heißt das zumindest, dass das senden von Zwave befehlen zu mehreren Aktoren aus einem structure anders behandelt wird? Sprich weniger Funklast erzeugt?
Baut eine zusätzliche Pause beim Versenden der Befehle an die einzelnen Aktoren ein. Kannst Du auch mit sleep-Kontrukten erreichen. structure ist aber mMn "schöner".
Zitat von: krikan am 24 Juli 2017, 10:46:04
Dann hat etwas nicht funktioniert.Eigentlich sollte es überall Dezimal sein.
Hier ein list, ich sehe nur die NodeID in Hex:
Internals:
CFGFN
CallbackNr 0
Clients :ZWave:
DEF /dev/serial/by-id/usb-0658_0200-if00@115200
DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
FD 17
MaxSendRetries 3
NAME ZWDongle_Fibaro
NR 119
PARTIAL
RAWMSG 000400050a32022144000000400000
ReadTime 1500887301.91916
STATE Initialized
SendRetries 0
SendTime 1500885672.88049
TYPE ZWDongle
WaitForAck 0
ZWDongle_Fibaro_MSGCNT 15270
ZWDongle_Fibaro_TIME 2017-07-24 11:08:21
homeId c72e3103
nodeIdHex 15
nrNAck 0
MatchList:
1:ZWave .*
Zitat von: Fixel2012 am 24 Juli 2017, 11:18:36
Hier ein list, ich sehe nur die NodeID in Hex:
Ich meinte eigentlich die Nummern, die Du in den Befehlen angeben musst.
Das ZWDongle-Device enthält im Gegensatz zu den ZWave-Devices in den Internals nur den Hexwert, den Du umrechnen darfst.
Also 15hex=21dec.
Gerade getestet:
Die Aufnahme des Controllers in Assogroup 1 führt beim Schalten des FGRM über "set <device> dim %" nicht zu zusätzlichen Nachrichten. Also ist das hier nicht problemrelevant.
Wenn Du die Assoziation aber nicht brauchst, würde ich löschen. :)
Zitat von: krikan am 24 Juli 2017, 12:28:41
Gerade getestet:
Die Aufnahme des Controllers in Assogroup 1 führt beim Schalten des FGRM über "set <device> dim %" nicht zusätzlichen Nachrichten. Also ist das hier nicht problemrelevant.
Wenn Du die Assoziation aber nicht brauchst, würde ich löschen. :)
öhh, wollte gerade schreiben, dass ich alle gelöscht habe und nun mal schauen ob es besser läuft ;D
Dann muss ich wohl entweder ein structure einsetzen oder ein paar sleeps einbauen. Sleep würde ich vorziehen, ist einfach einfacher, auf die schnelle ::)
Wie viele und wie lange sollen die sleeps sein? reichen da 0,5 sek und das jeweils zwischen den set commands?
Nochmals danke auch für das testen meines Problems!
ZitatDann muss ich wohl entweder ein structure einsetzen oder ein paar sleeps einbauen.
Ja, wenn die Annahme zutrifft, dass zu viel Funkverkehr mit Telegrammverlust das Problem ist und keine besseren Ideen kommen....
ZitatSleep würde ich vorziehen, ist einfach einfacher, auf die schnelle ::) Wie viele und wie lange sollen die sleeps sein? reichen da 0,5 sek und das jeweils zwischen den set commands?
Kommt darauf an und kann ich nicht pauschal beantworten. Tippe auf zu wenig 8)
Mache doch einmal ein verbose 5 Log und schaue, ob es ein System bei eventuellen Retransmits und ähnlichem gibt. Dann würde ich mit verschiedenen Werten experimentieren. Vielleicht genügt es auch schon, die Aktoren in 2 Gruppen zu packen und nur dazwischen ein sleep einzubauen.
Am sichersten ist es bestimmt zwischen jeden Schaltbefehl für einen einzelnen Aktors eine längere Pause von x Sekunden per sleep/async_delay zu setzen, aber ob Du das willst!? So könntest Du es zumindest sicherer auf Kollisionen und Telegrammverluste zurückführen, wenn es dann problemlos funktioniert.
ZitatreportedState dim 35 2017-07-22 21:43:56
state on 2017-07-23 10:30:00
Normaler Vorgang:
- in FHEM wird set ausgeloest, state wird gesetzt.
- Geraet meldet ACK, und den neuen Zustand. Fals dieser Zustand in FHEM als state-Event gemeldet wird, dann wird auch reportedState gesetzt.
In deinem Fall hat state einen neueren Zeitstempel als reportedState. Ich vermute, dass FHEM die Zustandsmeldung vom Geraet fuer den letzten "set" nicht empfangen hat.
Zitat von: rudolfkoenig am 24 Juli 2017, 14:57:16
Normaler Vorgang:
- in FHEM wird set ausgeloest, state wird gesetzt.
- Geraet meldet ACK, und den neuen Zustand. Fals dieser Zustand in FHEM als state-Event gemeldet wird, dann wird auch reportedState gesetzt.
In deinem Fall hat state einen neueren Zeitstempel als reportedState. Ich vermute, dass FHEM die Zustandsmeldung vom Geraet fuer den letzten "set" nicht empfangen hat.
Das vermute ich auch weiterhin!
Hallo,
habe ein ähnliches Problem mit zwei FGD211-Dimmern. Wenn ich ihn am schalter bediene wird reportedState korrekt gesetzt. Wenn ich ihn aus FHEM schalte, wird reportedState nicht verändert.
Habe die Assoziationen auch schon verändert - ohne Erfolg.
Hier das Listing:
Internals: DEF db46f49f 14 IODev ZWDongle_0 (http://192.168.188.30:8083/fhem?detail=ZWDongle_0) LASTInputDev ZWDongle_0 (http://192.168.188.30:8083/fhem?detail=ZWDongle_0) MSGCNT 101 NAME Licht_SZO_Decke (http://192.168.188.30:8083/fhem?detail=Licht_SZO_Decke) NR 403 STATE dim 1 TYPE ZWave ZWDongle_0_MSGCNT 101 ZWDongle_0_RAWMSG 0004000e06850303010001 ZWDongle_0_TIME 2017-08-15 10:19:30 ZWaveSubDevice no homeId db46f49f isWakeUp lastMsgSent 1502785170.80055 nodeIdHex 0e .vclasses: ASSOCIATION 2 CONFIGURATION 1 FIRMWARE_UPDATE_MD 1 MANUFACTURER_SPECIFIC 1 MULTI_CHANNEL_ASSOCIATION 2 POWERLEVEL 1 SCENE_ACTIVATION 1 SWITCH_ALL 1 SWITCH_MULTILEVEL 1 VERSION 1 READINGS: 2017-06-16 20:22:23 CMD ZW_APPLICATION_UPDATE 2017-07-12 22:44:10 UNPARSED APPLICATION_STATUS 03220702 2017-08-15 10:19:30 assocGroup_1 Max 5 Nodes ZWDongle_0 (http://192.168.188.30:8083/fhem?detail=ZWDongle_0) 2017-08-15 10:19:30 assocGroup_2 Max 5 Nodes 2017-08-15 10:19:30 assocGroup_3 Max 1 Nodes ZWDongle_0 (http://192.168.188.30:8083/fhem?detail=ZWDongle_0) 2017-08-15 10:19:30 assocGroups 3 2017-08-15 10:19:09 config3WaySwitch Disable 2017-08-15 10:19:09 configADVANCEDImpulseLength 110 2017-08-15 10:19:09 configActiveFlashingAlarmTime 600 2017-08-15 10:19:09 configAlarm ALARMFLASHINGDeviceWillTurnONAnd3 2017-08-15 10:19:09 configChangeOnOffBiStableKeys Disable 2017-08-15 10:19:10 configControlKey2Behaviour FrameGETIsSend1 2017-08-15 10:19:10 configDimmingStepAtAutomaticControl 1 2017-08-15 10:19:10 configDimmingStepAtManualControl 1 2017-08-15 10:19:10 configDoubleClickOption EnableDoubleClick 2017-08-15 10:19:10 configEnableDisableALLONOFF ALLONActiveALLOFFActive 2017-08-15 10:19:11 configInputsButtonSwitchConfiguration MonoStableInputButton 2017-08-15 10:19:12 configMaximumDimmerLevelControl 99 2017-08-15 10:19:13 configMinimumDimmerLevelControl 1 2017-01-17 20:42:08 configSavingStateBeforePowerFaillure StateSavedAtPowerFailureAll1 2017-08-15 10:19:14 configSavingStateBeforePowerFailure StateSavedAtPowerFailureAll1 2017-08-15 10:19:15 configSceneActivationFunctionality FunctionalityDeactivated 2017-08-15 10:19:16 configSeparationOfAssociationSending6 MapStatusToAllDevicesInGroup10 2017-08-15 10:19:18 configSynchronizingLightLevelFor18 Enable 2017-08-15 10:19:19 configTimeOfAUTOMATICMovingBetweenThe10 2 2017-08-15 10:19:20 configTimeOfMANUALLYMovingBetweenThe9 5 2017-08-15 10:19:21 configUpdatingTheDimmingLevelWithout40 1 2017-08-14 11:15:50 model FIBARO System FGD211 Universal Dimmer 500W 2017-08-14 11:15:50 modelConfig fibaro/fgd211.xml 2017-08-14 11:15:50 modelId 010f-0100-100a 2017-08-14 13:37:45 powerlvl current 0 remain 0 2017-08-14 13:37:57 powerlvlTest node 1 status 0 frameAck 0 2017-08-15 08:22:23 reportedState off 2017-08-15 10:18:22 state dim 1 2017-08-15 10:19:30 timeToAck 0.074 2017-08-15 10:19:30 transmit OK Attributes: IODev ZWDongle_0 (http://192.168.188.30:8083/fhem?detail=ZWDongle_0) alias Schlafzimmer oben classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION SWITCH_MULTILEVEL FIRMWARE_UPDATE_MD SWITCH_ALL POWERLEVEL MARK SWITCH_MULTILEVEL SCENE_ACTIVATION devStateIcon dim.0:light_light@green:on off:light_light@green:on dim..:light_light_dim_00@red dim.1.:light_light_dim_10@red dim.2.:light_light_dim_20@red dim.3.:light_light_dim_30@red dim.4.:light_light_dim_40@red dim.5.:light_light_dim_50@red dim.6.:light_light_dim_60@red dim.7.:light_light_dim_70@red dim.8.:light_light_dim_80@red dim.9.:light_light_dim_90@red dim.99:light_light_dim_100@red:off group Beleuchtung room Aktoren vclasses ASSOCIATION:2 CONFIGURATION:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 SCENE_ACTIVATION:1 SWITCH_ALL:1 SWITCH_MULTILEVEL:1 VERSION:1 webCmd dim
Gruß
Thomas
Hi,
ich habe seit einigen Tagen ebenfalls das Problem, dass reportedState nicht aktualisiert wird. Ich setze momentan UZB Stick mit der aktuellsten FW (Vers:5 Rev:22, Z-Wave 4.61 STATIC_CONTROLLER) ein. Als Rollo-Aktoren setze ich die "FIBARO System FGRM222 Roller Shutter Controller 2" in der Version "Lib 3 Prot 3.52 App 25.25" ein.
Ich nutze reportedState um daraus die aktuelle Position abzuleiten um damit bspw. zu prüfen, ob der Rollo unten oder oben ist. Dadurch muss ich die Befehle zum Öffnen/Schließen nur bei Bedarf absetzen.
Die Funktion "GetRolloPositionAsValue" dient zur Umrechnung der Position in einen dezimalen Wert (also ohne Prefix "dim" und gemappten State-Werten wie "zu/off"). Damit kann ich dann bspw. auch die Icons etc. umschalten und selbst-definiertes Reading "statePosition" für jeden Aktor zu setzen: userReadings statePosition { GetRolloPositionAsValue($name); }
Die Funktion "WriteLogMessage" schreibt nur Texte ins Logfile.
sub GetRolloPositionAsValue($)
{
my ($deviceName) = @_;
my $t1 = ReadingsVal($deviceName,"reportedState","0");
WriteLogMessage("GetRolloPositionAsValue for device $deviceName, reportedState returns: $t1");
if(index($t1,"dim") >=0 )
{
my @valueTmp = split(" ", $t1);
return $valueTmp[1];
}
else
{
return 0;
}
}
Das ganze läuft timer-gesteuert, dabei werden einzelne Aktoren mit einem Delay von 2 Sekunden gesteuert umd evtl. Queue Probleme im Netz zu umgehen. Leider wird der reportedState nicht immer aktualisiert, STATE selbst dagegen schon (ist auch klar, weil man diesen durch das Absetzen des Commandos selbst setzt...). Im Log sieht man im Fehlerfall folgenden Traffic, wenn das Rollo hochgefahren wird (also open). Bei Herunterfahren prüfe ich dann auf den reportedState und da dieser "off" (also "0") ist, passiert nichts - Rollo bleibt über Nach geöffnet:
2017.11.27 08:00:20.123 5: exec at command tmp_time10
2017.11.27 08:00:20.124 5: Cmd: >set zw_DG_Bad_Rollo dim 99<
2017.11.27 08:00:20.128 3: ZWave set zw_DG_Bad_Rollo dim 99
2017.11.27 08:00:20.129 5: ZWDongle_Write 001312032601632512 (dad62400)
2017.11.27 08:00:20.129 5: SW: 010a00131203260163251284
2017.11.27 08:00:20.133 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:20.134 5: Starting notify loop for zw_DG_Bad_Rollo, 2 event(s), first is dim 99
2017.11.27 08:00:20.146 5: End notify loop for zw_DG_Bad_Rollo
2017.11.27 08:00:20.148 5: ACK received, WaitForAck=>2 for 010a00131203260163251284
2017.11.27 08:00:20.148 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.11.27 08:00:20.149 5: SW: 06
2017.11.27 08:00:20.151 5: ZWDongle_0: dispatch 011301
2017.11.27 08:00:20.195 4: ZWDongle_Read ZWDongle_0: rcvd 00131200 (request ZW_SEND_DATA), sending ACK
2017.11.27 08:00:20.195 5: SW: 06
2017.11.27 08:00:20.196 5: device ack reveived, removing 010a00131203260163251284 from dongle sendstack
2017.11.27 08:00:20.197 5: ZWDongle_0: dispatch 00131200
2017.11.27 08:00:20.197 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:12
2017.11.27 08:00:20.197 4: ZWDongle_0 transmit OK for CB 12, target zw_DG_Bad_Rollo
2017.11.27 08:00:20.198 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:20.200 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:21.453 4: ZWDongle_Read ZWDongle_0: rcvd 0004001206310504220347a700 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.11.27 08:00:21.453 5: SW: 06
2017.11.27 08:00:21.454 5: ZWDongle_0: dispatch 0004001206310504220347a700
2017.11.27 08:00:21.455 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:06310504220347a700 CB:00
2017.11.27 08:00:21.457 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:00:21.458 5: Starting notify loop for zw_DG_Bad_Rollo, 2 event(s), first is power: 83.9 W
2017.11.27 08:00:21.463 5: End notify loop for zw_DG_Bad_Rollo
...
2017.11.27 08:00:55.432 4: ZWDongle_Read ZWDongle_0: rcvd 0004001306310504220000b600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.11.27 08:00:55.432 5: SW: 06
2017.11.27 08:00:55.434 5: ZWDongle_0: dispatch 0004001306310504220000b600
2017.11.27 08:00:55.435 4: CMD:APPLICATION_COMMAND_HANDLER ID:13 ARG:06310504220000b600 CB:00
2017.11.27 08:00:55.438 1: GetRolloPositionAsValue for device zw_DG_DZ_Rollo_DFL, reportedState returns: off
2017.11.27 08:00:55.440 5: Starting notify loop for zw_DG_DZ_Rollo_DFL, 2 event(s), first is power: 0.0 W
2017.11.27 08:00:55.450 5: End notify loop for zw_DG_DZ_Rollo_DFL
...
2017.11.27 08:01:05.330 4: ZWDongle_Read ZWDongle_0: rcvd 0004001206310504220000b900 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.11.27 08:01:05.331 5: SW: 06
2017.11.27 08:01:05.333 5: ZWDongle_0: dispatch 0004001206310504220000b900
2017.11.27 08:01:05.333 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:06310504220000b900 CB:00
2017.11.27 08:01:05.337 1: GetRolloPositionAsValue for device zw_DG_Bad_Rollo, reportedState returns: off
2017.11.27 08:01:05.339 5: Starting notify loop for zw_DG_Bad_Rollo, 2 event(s), first is power: 0.0 W
2017.11.27 08:01:05.349 5: End notify loop for zw_DG_Bad_Rollo
Kann man sich auf den reportedState überhaupt verlassen? Gibt es eine Möglichkeit zu erkennen (wenn möglich per Perl-Funktion), ob der reportedState gesetzt wurde, bzw. empfangen wurde? Dass die Readings sich unterschieden kann man prüfen, aber woher weiß man, was richtig ist? Kann man das über das Datum vom Reading machen?
Alternative wäre man schaltet die Aktoren immer auf/ab, unabhängig von deren Position, aber das ist ganz so elegant und erzeugt unnötigen Traffic ;)
Danke schon mal im Voraus für Hilfe!
LG
2017.11.27 08:00:20.129 5: SW: 010a00131203260163251284
-> Daten ueber USB/Seriell rausgeschickt, SWITCH_MULTILEVEL set 99 an nodeId x12
2017.11.27 08:00:20.148 5: ACK received, WaitForAck=>2 for 010a00131203260163251284
-> Controller hat Empfang der Daten bestaetigt.
2017.11.27 08:00:20.148 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
-> Controller hat die Daten per Funk versendet
2017.11.27 08:00:20.197 5: ZWDongle_0: dispatch 00131200
-> Gegenstelle hat den Empfang der Daten bestaetigt
2017.11.27 08:00:21.455 4: CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:06310504220347a700 CB:00
-> SENSOR_MULTILEVEL power von nodeId x12
...
Einen Fehler sehe ich nicht, die Gegenstelle hat kein status gemeldet.
Entweder, weil es nicht kann, es nicht konfiguriert ist (Association + Config) oder weil es unterwegs verloren ist. Da ich das Geraet nicht kennen, sind die ersten beiden Faelle hypothetisch.
Als Geraeteentwickler muesste ich auch ueberlegen, wann ich welchen Status melde, so ganz klar ist die Sache nicht.
ZitatGibt es eine Möglichkeit zu erkennen (wenn möglich per Perl-Funktion), ob der reportedState gesetzt wurde, bzw. empfangen wurde?
reportedState ist ein state, was vom Geraet kommt. State gibt es z.Zt. fuer die Klassen SWITCH_BINARY, SWITCH_MULTILEVEL und SENSOR_BINARY. D.h. ob man ueberhaupt reportedState kriegt, haengt von den unterstuetzten Klassen ab. Danach gibt es die Huerden "Firmware im Geraet kann status senden", Geraetekonfiguration, "Geraet sendet _immer_ status", und Paketverlust.
Ok, dann kommt wohl nur der Paketverlust als Ursache in Frage. Alle anderen Punkte kann ich ausschließen (Associations, SWITCH_MULTILEVEL ist ebenfalls vorhanden), abgesehen davon funktioniert es bei den meisten Aktoren gleichen Typs ohne Probleme.
Danke für die Analyse!
ZitatAlle anderen Punkte kann ich ausschließen
Fuer den Punkt "Geraet sendet _immer_ status" habe ich so meinen Zweifel, dafuer muesste man die Firmware kennen. Selbst als Firmware-Autor wuerde ich das nicht ausschliessen :)