Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessung

[ohweh]

Hey,

sorry, bin spaet dran, kleiner Zwischenfall im Job, daher nur auf die Schnelle...

- Es gibt keiner sichtbare Beschränkungen bzgl. der Kanäle, ich hab am Wochenende mal testweise Kanal 16, 32 und 64 probiert, kein Problem. Ich schätz mal das geht bis 255 hoch... oder auch nur 212. Ich werd's noch genauer ausprobieren.

- Es ist auch kein Problem mehrere Steckdosen auf denselben Kanal zu pairen. Gut, die Anzeigeeinheit käm damit nicht klar, aber rein theroetisch könnten sämtliche Dosen auf demselben Kanal laufen. Könnte wichtig werden, wenn jemand plant mehrere Anzeigeeinheit einzusetzen (um nicht dieselben Dosen, sondern je Anzeigeeinheit unterschiedlich zu steueren).

@Andre: Ich füttere Dich morgen früh mit Log-Output und ein paar Antworten. Lass uns dann mal weiterschauen... Bzgl. des automatischen Pairens wg. des Nachbars: Ganz starkes Argument! Hab ich gar nicht dran gedacht...

Gruss

/Oliver

[ohweh]

Morgähn :)

@Andre: Ich versuch jetzt mal Deine Fragen zu beantworten...

1.) Bgzl. "...automatische pairen sollte abschaltbar sein...":
Klar, wäre zu machen... aber wer paired dann? FHEM (durch Übergabe eine SendStrings)? Oder schaltet man den Pairing-Modus kurzfristig auf dem JeeLink ein? Ich wär für die JeeLink-Methode, weil
a.) das Pairing Timing-Kritisch ist. Es kommen im Pairing-Mode zwar 30 Requests rein, aber die können nicht zu einer beliebigen Zeit beantwortet werden, sondern nur in einem schmalen Zeitfenster direkt nach einem Request. Kommt die Antwort zu schnell oder langsam, dann wertet die Dose den Request nicht aus.
b.) das Device ja auch in die Config+EEPROM übernommen werden muss. Dies ist wiederum wichtig, damit der Dose auch Anfragen geschickt werden.

2.) Bzgl. "...man z.b. aus reichweiten gründen mehr als einen enpfänger hat/braucht...":
Yepp, richtig, kann ich Dir nur zustimmen! M.E. ist das Coole an dem Auto-Modus, dass nur ein JeeLink das Pairing-Wettrennen gewinnen kann :)
a.) Ein JeeLink ist der Verlierer. Dieser kennt das neue Device jetzt ebenfalls, aber ggf. mit einem anderen Kanal. Also wird er versuchen zu "pollen", kriegt aber keine Antwort. Was nicht schlimm ist, denn dafür gibt's b.)
b.) Der Gewinner pollt ebenfalls, und die Dose wird darauf antworten. Weil der Sketch darauf ausgelegt ist sich jedes Paket anzuschauen, und sowohl neue DeviceIDs selbst lernt, als auch Kanäle bereits bekannter Devices abgleicht und ggf. Kanalinformationen überschreibt, sollte der Verlierer maximal 1-2 Pakete ins Nirvana schicken müssen bevor er die Antwort der Dose an den Gewinner "sieht". Der Verlierer wertet die Antwort aus, merkt dass sein Kanal in der Config falsch ist, und überschreibt diesen. Und hat ab sofort die richtigen Informationen. Find ich schick :)

3.) Bzgl. "...probleme machen wenn der nachbar auch welche von den steckdosen hat...":
Scheee****e, daran hab ich nicht gedacht! Ich hab alles mögliche veranstaltet, damit der JeeLink selbst lernt. Damit er sowohl alleine, als auch im Zusammenspiel mit mehreren Empfängern und auch (unflexiblen) Anzeigeeinheiten leben kann. Aber an den Nachbarn hab ich jetzt nicht gedacht... Man kann jetzt natürlich sagen "mir ist mein Nachbar egal", aber der könnte ja auch nen JeeLink haben :) Und schon wird ein Bumerang draus. Mist, ehrlich, ich hab noch keine Idee wie man das Problem elegant löst.

