Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessung

[ext23]

Moin,

nochmal eine Frage zu diesen fertig Modulen die hier verwendet werden (JeeNode). Welches Modul kann man denn da empfehlen? Das nochmale V6 Modul oder gleich das JeeNode USB Teil?

Ich hab zwar ein unbenutzen RFM rumliegen aber ich hab keine Lust mir da jetzt selber ein Platinchen zu löten, abgesehen davon das die am Ende bestimmt etwas großer ausfällt. Daher würde ich mir da einfach mal einen bestellen, klingt ja ganz interessant, und da ich mit dem RFMs noch nicht gearbeitet habe käme mir da so ein Spielzeug ganz gelegen ;-)

Gruß
Daniel

[ohweh]

Hi,

@fh168: Ich glaube wir haben uns da mis(t)verstanden. Ich hab nichts gegen die Revolt-Teile, und es freut mich für Dich, dass Du damit zufrieden bist und sie das tun, was sie sollen. Was ich eigentlich nur ausdrücken wollte war: Diese ganze Dekodierungsprozedur kostet unglaublich viel Zeit. Möchte nicht wissen wie lange "Kleiner" für all die Basis-Informationen inkl. Protokoll-Dekodierung gebraucht hat. Mit Sicherheit war das nicht an einem Tag erledigt... und dann noch all die Zeit, die ich jetzt gebraucht habe. Mit tatkräftiger Unterstützung von Trilu. Und die, die da noch kommt. Was ich damit also zum Ausdruck bringen will ist, dass sich soviel Zeit und Mühe eigentlich nur lohnt, wenn es sich um etwas zukunftsträchtiges handelt. Oder etwas mit einem Alleinstellungsmerkmal. Und letzteres liegt doch hier vor, mir sind kaum Lösungen bekannt die sowohl messen, als auch schalten können. Und die mit einem bidirektionalen Protokoll arbeiten.

Apropos "zukunftsträchtig": Ich finde die Überlegung von Rudolf König bemerkenswert, als er sagte, er sehe die langfristige Verfügbarkeit der PCA 301 nicht unbedingt als gegeben an. Eben weil sie nicht ins ELV FS20/HM Universum passt. Boah, ja, dem kann ich nur zustimmen. Was ist, wenn wir jetzt ne schöne Lösung bauen, und die dann meinen Ansprüchen genügt? Und ich in 3 Monaten Dosen nachordern will, es diese aber plötzlich nicht mehr gibt? Schaut doch mal bei ELV nach dem S300TH... oder wie war das noch gleich mit der EM1000? Gebrauchte EM1000-Steckeradapter gehen mittlerweile für 30-45 Euro bei Ebay über die Theke...

Ich werde dem ganzen Ärger aus dem Weg zu gehen. Sobald sich die PCA Lösung als gut brauchbar erweist, werde ich mich damit eindecken.

@Daniel: Ja, genau das wollte ich damit sagen. Ohne Hardwareseitige Filterung des RF-Moduls biste auf Seite des Hosts ruckzuck überfordert. Das ist dann wie beim Seti-Projekt, da kommen "ein wenig" zuviele Informationen rüber ;-)

Jetzt noch was wegen der JeeNode/JeeLinks... Das ist von der Hardware her nichts anderes als ein Arduino Uno mit RFM12B Modul. Aber in einer besonderen "Bauform", die PINs werden zu "Ports" gruppiert und anders nach aussen geführt als beim Arduino. Das Boardlayout ist zudem anders (lang und schmal).

Es gibt 4 Versionen davon:

1.) JeeNode Micro... Den bitte NICHT nehmen! Ist kein ATMEGA, sondern ein ATTINY84 drauf. Und das hat KEINE serielle Hardwareschnittstelle.

2.) JeeNode v6 Kit - Den bitte auch NICHT nehmen! Denn für die Programmierung und die spätere Ausgabe auf USB-Schnittstelle würde noch ein USB-BUB benötigt. Macht daher für die meisten hier keinen Sinn (ausser für Bastler, die sowieso alles rumliegen haben)...

