Autor Thema: Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessung  (Gelesen 303581 mal)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18609
danke. eine ausrede weniger :)

aber ich fürchte ich komme trozdem nicht dazu.

ist das individuelle intervall wirklich so wichtig?
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3125
Bei meinem Vorhaben geht es weniger um das individuelle Intervall, sondern dass das nicht in die culfw gehört(meine Meinung). Ohne polling senden die Dosen aber nie(außer bei manueller Betätigung der Dose den Schaltbefehl).  :'(

Zitat
aber ich fürchte ich komme trozdem nicht dazu.
Ist doch OK. Ich machs dann ggfs., da ich ja auch aktueller in der Materie und dem Modul drin bin.
Grüße Markus
RPi3/2 Stretch-STV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18609
doch. ich finde das gehört in dir firmware :). deshalb ist es ja auch im jeelink sketch.

dar sketch muss sich auch darum kümmern das die dosen nicht alle gleichzeitig abgefragt werden oder das nicht abgefragt wird wenn eine dose gerade geschaltet wird und die antwort abgeholt wird. die ganzen zeiten dazu werden zufällig verschoben.

das gehör alles nicht auf die fhem ebene.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3125
Zitat
doch. ich finde das gehört in dir firmware :). deshalb ist es ja auch im jeelink sketch.
Von einem theoretischen Standpunkt aus mag das stimmen. Wenn ich mir vorhandene device-Modul-Beziehungen angucke aber eher nicht:
- devices ohne Eingriffsmöglichkeit in die firmware;fast alle Kaufdevices(u.a. Stromzähler, AV-Geräte....); Polling macht (in der Regel)das Modul
- CUL/S'duino/RFXTRX vs. Jeelink: 1 Mehrzweck-Transceiver für viiieeele Protokolle(dann wird dann aber der Speicher knapp) vs. Ein-Protokoll -Transceiver(individuell aber teuer; da gehen einem dann die USB-Anschlüsse aus)

Ist dann aber so ziemlich OT. Die Masse der Pros und Cons müssten wir dann im Development Forum austauschen. ;)
RPi3/2 Stretch-STV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-CUL868-FS20A4-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty-Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)

Offline Wernieman

  • Hero Member
  • *****
  • Beiträge: 5070
Wobei es eigentlich was "gans tiefes ist" und damit eigentlich auf die unterste Ebene gehört ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html