4.) Bzgl. "...in den raw messages sollten beim senden/empfangen kommas oder leerzeichen sein":
Keinen Trenner zwischen den Bytes? Wär aber mächtig unbequem und hätte einige Konsequenzen...
a.) Beim Empfang kann man auf HEX umschalten. Dort könnte man (rein theoretisch) auch den Trenner weglassen. Ist man im INT modus, braucht man den Trenner, um das Ende eines Bytes zu erkennen. Desweiteren werte ich die Pakete ja nicht nur maschinell aus, sondern schaue da mitunter auch visuell drauf. Und gerade wenn ich mit dem Auge draufschaue, finde ich es wichtig einen optischen Anhaltspunkt zu haben. Zudem können in der Ausgabe auch "defekte Pakete" enthalten sein (ist an-/abschaltbar und wird in die Config übernommen). Da möchte ich schon sehen wollen, ob es sich um ein reguläres Paket handelt welches es aufgrund von Empfangsproblemen nicht geschafft hat, oder ob's ein "fremdes" Paket ist.
b.) Zum senden braucht der Sketch INTs. Liegt daran, dass der Input Parser eine x-beliebige Zahl als "value", und einen x-beliebigen Buchstaben als "kommando" ansieht. Hat den Vorteil, dass während man noch von der seriellen Sch(n)ittstelle liest, man bereits mit der Verarbeitung beginnen kann (in den Buffer füllen, ggf. kann sogar schon die CRC Berechnung triggern, usw. Weil INTs aber 1-3 Stellen lang sein können, muss es auch irgendeinen Trenner geben. Dieses Konstrukt jetzt in etwas anderes umzubauen (z.B. Hex), würde bedeuten man müsste alles umbauen. Und erst auf eine komplett seriell übermittelte Zeile warten bevor man mit der Verarbeitung beginnen kann. Den Trenner z.B. durch ein Leerzeichen zu wechseln, wär aber gar kein Problem.
c.) nochmal wg. des Übergabeformates: Was gefällt Dir denn daran nicht? Eher kosmetisch? Oder irgendein Problemchen auf FHEM Seite dass ich noch nicht verstehe? Auch wenn ich in b.) beschrieben habe wie's aktuell umgesetzt ist, heisst es ja nicht dass man es nicht mit etwas Aufwand ändern kann. Ich versteh nur den tieferen Sinn noch nicht...

Ich weiss, ich hab noch nicht alle Fragen beantwortet. Muss jetzt trotzdem erstmal zur Arbeit :) Melde mich heut mittag nochmal.

Gruss

/Oliver

[justme1968]

moin moin

- vorschlag zum pairen: so wie bei homematic. der jeelink macht das pairen, bekommt aber ein kommando um es ein und aus zu schalten. am besten mit einem zeit parameter um es für x sekunden zu aktivieren.

- damit wäre das pairen bei mehr als einem jeelink auch kein problem. es ist dann normalerweise nur bei einem aktiviert. hast du das mit dem mehrere jeelinks sind gleichzeitig im pairing modus so schon probiert? es klingt klasse wenn es so einfach wäre aber ich fürchte es gibt auch noch den fall das sich beide pairing anfragen so in die quere kommen das am ende keine mehr durch geht. das waere auch gelöst wenn man das pairen nur bei einem jeelink aktiviert.

- der nachbar wird ruckzuck unkritisch wenn das pairen nicht dauernd aktiv ist.

- das mit dem mit lernen des zweiten jeelink ist gut und solte so sein. das wird aber nur funktionieren wenn zur kommunikation nur die device is verwendet wird und nicht die laufende nummer. stell dir vor: du hast zwei jeelinks. der eine ist mit zwei dosen gepaired. 1 und 2. der andere nur mit einer. 1. beide kenne die jeweils die dosen des anderen nicht weil die räumliche anordnung so ist das nur einer jeelink jeweils nahe genug an den dosen ist. jetzt kommt eine vierte dose in der mitte dazu und sie wird an den  jeelink mit nur einer dose gepaired. der ander kann aber mithören. -> die laufende nummer der neuen dose wäre für beide jeelinks eine andere. und für den einen gibt es sogar einen konflikt.

- es gibt in fhem einen duplikats check zum automatischen erkennen von nachrichten des gleichen device die über unterschiedliche rf modems empfangen wurden. das geht nur wenn das device eindeutig ist. d.h. am besten die uid.

- verwendet die anzeigeeinheit wirklich das eine kanalbyte um die dosen zu nummerieren oder haben dort alle dosen und die anzeigeeinheit den selben kanal? das würde ich eigentlich logischer finden und 'gruppen' ermöglichen die sich nicht 'sehen' müssen.

- zum format: das auslesen der nachrichten ist in fhem string basiert. nicht zeichen basiert. d.h. ohne overhead ist es aus am einfachsten wenn ich die teile der adresse oder der verbrauchswerte nicht erst wieder zusammen setzen muss. einen string ohne leerzeichen liefern auch alle anderen er modems. wenn es dir um die menschenlesbarkeit geht wäre es eigentlich viel besser das leerzeichen nicht überall sondern nur zwischen nachrichtenteilen einzubauen. als z.b. vor und nach der 3 byte adresse oder vor dem 2 byte verbrauchswerten. also etwa so:

Code Auswählen Erweitern

TX: AAAAAA 2DD4 01 04 07F892 00 AAAAAAAA 7152 AAAAAA

RX: 01 04 07F892 00 0000 0000 0E9F
RX: 01 05 07F892 01 AAAAAAAA 774A
den int mode würde ich aus fhem heraus nicht verwenden. da ist mir die formatierung egal.

gruss
  andre

[ohweh]

Hey,

ich liefere Dir das Sitzungsprotokoll heute Abend mal nach, war gestern einfach zu spät :) Denke dann wird auch einiges noch ein bisschen klarer. Dann sollten wir ein paar der Fragen nochmal anhand von Beispielen diskutieren.

- Pairing Modus "für X Sekunden aktiv" ist machbar. Geb Dir Recht, vermutlich der einzig sinnvolle.
- Wenn mehrere JeeLinks und eine Dose "in der Mitte" existiert, dann würde die Dose in der Mitte auch von beiden gepollt. Würde ich aber erstmal so "hinnehmen", und ggf. später mal als ToDo ans Ende der Liste setzen.
- Die Kanalnummer ist für die Anzeigeeinheit leider nicht egal. Du hast acht Plätze, und gemäss dem Platz gibt die Anzeigeeinheit der Dose den Kanal vor. Der Dose ist der Kanal aber wurscht, d.h. alle Dosen könnten auf demselben Kanal funken.
- Der Raw-SendString an den JeeLink beinhaltet NICHT die Platznummer des Devices, sondern Kanal + DeviceId. Muss so sein, aldiweil der JeeLink das Device vielleicht nicht kennt? Könnte dann der Fall sein, wenn wir auch den Lern-Modus abschalten möchten. Kanal+DeviceId sind aber auf jeden Fall FHEM bekannt, denn die Info ist vorher entweder über einen JeeLink reingekommen, oder aber wird "definiert" (könnte ja sein dass wir später auch das Pairing "vorgeben" wollen...). Versuche gerade alle Eventualitäten für später abzudecken :)
- Zusätzlich zum Raw-SendString könnte ich noch ein weiteres Kommando einbauen, was das Senden an eine DeviceId erlaubt (sofern sie dem JeeLink bekannt ist).
- Die Ausgabe greife ich nachher nochmal auf... Ich muss Dir zwei Beispiele dazu zeigen. Ist aber so wie vorgeschlagen leicht machbar, am besten konfigurierbar (Mode: 1=FHEM, 2=Rest-der-Welt).
- Die Konfigurationsmethode FHEM- und "THEO"-Mode könnte auch folgendes beinhalten: Wenn FHEM, dann verhalte Dich in weiten Teilen auf einen Schlag so, wie vorgegeben. Und im THEO-Mode eben nicht, dann kann alles separat konfiguriert werden.
- ich hab immer noch ein Problem mit Deinem Raw-SendString. Wenn da keine Kommandos drin stehen (so wie das bei der INT-Folge ist: also 1,4,07,12,72,00,00,00,s, wie soll ich dann beides (FHEM + manuell bedienbare GUI) bewerkstelligen? Hätte zur Folge, dass das Ding zwar von FHEM aus gut bedienbar ist, aber Du kannst halt nicht mal eben "manuell" was tun (ohne dieselbe "Kryptik" zu beherrschen).
- "Versions"-Kommando fehlt ebenfalls noch. Da würde dann nicht nur eine Sketch-ID zzgl. Versionsnummer, sondern auch die aktuelle Sketch-Configuration zurückkommen. Ich schick später mal ein Beispiel.
- "Device-Config" gibt's schon (Beispiel schicke ich später noch). Da geht es dann auch ausschliesslich um die Devices, und keine anderen Informationen (sodass man da nichts auseinanderdröseln muss).

Sorry, viele Worte... Ich glaub es wird viel klarer, wenn ich nachher ein paar Protokoll-Auszüge schicke.

Gruss

/Oliver

[justme1968]

ja. ich denke die beispiele wären seh hilfreich und es kann gut sein das wir in manchem noch aneinander vorbei reden. ich hatte bis jetzt weder die dosen in betrieb noch meinen jeelink in der hand :)

mit device id habe ich (hoffentlich fast immer :) die drei byte uid aus dem protokoll gemeint. wenn es irgendwie geht würde ich von und zu fhem gerne alles damit abwickeln. die ist hoffentlich auch jeelink übergreifend eindeutig.