3.) JeeNode USB - Den KANN man nehmen. Damit kann man auch gut andere Sachen veranstalten, weil da die Hardware PINs nach aussen geführt sind. Wird OHNE Gehäuse geliefert, und die PIN Header muss man selber einlöten (was aber einfach ist).

4.) JeeLink - Den KANN man nehmen. Ist ein JeeNode in einem USB-Stecker-Gehäuse. Hat keine PIN Header die nach aussen geführt sind, hat dafür aber zusätzlichen Flashspeicher. Der JeeLink ist AEG (auspacken, einstecken, geht ;-)).

Also sucht es Euch aus... Seid aber bitte nicht zu voreilig mit der Bestellung, wir haben ja noch nichts fertiges! Es sei denn, ihr wollt schonmal "spielen". Desweiteren müsst ihr Euch darüber im Klaren sein, dass der JeeNode/JeeLink noch programmiert werden muss (über die Arduino IDE). Ist nicht schwer, aber ich will's trotzdem erwähnen, damit hier keine Mis(t)verständnisse aufkommen.

Im übrigen: Ich hab weder was mit ELV zu tun, noch was mit JeeLabs. Wollte ich nur mal erwähnen ;-)

/Oliver

[justme1968]

ich bin begeistert über die schnellen fortschritte bis jetzt.

da ich grosses interesse habe einige dieser steckdosen mit fhem einzusetzen möchte ich dafür natürlich ein fhem modul haben.

hier es stellt jetzt die frage auf welcher ebene die integration stattfinden soll und kann. alle anderen rf devices sind ja zur zeit so an fhem angebunden das zumindest das decodieren der höheren protokoll schichten in fhem passiert. das hätte den vorteil das man potentiell nicht nur einen jeenode/jeelink verwenden kann sondern auch einen cul oder panstamp mit passender firmware. ebenso gibt es in fhem schon ein wenig infrastruktur wie z.b. das erkennen und verwerfen doppelter nachrichten wenn man mehr als einen empfänger verwendet um eine grössere fläche abzudecken oder den sendpool um zu verhindern das mehrere sender gleichzeitig senden.

ist es jetzt schon sinnvoll darüber nach zu denken? dann könnte man auch mit dem fhem modul schon anfangen. ich bin zwar jetzt drei wochen in urlaub würde mir aber direkt schon mal einen jeelink und die steckdosen bestellen um etwas zum spielen zu haben wenn ich zurück bin.

gruss
  andre

[rudolfkoenig]

>  mir sind kaum Lösungen bekannt die sowohl messen, als auch schalten können.
> Und die mit einem bidirektionalen Protokoll arbeiten.

Es fehlt noch: und mit FHEM zusammenarbeiten.

Mir faellt ein: ZWave AN158, Fritz!DECT 200, Fritz!DECT 546e
Billig sind die alle nicht, ich kann mir aber vorstellen, dass sie laenger als die PCA lieferbar sein werden. Will aber niemanden von basteln abhalten, sowas muss man durchgemacht haben :)

[ohweh]

Hi,

bin nur mal über die Fritz!DECT 200 gestolpert, die anderen kannte ich bisher gar nicht. Daher schonmal danke! Die Preise sind tatsächlich nicht übel ;-) Aber stimmt schon, (zumindest) die Fritz-Adapter sollten längerfristig verfügbar sein, bieten also einen gewissen Investitionsschutz.

Wie sähe denn so eine Integration aus? D.h. mit was könnte FHEM umgehen und gut leben? Aktuell wirft der JeeNode Sketch empfangene Pakete in der Notation

OK xx xx xx xx xx xx xx xx xx xx

aus. Je nachdem ob der CRC stimmt oder nicht, fängt die Ausgabe mit "OK" oder mit "?" an. Senden geht auch schon in der Notatation

xx,xx,xx,xx,xx,xx,xx,xx,xx,xx,s

Man kann noch einstellen, ob das gesendete Paket auch über die serielle Schnittstelle geechoed wird, oder nicht.

