Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessung

[Ton]

Hallo,

Hat jemand eine Ahnung an welches Bauteil diese Fehlmessung liegen könnte?
Ich wurde nämlich lieber eine Lötkolbe in der Hand nehmen und ein Kleinigkeit dazu oder weg löten als die 3 Steckdosen zurück schicken und 18 Wochen auf Ersatz warten... 

Bin leider keine HW Experte aber konnte mich vorstellen das so was typischerweise von eine Kaputte/Falsche Kondensator oder widerstand oder so kommen könnte und eher kein PCA301 SW Problem ist weil es bei 1 von 4 ( in meinem Fall ) tut, und die bestimmt die gleiche SW haben.

Also jemand eine Idee ??

Gruß

   Ton

[herrmannj]

Moin, Moin,

mit dem aktuellen Update sogar deutlich unter 3 Sekunden . Gestern in betrieb genommen, da wars schon recht häufig, aber jetzt nach update will er (jeelink) es wissen

Code Auswählen Erweitern


2013-11-11 16:21:08.689 PCA301 PCA301_0D0301 power: 23.4
2013-11-11 16:21:08.689 PCA301 PCA301_0D0301 consumption: 0.79
2013-11-11 16:21:08.689 PCA301 PCA301_0D0301 consumptionTotal: 0.71
2013-11-11 16:21:09.231 PCA301 PCA301_0D0301 power: 23.4
2013-11-11 16:21:09.231 PCA301 PCA301_0D0301 consumption: 0.79
2013-11-11 16:21:09.231 PCA301 PCA301_0D0301 consumptionTotal: 0.71
2013-11-11 16:21:09.773 PCA301 PCA301_0D0301 power: 23.4
2013-11-11 16:21:09.773 PCA301 PCA301_0D0301 consumption: 0.79
2013-11-11 16:21:09.773 PCA301 PCA301_0D0301 consumptionTotal: 0.71


vg
Jörg

[justme1968]

da muss oliver noch mal nach dem sketch schauen.

gruss
  andre

[justme1968]

ich habe gerade einen fehler bei der intiialisierung des pac301 jeenode gefunden und einen fix eingecheckt.

der fehler hat dazu geführt das unter bestimmten bedinungen eine endlos schleife beim device öffnen passieren konnte.

das führt dann zu dem verhalten mit dem dauerlicht. es hat aber nichts mit dem 3 sekunden pollen zu tun. das hat eine andere ursache die ziemlich sicher im sketch und nicht im fhem modul liegt.

gruss
  andre

[Spiff]

Hi Andre,

ich habe gerade ein Update ausgeführt, seitdem ist der JeeLink sehr wissbegierig. Mit einer Version von vor ein paar Tagen kamen die Nachrichten wirklich "nur" alle 3-4 Sekunden, jetzt sind es mehrere pro Sekunde!
Und: er führt im Eventmonitor jetzt auch meine eine Reserve-Steckdose auf, die gar nicht eingesteckt ist. 

Gruß
Spiff

[justme1968]

die version mit dem fix von oben bekommst du erst morgen im update. wenn du die schon jetzt brauchst musst du sie von hand aus dem svn auschecken.

die endloss schleife führt dazu das der jeelink immer wieder initialisert wird. bei der initialisierung wird die liste aller bekannten steckdosen abgefragt. also jede die schon mal mit dem jeelink gepaired war. da ist dann auch die reserve dose dabei.

gruss
  andre

[Spiff]

Aaah, okay, hat funktioniert.
Jetzt kann ich die Steckdosen nur leider nicht mehr schalten, die Befehle dazu tauchen im Eventlog aber auf.

Code Auswählen Erweitern


2013-11-11 20:09:05 PCA301 xxx power: 72.1
2013-11-11 20:09:05 PCA301 xxx consumption: 3.26
2013-11-11 20:09:05 PCA301 xxx consumptionTotal: 0.8
2013-11-11 20:09:06 PCA301 xxx set-off

Es passiert jedoch nichts.
Kleine Info am Rande: ich habe den JeeLink in der fhem.cfg umbenannt, weil ich gerade einen zweiten installiert habe.

Hast du eine Idee?

Gruß
Spiff

[ph1959de]

@Spiff: hast Du mal die neue Steckdose gelöscht und neu anlegen lassen?
Bei mir wurde eine zusätzliche Steckdose auch erst als "Kanal 04" (war eigentlich am Display PSA301 auf Kanal 02 angelernt) erkannt und ließ sich nicht schalten. Nach dem Löschen hat autocreate die dann neu auf Kanal 02 angelegt und das Schalten (sowie der Rest) hat funktioniert.

(Habe ich auch so im Wiki dokumentiert; die Gründe sind wohl noch unklar? Es gab aber vor einer Weile schon ähnliche Probleme mit neuen Geräten, damals auf Kanal 00).