die kanalnummer, laufende nummer, du vor allem in verbindung mit der anzeige einheit wichtig ist brauche ich nach meinem bisherigen verständniss nicht wirklich und die sorgt eher für verwirrung weil sie nicht eindeutig (vor allem nicht jeelink übergreifend) ist und sich z.b. beim neu pairen auch ändern kann.

das mehrfach pollen könnte man zum teil verhindern wenn der jeelink merkt das eine antwort von einer dose kommt die er nicht angefordert hat.

ach ja: noch was zu pollen. wie wäre es wenn man das intervall für jede dose getrennt einstellen könnte?

gruss
  andre

[ohweh]

Ja, schade, wär schon schön wenn Du jetzt nicht nur in Gedanken spielen könntest :)

@Daniel, Robin: Habt ihr Euren JeeLink denn schon gekriegt? Bin mal gespannt auf Eure ersten Tests.

[fh168]

Hallo ohweh,

meine Steckdose kam innerhalb 24h, der JeeLink ist noch nicht eingetrudelt.

LG
Robin

[justme1968]

ich hoffe wenn ich die logs habe kann ich ein bischen mehr als nur in gedanken spielen :)

zumindest kann ich was zusammen bauen das jemand anders mal testen kann. initialisieren müsste schon gehen :).

gruss
  andre

[ohweh]

Moin Andre,

wenn Du Zeit und Lust hast, dann schau mal in Deine PM. Hab Dir ganz viel Log-Material geschickt.

Gruss

Oliver

[justme1968]

die beispiele sind klasse. ich hab aus lauter langeweile schon mal einen jeenode dummy gebaut. wenn ich den mit deinen logs füttere kann ich das alles ins fhem modul einbauen.

die offenen punkte von oben sollten wir dann weiter diskutieren wenn ich mir alles angeschaut habe. zumindest den teil der sich ohne hardware klären lässt.

heute ist zwar sonne :) aber ich denke mal es gibt dann auch bald etwas aus fhem heraus zu testen.

gruss
  andre

[ohweh]

Hey,

Du hast wieder Post :) Neue Protokolle, und ein paar geplante Änderungen die schonmal ein Teil Deiner Wünsche abdecken.

/Oliver

[ohweh]

Ich glaube ich bin eben auf ein kleines "Problem" gestossen. Hab nen anderweitig in Gebrauch befindlichen JeeLink mit dem PcaSerial-Sketch betankt. Und beim Laden der Quatsch-Config aus dem EEPROM (wird ja automatisch gemacht) kriegte ich dann nur ohne ende Müll-Zeichen auf der seriellen Schnittstelle, und konnte keine Kommandos mehr absetzen. Es hat geholfen im Sketch

- in der Funktion setup() die Zeile "loadConfig()" gegen "fillConfig()" zu tauschen
- dann einmal den JeeLink starten und mit "2C" die Config ins EEPROM bügeln
- anschliessend die Zeile wieder zurückändern (in loadConfig).

Kann ein Einzelfall gewesen sein, aber kann theoretisch auch anderen blühen. Ich hab leider erst am Wochenende wieder ein bisschen mehr Zeit um mich darum zu kümmern, deshalb müsst ihr Euch einmalig so behelfen. Am Wochenende werde ich dann

- entweder eine Zeitverzögerung einbauen (nach dem starten des Sketches hat man 10 Sekunden Zeit bevor die Config automatisch geladen wird)
- oder aber ich baue ne komplette CRC-Routine mit allem drum und dran ein...

Letzteres ist sicherlich der saubere Weg, aber auch aufwendiger. Kann sein dass ich auf die Schnelle den ersten Weg wähle, damit ich mich um die anderen, dringlichen Wünsche kümmern kann. Und dann ein wenig später um den zweiten, sauberen Schritt.

Gruss

/Oliver

[justme1968]

kurzes update nach erstem spielen mit einem 'fake' jeenode und einem teil von olivers log files:

(siehe Anhang / see attachement)

(siehe Anhang / see attachement)

die pca301 devices werden per autocreate angelegt sobald sie gepaired werden bzw. die erste nachricht empfangen wird.

gruss
  andre

[ohweh]

Super, ich bin begeistert! Warum verbrät mein Laptop eigentlich 46 Watt? Ach soo, stimmt ja, ist ein (mittlerweile nicht mehr taufrischer) i7-Quad :)

[ext23]

Mhh mein JeeLink ist noch nicht da, ich hoffe ich habe heute was im Kasten ...

/Daniel