1.) Kann das in FHEM denn so implementiert werden? Und die Auswertung der Pakete in FHEM erfolgen (die Bedeutung der Bytes ist ja bekannt)?
2.) Kann FHEM das Pairing übernehmen? In dem Fall erscheint der Request auf der seriellen Schnittstelle (in obiger Notatation), und innerhalb von 60 Sekunden muss ein spezielles Antwort-Paket geschickt werden.
3.) Kann FHEM das Polling übernehmen? Die Adapter senden nie selbst (es sei denn, jemand betätigt den Schalter der Dose selbst) oder aktiviert den Pairing-Modus), das muss also irgendwer triggern.

Lautet die Antwort jedes mal "Ja!", dann kann man doch auf FHEM-Seite richtig Gas geben?!?! JeeNode-seitig ist das alles bereits fertig. Oder aber kann schnell angepasst werden (sofern mir jemand sagt wie's denn genehm ist).

/Oliver

[justme1968]

die antwort ist auf jeden fall drei mal ja.

ein fhem modul das das so umsetzt ist im prinzip sehr schnell zu machen. ich mache mich auch gerne dran. kann aber erst in drei wochen. hardware bestelle ich aber schon mal.

wenn bis dahin jemand anders das fhem modul bauen möchte gerne.

als vorschlag: die anderen funk module stellen noch den rssi wert bereit damit man schnell sehen kann ob man sich am reichweiten limit bewegt.

bei den cul modulen ist es glaube ich am ende der nechricht, beim panstamp/swap steht es am anfang.  wenn du auf dem jeenode etwas verleichbares hast wäre es vielleicht gut den noch in die nachricht zu stecken.

bei den anderen modulen gibt es auch keine leerzeichen bzw kommas in den übertragenen strings. das macht das parsen und zusammenbauen etwas einfacher.

wenn man für ok/nicht ok die gleiche anzahl zeichen vorzieht wäre es glaube ich auch einfacher. eventuell braucht man die nachrichten mit falschem crc gar nicht weiter geben sondern nur einen fehler status?

braucht man eigentlich die basisstation für irgendetwas wenn man alles an fhem hängt ?

gruss
  andre

[trilu]

Ich persönlich finde den JeeLink praktischer zum Anschluss an FHEM.
Hat ein schickes Gehäuse und entspricht in der Bauform einem CUL :-)

Vielleicht können wir die Verkaufszahlen durch Integration in FHEM nach oben treiben - dann würde ELV sie auch nicht aus dem Programm nehmen...

Anyway - ich denke wir müssen ein wenig strategisch vorgehen, wie wir die Implementierung machen wollen. Es gibt einige Ebenen der Kommunikation.

Steckdose - sendet nur nach Aufforderung und muss gepaired werden

JeeNode/Link - sollte nach Aufforderung das Pairing übernehmen und auch das Pollen nach Informationen (per Parameter zu setzen)

dann gibts den untersten Kommunikationslayer in FHEM - irgendwas mit 00_ - Hier läuft die Grundsätzliche Schnittstellensteuerung, also Com Port lesen und schreiben

und den etwas höheren Device Layer in FHEM - hier findet die Gerätebeschreibung und solche Dinge statt.

Ich denke damit wissen wir jetzt, was in die JeeNode rein muss :-)

[trilu]

Hups, ein paar Fragen sind ja noch offen :-)

- Sofern keine Anzeige-Einheit vorhanden ist, muss ja irgendwer das Polling übernehmen. Entweder FHEM, oder aber der JeeNode/JeeLink!?!? Ich denken es wär gut, wenn der JeeNode das übernehmen "könnte" (aber per Config her nicht muss). D.h. wir brauchen nen Scheduler der alle x Sekunden bekannte Devices abfragt damit sie Daten zurückliefern
- FHEM Integration?
- Wo speichern wir die Device list? Im Sketch oder im EEPROM des JeeNodes?

Ich fange mal mit der letzten Frage an - am besten im EEprom. Ich würde dazu ein Array erzeugen in dem ich die Liste der Devices verwalte.
Ich werde mal ein Beispiel basteln. So eine Struktur lässt sich dann gut ins EEprom speichern und nach Neustart auch wieder rausholen.

Für den Scheduler lass ich mir auch was einfallen...

[justme1968]

beim design der fhem module würde ich mich an die aufteilung cul/fs20 oder cul/cul_hm und änliche halten. bei panstasmp/swap habe ich es auch so gemacht und das geht sehr gut. also ein modul für den jenode/jeelink und eins für die steckdose.

