CUL(culfw) und PCA301

[arthur_dent_2015]

Hallo Markus,
erst mal alles gute fürs neue Jahr!
Dann, Danke für die Blumen... Aber, wie gesagt, ich komme aus der Mainframe Welt. Hab mir da das programmieren, damals noch in CLIST, später in REXX, selbst beigebracht. Das funktioniert zwar (meistens), aber ein Programmierer würde wohl, angesichts des Spaghetti Codes, die Hände überm Kopf zusammenschlagen Und meine C Kenntnisse gehen mal gerade so weit dass ich vielleicht ein einfaches Script lesen, interpretieren und ggf. für mich adaptieren kann, mehr aber auch nicht. Vom technischen Hintergrundwissen (Elektronik und Funk) und der mangelnden Zeit mal ganz abgesehen...
Ich habe meine Jeelinks jetzt so weit im Griff. Der Status wird regelmäßig überprüft und ggf. ein reset gemacht. Nicht schön, funktioniert aber. Trotzdem würde ich sie gerne ablösen. Temperatur und Luftfeuchtigkeit läuft schon parallel über CUL. Wenn jetzt noch der, zur Zeit arbeitslose, vierte Transmitter auf meinem MapleCUL die PCA301 steuern könnte wäre das schon Klasse. Wenn sonst aber niemand an dem Projekt interessiert ist, vergiss es einfach...
Danke für Dein Engagement!
Gruß
Arthur

[KölnSolar]

Hallo Arthur,

Wenn sonst aber niemand an dem Projekt interessiert ist, vergiss es einfach...

nönö 
probier mal die neue Version. Ich hab zwischenzeitlich mit Andre das Doublettenthema diskutiert. Da gibt es wohl noch eine Lücke bei der Konzeption der 2-stufigen Module. Ich glaub aber einen Workaround zu haben.

Wenn die Version funktioniert(natürlich nur Empfang), dann wäre es interessant es mit PCA301-Jeelink und Cul im Parallelbetrieb zu testen. Die Transceiver dann mit verbose=5. Am PCA301-device sollte dabei nichts auffallen. Bei den Transceivern sollte aber immer nur einer die ja gleichzeitig empfangenen Daten verarbeiten(Doublettenfilterung). Und das nach dem Prinzip first come first serve.

Grüße Markus

[arthur_dent_2015]

Hallo Markus,
Du bist ja richtig hartnäckig..  Ich denke dass ich morgen Zeit zum testen finden werde.
Gruß
Arthur

[arthur_dent_2015]

Hallo Markus,
im Anhang wieder fhem.log und device.log. Geschaltet habe ich vom Testsystem on/off/status request über den angeschlossenen nanoCUL und das gleiche noch mal vom Prod System über den dortigen Jeelink. Ich hoffe Du kommst damit weiter. Was mich gewundert hat, beim Start von Fhem

Code Auswählen Erweitern


2019.01.07 15:00:41 1: PCA301_0B9DB4: no I/O device
2019.01.07 15:00:41 3: No I/O device found for PCA301_0B9DB4

Im list sieht das aber völlig okay aus:

Code Auswählen Erweitern


Internals:
   CUL0_MSGCNT 97
   CUL0_RAWMSG OK 24 2 4 11 157 180 0 0 0 0 0 1DFF
   CUL0_TIME  2019-01-07 15:25:58
   DEF        0B9DB4 02
   IODev      CUL0
   LASTInputDev CUL0
   MSGCNT     97
   NAME       PCA301_0B9DB4
   NR         61
   PCA301_lastRcv 2019-01-07 15:25:58
   PCA301_lastSend 2019-01-07 15:10:53
   STATE      off
   TYPE       PCA301
   addr       0B9DB4
   channel    02
   READINGS:
     2019-01-07 15:25:58   consumption     0
     2019-01-07 15:25:58   consumptionTotal 16334598.7499935
     2019-01-07 15:25:58   power           0
     2019-01-07 15:11:41   state           off