@Andre (justme1968): ist Dir das bekannt? Kann man bei der Problemeingrenzung noch helfen?

Gruß, Peter

[justme1968]

@Spiff: passt das IODev noch? wenn du mehr als einen jeelink hast musst du drauf achten das jedes pca301 device das richtige IODev gesetzt hat sonst geht das senden nicht.

@ph1959de: nein. das wusste ich noch nicht. ich vermute aber das es am sketch liegt. oliver hat eben geschrieben das er sich das mal anschaut.

wenn es probleme gibt bitte mal global verbose auf 5 setzen und nachschauen was für messages geloggt werden.

gruss
  andre

[ph1959de]

Wenn es probleme gibt bitte mal global verbose auf 5 setzen und nachschauen was für messages geloggt werden.

Hab jetzt leider keine "frischen" PCA301 mehr und mit den schon angelernten tritt das Problem ja nicht auf (ich wüsste jedenfalls nicht, wie ich es provozieren könnte). Aber die gerade bestellten neuen PCAs kommen ja schon bald ... in 18 Wochen  ... dann werde ich an das verbose (hoffentlich noch) denken.

Gruß, Peter

[justme1968]

noch eine idee:

wer hatte alles schon probleme mit einem 'falschen' kanal? ist jemand dabei der *keine* display unit hat?

mein verdacht ist gerade folgender: wenn der jeelink eine neue dose lernt vergibt er den nächsten freien kanal. wenn die display unit die dose lernt vergibt sie natürlich auch einen kanal. sie weiss ja nichts vom jeelink. wenn display unit dann die dose pollt lernt der jeelink den kanal den das display vergeben hat und verwendet diesen statt dem eigenen. in fhem ist das device aber noch mit dem alten kanal angelegt. beim empfangen macht das nichts weil hier nur die device id verwendet wird. nur beim senden ist der kanal wichtig.

gruss
  andre

[ohweh]

Hi ho

Oh man, irgendwie fehlen mir die Email-Benachrichtigungen. Hab nicht mitbekommen, was hier die letzten Tage gelaufen ist, sorry.

Dann lasst mich mal versuchen ein wenig Ordnung ins Chaos zu kriegen...

Bzgl. den 3 Sekunden im Sketch: Das ist nicht das Polling-Intervall, sondern eine zufällig Zeit-Abweichung zwischen 0 und 3 Sekunden... Hintergrund ist, dass wenn der JeeLink "resettet/gebootet" wird, er ja sofort mit dem Polling seiner bereits bekannte Devices beginnt. Das führt natürlich bei vielen Devices erstmal zu einem kleinen RF-Sturm. Um das zu entzerren, wird auf das Standardpolling-Intervall je Device immer diese zufällige Zeitabweichung zuaddiert, sodass sich die Polling-Pakete nach kurzer Zeit besser über die Laufzeit verteilen. Hat man also 30 Sekunden als Poll-Intervall eingestellt, wird das Device zwischen alle 30 bis 33 Sekunden gepollt. Daran rumzuspielen hat also wenig Sinn

Wenn der JeeLink ein Paket empfängt, welches nach einem manuellen Schaltbefehl aussieht, dann wird sofort gepollt um den echten Status zu ermitteln. Das hat bisher (bei der alten Charge) auch geklappt. Vielleicht liegt hier der Hund begraben, weil das Protokoll leicht verändert wurde? Oder die RF-Parameter leicht geändert? Ist schwer zu sagen...

Ich blicke bei den Kommentaren hier gerade nicht so ganz durch. Hat jemand eine PCA aus der neuen Charge, die:

- 0 Watt anzeigt wenn sie unbelastet ist
- aber trotzdem alle 3 Sekunden gepollt wird?

Wenn ja, könnte mir jemand eine solche Dose schicken? Ich würde mir das dann mal direkt im Detail anschauen... Diese neuen Phänome hier sind echt schräg, irgendwas muss sich da geändert haben. Mehr fällt mir gerade leider nicht ein...

Gruss
Oliver

[mele]

noch eine idee:

wer hatte alles schon probleme mit einem 'falschen' kanal? ist jemand dabei der *keine* display unit hat?

mein verdacht ist gerade folgender: wenn der jeelink eine neue dose lernt vergibt er den nächsten freien kanal. wenn die display unit die dose lernt vergibt sie natürlich auch einen kanal. sie weiss ja nichts vom jeelink. wenn display unit dann die dose pollt lernt der jeelink den kanal den das display vergeben hat und verwendet diesen statt dem eigenen. in fhem ist das device aber noch mit dem alten kanal angelegt. beim empfangen macht das nichts weil hier nur die device id verwendet wird. nur beim senden ist der kanal wichtig.

gruss
  andre

Ich habe am Donnerstag 6 Dosen angelernt und habe keine Anzeigeeinheit. Ich musste jede Dose einzeln einmal und nach den Löschen ein zweites Mal anlernen.