das pollen optional in den sketch zu verlagern ist vielleicht nicht schlecht. je nach dem wie viel speicher das ding hat könnteman sogar überlegen ob nicht sogar werte gesammelt werden können falls fhem nicht läuft. aber ads ist vielleicht etwas für den zweiten schritt.

ob und wieviel man vom pairing auslagert macht glaube ich nicht wirklich einen unterschied.

kennt eigentlich jemand noch andere devices die mit den gleichen rf parametern arbeiten und gleichzeitig mit dem gleichen jeenode ansprechbar wären?

[justme1968]

ich würde vorschlagen das man für jedes device das polling intervall getrennt setzen kann.

ja. die bekannten devices sollten ins eeprom.

[justme1968]

vorschlag für den scheduler wenn der funkt teil per interrupt läuft (so wäre es bei einem panstamp):

Code Auswählen Erweitern

#define MAX_DEVICES 128

static byte nr_devices;
static unsigned long timeouts[MAX_DEVICES];
void setup()
{
...
  nr_devices = EEPROM.read(...);

  for( int i = 0; i < nr_devices*sizeog(unsigned long); ++i )
    ((char *)timeouts)[i] = EEPROM.read(...)
...
}

bool
isTime(unsigned long &timeMark, unsigned long timeInterval)
{
  if( millis() - timeMark >= timeInterval )
    {  
      timeMark = millis();
      return true;
    }  
 
  return false;
}

static unsigned long times[MAX_DEVICES];
void loop()
{
  for( byte i = 0; i < nr_devices; ++i )
    if( isTime(times[i], timeouts[i] )
      -> device i pollen
}

[trilu]

ich finde so etwas praktischer :-)

typedef struct {
 uint8_t numberDevices;   
 uint32_t devID[128];
 etc...;

} struct_pca301Config;
damit wird der struct container öffentlich

extern struct_pca301Config pca301Config;

und zum laden und speichern dann noch sowas
void saveConfig() {         
 uint8_t len = sizeof(pca301Config);
 uint8_t buf[len];
 memcpy(&buf, &pca301Config, len);
 eeprom_write_block(&buf, (void *) 0, len);
}

void loadConfig() {         
 uint8_t len = sizeof(pca301Config);
 uint8_t buf[len];
 eeprom_read_block(&buf, (void *) 0, len);
 memcpy(&pca301Config, &buf, len);
}

[justme1968]

mir ging es nur um das pollen. das die ganze config in structs sollte und funktionen zum laden und speichern ist doch klar :)

ich würde noch struct pro device spendieren um die id, den timeout zum pollen und was sonst noch nötig ist zusammen zu fassen.

den typedef bei der struct brauchst du in c++ nicht.

im include file das hier:

Code Auswählen Erweitern

struct pca301 {
  byte id[4]
  unsigned long poll_timeout;
  ...
};

extern byte numberDevices;
extern pca301 *devices;

und sketch ein mal das hier:

Code Auswählen Erweitern

pca301 devices[MAX_DEVICES];
byte numberDevices;

wofür ist der extra buffer beim lesen und schreiben des eeprom? das geht doch auch direkt oder nicht?

gruss
  andre

[trilu]

Den buffer hab ich für die serielle console zu debug ausgabe drin.
Ich will ja kontrollieren was ich schreibe und lese ...
Zum pollen fallen mir zwei möglichkeiten ein. Einmal einer timer setzen und innerhalb des timers einen zähler laufen lassen der alle 5 oder 10 minuten feuert.
Oder in der main loop die zeit merken und per differenz verzweigen. Ich habe beide varianten irgendwo schon benutzt, ich such sie dir morgen mal raus....

[justme1968]

ich meinte den buffer im loadConfig und saveConfig. du kopierst aus der struct in einen buffer und dann ins eeprom bzw aus dem eeprom in einen buffer und dann erst in die struct. das geht doch auch ohne den buffer dazwischen.

du musst mir nichts raussuchen. das istTime() und die loop aus meinem beispiel oben würde jedes device mit einem getrennt einstellbaren timeout pollen.