Attributes:
   IODev      CUL0
   devStateIcon on:on:toggle off:off:toggle set.*:light_exclamation:off
   room       PCA301
   userReadings consumptionTotal:consumption.* monotonic {ReadingsVal($name,'consumption',0)}
   verbose    5
   webCmd     on:off:toggle:statusRequest


Gruß
Arthur

[KölnSolar]

Geschaltet habe ich vom Testsystem on/off/status request

Ich schrieb doch nur Empfang.
Und ich meinte mit

mit PCA301-Jeelink und Cul im Parallelbetrieb zu testen

mit beiden Sticks am Testsystem.

2019.01.07 15:00:41 1: PCA301_0B9DB4: no I/O device
2019.01.07 15:00:41 3: No I/O device found for PCA301_0B9DB4

Könnte ein Nebeneffekt meiner "Lösung" sein. Aber scheinbar nicht von Bedeutung.
Kannst Du den Test dann noch einmal wiederholen. Hat keine Eile. Ich kämpfe derzeit mit dem DLNARenderer.
Grüße Markus

[arthur_dent_2015]

Ich schrieb doch nur Empfang.

okay, Empfang war ja trotzdem auf dem Testsystem.

Und ich meinte mit  mit beiden Sticks am Testsystem.

Okay, das hatte ich so nicht verstanden. Dazu muss ich das Prod System stoppen und den Jeelink vom Wohnzimmerschrank holen. Mal gucken wann das am besten passt.... Den Jeelink dann auch mit verbose=5 nehme ich an...

Könnte ein Nebeneffekt meiner "Lösung" sein. Aber scheinbar nicht von Bedeutung.

War nur etwas irritierend. Im Zweifelsfall kann man die msgs ja filtern
Gruß
Arthur

[arthur_dent_2015]

und hier die Ergebnisse.
Das heutige Wetter war ideal für den Test

[KölnSolar]

Ich hab mir mal die Logs angeguckt. Gar nicht so einfach das, was mich interessiert, herauszulesen.  Hast Du öfter geschaltet ? Das sind so viele Logeinträge in kürzester Zeit.

Idee: Ich fänd es ja Verschwendung einen CUL nur für die PCA301 abzustellen. Es wird ja nur ab und an geschaltet. Und aktuellen Status kann man mit statusrequest abfragen. Und die Antwort kommt auch flink oder ?
Dann könnte man doch folgende Funktionen entwickeln:
- schalten
  merken des rfmode
  switch in rfmode=nativeRF3
  schalten
  switch to previous rfmode
- Zyklischer Empfang
   - parametrisiertes internaltimer oder simples at *
     Modusswitch wie oben
     anstatt schalten: statusrequest absetzen; receive abwarten(nichts tun) u. per notify in den alten rfmode switchen 
Nachteil:
- während des nativeRF3-mode gehen eingehende Telegramme verloren(bei mir egal)
- Senden aus FHEM geht für devices des "Standard"-mode verloren(nicht so toll, da meine Mischersteuerung per slowRF läuft)
- im Fehlerfall des PCA301 bleibt der CUL im nativeRF3 hängen(ganz schlecht,das muss man zusätzlich über at/notify übersteuern)
- keine events im "gewohnten" Zyklus von den Dosen(so what)

Was denkst Du ?
Markus 

[arthur_dent_2015]

Naja, ich habe zur Zeit 18 von den PCA301 im Einsatz, da fliegt einiges durch den Äther;) geschaltet hab ich nur on/off/toggle/toggle/status request, siehe auch device log.
Manchmal dauert die Antwort schon, liegt wohl an den Empfangsverhältnissen. Ob nun CUL oder Jeelink explizit für ein Protokoll "zuständig" ist, ist, aus meiner Sicht, ziemlich egal. Der SignalDuino hat da, als Mulit, ein Alleinstellungsmerkmal. Ein NanoCUL ist, im Eigenbau, definitiv billiger als ein Jeelink (clone).
Ich schalte viele Geräte verbrauchsabhängig. Da würde ich den von Dir vorgeschlagenen Weg nicht mitgehen wollen. Ich hab ja noch nen arbeitslosen CUL der sich mal um die PCA's kümmern soll. Die Techem, Heizkosten- und Wasserzähler sind ja ähnlich konzipiert, ohne IODev. Bei mir kümmert sich aber auch ein extra dafür freigestellter CUL darum. Soll heißen, wer nur ein, zwei PCA's hat, kann sich sicherlich so eine Mimik aufbauen, wenn es mehr werden verliert man aber irgendwann den Überblick. So lange es keinen Transmitter gibt der mit allen Protokollen umgehen kann, wird man wohl damit leben müssen dass man mehrere davon braucht.