VG
Manuel

[Ton]

Hallo,

Habe jetzt den test gemacht und der Jeelink SW so angepasst das im loadConf() nochmal des polling interval hart auf 30 Sekunden gesetzt wird und das deadInterval auf 300, zur Sicherheit weil der war meine ich auch um Faktor 10 zu niedrig.

Habe im pca301.cpp:391 im loadConf() folgendes zugefügt :

Code Auswählen Erweitern

pcaConf.pollIntv   = 300;     // AK : Set polling interval to 30 seconds ( 300 * 1/10th of a second ) default poll interval
pcaConf.deadIntv   = 3000;    // AK : Set polling interval to 300 seconds ( 3000 * 1/10th of a second ) dead device poll retry interval

Und es tut !!!

Vorher, schlecht fall mit 3 bis 4 sec polling :

2013-11-11_07:26:42 dg_IT_PC power: 2.9
2013-11-11_07:26:42 dg_IT_PC consumption: 0.16
2013-11-11_07:26:42 dg_IT_PC consumptionTotal: 0.26
2013-11-11_07:26:47 dg_IT_PC power: 2.4
2013-11-11_07:26:47 dg_IT_PC consumption: 0.16
2013-11-11_07:26:47 dg_IT_PC consumptionTotal: 0.26
2013-11-11_07:26:50 dg_IT_PC power: 2.6
2013-11-11_07:26:50 dg_IT_PC consumption: 0.16
2013-11-11_07:26:50 dg_IT_PC consumptionTotal: 0.26

Nachher, mit etwa 30 Sekunden :

2013-11-11_20:36:00 dg_IT_PC power: 2.6
2013-11-11_20:36:00 dg_IT_PC consumption: 0.22
2013-11-11_20:36:00 dg_IT_PC consumptionTotal: 0.32
2013-11-11_20:36:32 dg_IT_PC power: 2.7
2013-11-11_20:36:32 dg_IT_PC consumption: 0.22
2013-11-11_20:36:32 dg_IT_PC consumptionTotal: 0.32
2013-11-11_20:37:02 dg_IT_PC power: 2.7
2013-11-11_20:37:02 dg_IT_PC consumption: 0.22
2013-11-11_20:37:02 dg_IT_PC consumptionTotal: 0.32

Also sieht gut aus so

Was mir aber ein wenig wundert ist das der 3 Sekunde Jeelink SW schon vom 15 Sept. ist und es bis jetzt noch niemand so richtig aufgefallen scheint das da so viele Messungen kommen die das System und die Luftschnittstelle belasten...  Oder haben sich da im FHEM init werten geändert oder so im letzten Zeit?

Gruß

    Ton

Hier nochmal mein angepasste loadConfig :

Code Auswählen Erweitern

//- load config from EEPROM - returns 1 if valid config was found, otherwise 0
byte loadConf() {
  uint16_t len   = sizeof(pcaConf);
  byte *pPtrByte = (byte*)&pcaConf;        // byte Ptr to pcaConf
  eeprom_crc     = 0;
  eeprom_read_block(&pcaConf, (void *) 0, len);

  for (int i=0; i < (len - 2); i++) {
    eeprom_crc = crc16_pca301_update(eeprom_crc, *pPtrByte);
    pPtrByte++;
  }

  // valid config in EEPROM?
  if (eeprom_crc == pcaConf.crc) {
    // valid config found, reset dynamic settings
    for (int i = 0; i < pcaConf.numDev; i++) {
      pcaConf.pcaDev[i].pNow    = 0;
      pcaConf.pcaDev[i].pTtl    = 0;
      pcaConf.pcaDev[i].nextTX  = 0;
      pcaConf.pcaDev[i].retries = 0;
      pcaConf.pollIntv   = 300;     // AK : Set polling interval to 30 seconds ( 300 * 1/10th of a second ) default poll interval
      pcaConf.deadIntv   = 3000;    // AK : Set polling interval to 300 seconds ( 3000 * 1/10th of a second ) dead device poll retry interval
    }
    return 1;
  } else {
    // invalid crc
    return 0;
  }
}

[ohweh]

Besser hätte ich das nicht erklären können. Genau so läuft das!

noch eine idee:

wer hatte alles schon probleme mit einem 'falschen' kanal? ist jemand dabei der *keine* display unit hat?

mein verdacht ist gerade folgender: wenn der jeelink eine neue dose lernt vergibt er den nächsten freien kanal. wenn die display unit die dose lernt vergibt sie natürlich auch einen kanal. sie weiss ja nichts vom jeelink. wenn display unit dann die dose pollt lernt der jeelink den kanal den das display vergeben hat und verwendet diesen statt dem eigenen. in fhem ist das device aber noch mit dem alten kanal angelegt. beim empfangen macht das nichts weil hier nur die device id verwendet wird. nur beim senden ist der kanal wichtig.

gruss
  andre