Gruß
Rainer

[KölnSolar]

Da würde ich den von Dir vorgeschlagenen Weg nicht mitgehen wollen.

wer nur ein, zwei PCA's hat,

Ja, es würde dann ja beides gehen. Nur im 2. Fall bedarf es keines 2. CUL. 

So lange es keinen Transmitter gibt der mit allen Protokollen umgehen kann

Das wird es nie geben, weil eben das Modulationsverfahren(Funk) der devices unterschiedlich ist. Es lässt sich nur wie ich beschrieben habe "umgehen": immer wieder den Empfangsmodus ändern. Einfacher verständlich, aber genau derselbe Grund, ist, dass ja auch nur auf einer Frequenz(Frequenzbereich) empfangen werden kann, auch wenn der CC1101-Chip variabel ist. Frequenz ist auch nur ein Parameter des Modulationsverfahrens.

Die Logs guck ich mir mal in Ruhe an. Besser wäre für mich ein etwas längerer Zeitraum ohne jeglichen set-Befehl.
Grüße Markus

[arthur_dent_2015]

Hallo Markus,
im Anhang ein Logauszug über gut 5 Minuten ohne jegliche Schaltaktivitäten.
Gruß
Arthur

[KölnSolar]

Hallo Arthur,
Arnd hat mir 2 Dosen spendiert. 
Bedauerlicherweise senden die gar nichts periodisch. Nur, wenn man sie manuell schaltet und auch dann keine Verbräuche/Leistung. Ich spekuliere, das polling steckt im Jeelink. Kannst Du das verifizieren, also Testumgebung, ohne dass ein Jeelink/PCA301-Station die Dose anfunken kann ? Wir müssten dann für jede Dose ein at anlegen(oder Andre modifiziert die 36_PCA301), sofern ich das Senden hinbekomme.
Grüße Markus

[arthur_dent_2015]

Moin Markus,
sehr merkwürdig, meine senden bei jeder Änderung im power reading, so jedenfalls mein Eindruck. Aber ich unterstütze natürlich gerne  Am Testsystem steckt eh kein Jeelink, sollte also kein Problem sein. Lass mich wissen was ich tun soll. Bin allerdings die Tage auf Dienstreise   
Gruß
Arthur

[RaspiLED]

Hi,
Schaut mal unter
,,Häufiges Polling mit PCA Sketch pcaSerial10.0h" in https://wiki.fhem.de/wiki/PCA301_Funkschaltsteckdose_mit_Energieverbrauchsmessung

Für mich liest sich das so, als ob aktiv vom JeeLink nachgefragt wird und somit dürfte sogar das Produktivsystem keinen Jeelink haben, um im Testsystem nicht zyklisch was zu empfangen, was aus dem Produktivsystem gefordert wird

Brauchst Du auch einen Jeelink zum testen?

Gruß Arnd


Gesendet von iPhone mit Tapatalk

[KölnSolar]

aktiv vom JeeLink nachgefragt wird und somit dürfte sogar das Produktivsystem keinen Jeelink haben, um im Testsystem nicht zyklisch was zu empfangen, was aus dem Produktivsystem gefordert wird

Genau so. 
Ich hatte es im 70-seitigen Thread gefunden. 

Brauchst Du auch einen Jeelink zum testen?

Ich denke nicht. Ich versuche das Polling in der culfw einzubauen. Im Modul ist set...statusrequest implementiert.
Gute Woche
Markus