Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessung

Begonnen von Emil, 13 März 2013, 11:22:35

Vorheriges Thema - Nächstes Thema

ext23

@ohweh: Doch ich hab noch ein RFM rumliegen, nie benutzt. Könnte ich schnell auf meinem STK 500 oder Steckbrett oder so zusammenfrickelt mit einem AVR aber ehrlich gesagt habe ich gerade kein Zeit dazu weil ich noch ein neues RGB Board bastel für die PanStamps... Daher wollte ich mir mal den fertiges USB Stick da bestelle den ihr hier vorgeschlagen habt. Werd ich dann morgen mal bestellen. Dann kann es losgehen mit "spielen" ;-)

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ohweh

Hey,

die AskSin-Idee find ich gut. Ich hab die Tage auch schon nach Gehäusen gesucht, aber bin nicht fündig geworden. Dachte ich wär zu doof. Aber ich scheine ja nicht allein zu sein.

Klar, mach mal, ich schau mir die Sourcen an. Was ich auf die Kette kriege, mache ich. Und anderer Kram muss dann ggf. bis nach Deinem (und Andre's) Urlaub warten. Apropos Urlaub: Habt ihr mal nach Ü-Wagen-Verleih gegoogelt? Ihr könntet Eure Frauen fahren lassen und es Euch hinten mit ner Kiste Bier gemütlich machen *lach*

fh168

Hallo,

ich habe mir auch die Steckdose gekauft. Kam heute schon an, kurz auseinandergeschraubt und ein paar Fotos gemacht. Ebenfalls habe ich ich mir den JeeLink V3 868Mhz bestellt. Ich werde dann - wenn alles klappt - darüber bloggen.

Frage: Kann man (später) auch die Steckdose / Stromzähler mit dem CUL steuern?

Klasse Thema, macht weiter so!

LG
/robin
Hue, Lacrosse, PCA301, MySensors, V 1.67 CUL 868 V3.4, Lacrosse-WLAN-Gateway, Tasmota RF-

ohweh

Robin, Daniel,

na dann dauert das bei Euch ja noch bis Anfang der Woche. Ist nicht so verkehrt, dann hab ich noch das WE über Zeit an der ersten Version des Sketches was zu basteln. Und weiss, das ihr dann testen könnt, super!

Wegen dem CUL: So wie ich Andre verstehe, wird er das mit einem PanStamp versuchen zu realisieren. Für einen CUL hat sich bisher keiner eingefunden. Die Frage ist aber, ob das mit dem CUL denn überhaupt Sinn macht? Ist doch die teuerste aller Lösungen (verglichen mit PanStamp und JeeNode). Und Du musst schon einen extra dafür abstellen...

/Oliver

justme1968

auf dem panstamp kann im prinzip der gleichen sketch laufen wie auf dem jeenode. 'nur' der rf teil ist anders. der cul ist komplett andere hardware und nicht kompatibel. also nicht nur teurer sondern auch (viel) mehr aufwand.

wie hoch der aufwand für den rf teil bei einem panstamp wäre weiss ich nicht. dazu kann trilu sicher etwas sagen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ext23

Naja für den Busware CUL spricht natürlich, dass den schon jeder, naja jeder nicht das ist übertrieben aber zumindest viele haben. Das sogar in mehrfacher Ausführung. Ich hab auch 3: CSM, CUL und ein nachgebauten CUL (im übrigen auch nicht teurer als ein Panstamp ;-))

Ist halt immer so eine Sache wenn man dann zig Interfaces an einem Rechner hat. Aber gut für mich kann ich nur sagen, mir ist es egal. Ich bin schon froh wenn sich jemand die Arbeit macht da was zu basteln, da pass ich mich dann auch. Naja und ob so ein CUL nun 80 Euro, oder ein panstamp 20 oder ein JeeNode 20 ... Das wird ja nun niemanden umbringen. Ist eben ein teures Hobby, aber das sind die meißten Hobbys ;-)

So ich werd mir jetzt mal so ein Teil bestellen, kommt ja aus Holland wenn ich das richtig sehe, schauen wir mal wann der gelbe Weihnachtsmann kommt ^^

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

trilu

Ich möchte ja niemanden entmutigen, aber das mit dem CUL wird so einfach nicht gehen. Der CUL basiert auf einem cc1100 Chip. Die Funksteckdose basiert auf einem Hope Chip. Der Hope hat ein festes Sync Word, zumindest ein Byte von den Zwei im RF12B. Das heisst, man müsste das Syncword im CUL umbiegen.
Dann kommen wir zum Funksetup. Die Frequenzen werden per Register gesetzt, blöderweise kocht hier jeder seine eigene Suppe. Zwei Funkchips von unterschiedlichen Herstellern werden nie genau zusammen passen, was sich zumindest in der Reichweite bemerkbar macht.

Wichtigster Aspekt, es gibt keinen Grund. Wir reden hier von einer bidirektionalen Kommunikation. Selbst wenn man dem CUL das Protokoll bei bringt, dann kann er nur die Steckdosen steuern. Wenn man ihn nur zeitweise umschaltet, verliert man die Strommessung der Steckdosen.

Finanzieller Aspekt, ein JeeLink kostet 35 Euro in einem Gehäuse, der CUL das Doppelte.


justme1968

es nützt ja nichts einen cul zu haben wenn er schon in betrieb ist. wenn die rf parameter anders sind als bei fs20 oder hm (was sie ziemlich sicher sind) kannst du ja nicht den vorhandenen cul verwenden.

ich hab gerade 2 culs und 2 panstamps in betrieb und daneben noch zwei panstamps zum experimentieren. wenn da noch der jeelink dazu kommt schaut es mehr nach igel als nach schreibtisch aus :). vom hmlan und der hue bridge ganz zu schweigen.

aber das schöne an fhem ist ja das sich die systeme alle vertragen und und man immer den aktor/sensor aussuchen kann der am besten passt.

ich dachte auch holland. der versand ist aber scheinbar aus england.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

ZitatHab schon mal wegen RSSI geschaut. Sieht schlecht aus. Geht zwar, aber soweit ich gelesen habe, ist das RSSI (und DRSSI) Signal auf dem RFM12 unzuverlässig und zeigt oftmals Müll an. Deswegen sind einige schon hingegangen und haben sich ne Leitung vom ARSSI Pin des Moduls auf nen Analogen Eingang gelegt, das scheint offenbar zuverlässig und gut zu funktionieren. Vielleicht kann da nochmal jemand nach googlen der von der Materie noch ein bisschen mehr versteht?

Aus eigener Erfahrung: das RSSI auf dem RFM12B funktioniert schon recht gut. Die ARSSI Leitung zum GPIO war (zusammen mit einer Anpassung eines Kondensators) ein Hardwarehack um mit dem RFM12B besser Pulsmodulation empfangen zu können.

Das (d)RSSI Signal ist einfach relativ träge, was aber im Sinn einer Empfangsstärkeanzeige auch Sinn macht weil kurze Schwankungen aus-gemittelt werden.

viele Grüße
Jörg

justme1968

die steckdosen sind tatsächlich doch noch gekommen heute. fühlen sich besser an als erwartet. aber der jeelink ist noch irgendwo in der luft :( also nix mit beschäftigiung falls es regnen...
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ext23

Vor allem interessant das sie schreiben "This service does not have tracking or insurance." Ich würde das ja nun nicht so anpreisen, da kommen einige auch auf dumme Gedanken ...

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ohweh

Moin ;-)

Wollt mich mal kurz melden, bin noch da. Mein Urlaub ist zuende, dadurch die Freizeit etwas knapp. Soll aber nicht heissen, dass ich das hier nicht fertig machen möchte (ganz im Gegenteil), sondern dass ich bei den Postings vielleicht ein wenig träge werde.

Nur mal kurz wg. der JeeLinks: Der Entwickler/Mastermind Jean-Claude Whippler konzentriert sich mittlerweile ganz auf Fortentwicklung, die Fertigung und Vertrieb wird von zwei Brüdern aus England gemacht. Hab mich bei meiner ersten Bestellung auch etwas gewundert... Geht aber alles recht schnell, die Sendungen sind i.d.R. max. drei Tage unterwegs. Schön an "no tracking/insurance" ist, dass die Sendung dann im Briefkasten liegt. Sobald die Sendung einen gewissen Umfang überschreitet, wird nämlich mit TrackingID+Insurance gesendet, und dann muss der Empfang quittiert werden. Bzw. ihr zur Post laufen wenn ihr nicht da wart ;-)

Bzgl. PanStamps: Auf der Webseite von denen sehe ich zwar die Produkte, der Shop selbst ist aber (aktuell?) leer, d.h. man kann weder bestellen, noch sieht man Preise. Aber danke, ist ja mittlerweile beantwortet, ~20 Euro... Echt fair.

@Jörg: Ich habe bisher immer gedacht, dass der Tausch des Kondensators + Leitung zum analogen Port ausschliesslich der Verbesserung des OOK-Empfangs diente. Die "zusätzliche Leitung" haben einige aber unabhängig von OOK gelegt um den tatsächlichen analogen RSSI Pegel auslesen zu können. Weil das digitale auslesen wohl nur ein Bit zurückliefert (RSSI über/unter einstellbarem Schwellwert). D.h. das geht auch anders? Und da kommt dann ein aussagekräftiger Wert rüber?

Ich mach mich jetzt mal wieder ans Werk und bastele an dem Sketch. Bis später.

/Oliver

herrmannj

ZitatIch habe bisher immer gedacht, dass der Tausch des Kondensators + Leitung zum analogen Port ausschliesslich der Verbesserung des OOK-Empfangs diente.

Ja genau. Weil der dRSSI eben mit Verzögerung kippt ist er bei OOK (Pulse) nicht zuverlässig und außerdem vom Abstand (besser Feldstärke) zum Sender abhängig. Der dRSSI lässt sich (wenn ich micht recht erinnere) in 3dB Schritten einstellen.

Der geänderte C am aRSSI macht den aRSSI schneller, damit sind die gemessenen OOK Pulse genauer (wenn der AGPIO auf die richtige Schwelle gestellt wird).

Den absoluten RSSI Wert digital auszulesen geht meines Wissens nach nicht.

viele Grüße
Jörg
 

ohweh

Hallo Jörg,

super Erklärung, danke! Da ist mir einiges noch klarer geworden.

Nun stellt sich mir ne Frage: Wir haben es ja hier mit mehreren Sendern/Empfängern zu tun. Kann ich den dRSSI-Schwellwert denn innerhalb der Übertragung eines einzelnen Paketes schnell genug nachjustieren um auf einen aussagekröftigen Wert zu kommen? Oder muss man sich da quasi rantasten in dem man sich die Werte der letzten Übertragung(en) je Transmitter merkt?

Gruss

Oliver

ohweh

Moin,

es ist soweit. Hab ne erste Version des Sketches fertig. Man kann da sicherlich noch einiges besser gestaltet (vereinfachen, mehr in die Lib auslagern, usw.), aber mir geht's erstmal um die Grundfunktionalität.

Es gibt ein paar kleine Dinge die ihr tun müsst:

1.) Beim Start des Sketches wird automatisch die Config aus dem EEPROM ausgelesen. Da steht natürlich erstmal nur Quatsch drin (weil ja noch keine Config abgelegt wurde, ihr habt ja den JeeLink gerade erst ausgepackt). Also müsst ihr folgendes machen: Einmal in der seriellen Konsole den Befehlt "0c" absetzen (steht für "fill" Config... hab ich bei Trilus AskSin Sketch abgekupfert ;-), anschliessend das Kommando "2c" absetzen (für "save" config).

2.) Was ihr jetzt tun müsst hängt davon ab, ob ihr eine Anzeigeeinheit habt, oder auch nicht (siehe 2a und 2b).

2a.) Wer eine Anzeigeeinheit besitzt, sollte die Steckdosen erst mit seiner Anzeigeeinheit pairen (d.h. der JeeLink sollte NICHT angesteckt sein). Das hat was mit Kanal-Wahl zu tun. Wenn ihr das getan habt, müsst ihr den JeeLink (der aber bitte initialisiert sein muss, siehe Punkt 1.) nur anstecken. Dann einmal auf der Anzeige-Einheit alle bereits gelernten Dosen einmal anwählen. All die von der Anzeigeeinheit gelernten Pakete werden vom JeeLink gelesen, und die Rückantworten ausgewertet. Und die Konfiguration der Kanäle dann 1:1 ins EEPROM übernommen. Fortan könnt ihr die Steckdosen sowohl mit der Anzeigeeinheit, als auch mit dem JeeLink abfragen und schalten.

2b.) Wer keine Anzeigeeinheit besitzt, muss nur den JeeLink anstecken. Dann an der Dose den "Pairing"-Modus aktivieren (Knopf solange gedrückt halten, bis die LED zu blinken beginnt), den Rest erledigt der JeeLink. Er wertet das ankommende Pairing-Paket aus und schickt eine Pairing-Antwort. Also nicht wundern wenn es nur einmal an der Steckdose blinkt ;-) Dabei wird die angelernte Steckdose automatisch auf den nächsten freien Platz der Config gelegt (bei der ersten also auf "1").

3.) Sobald mindestens eine Dose "angelernt" wurde, könnt ihr Euch mit "l" die Device list anzeigen lassen. Da stehen dann auch die zuletzt gemeldeten Werte drin (Stromverbrauch), sowie die Anzahl der Retries usw. usf. Graphisch nicht schön aufbereitet, aber das ganze ist ja auch nicht dafür konzipiert, die Anzeigeeinheit zu ersetzen, sondern z.B. FHEM die Auswertung und Steuerung zu ermöglichen.

4.) Polling wird automatisch gemacht, z.Z. sind 30 Sekunden eingestellt (erstmal nicht konfigurierbar). Weil es Leute geben könnte, die VIELE Dosen haben, wird das Polling zudem zeitlich etwas gestreckt (0-3 Sekunden), um nach dem Zufallsprinzip eine möglichst gleichmässige Verteilung der ausgesendeten Pakete über die Zeit zu haben (wir wollen doch nicht alle 30 Sekunden das Band über die zugelassenen 1% je Sender hinaus beanspruchen, gell? ;-)

5.) Zu den Kommandos selbst:
- "1p" würde das erste Device der Device List "pollen". "3p" wäre demnach das dritte Device.
- "1d" disabled das erste Device, schaltet es also aus
- "1e" enabled das erste Device, schaltet es an
- Senden geht mit "0,1,2,3,4,5,6,7,8,9,s". Dabei stehen die Zahlen 0-9 für die INTs, die den jeweiligen Wert an dieser Stelle des Paketes repräsentieren. Das abschliessende "s" bedeutet, der ganze Mist soll gesendet werden. Die Paket-Länge ist immer 10 Byte! Um die Checksumme müsst ihr Euch NICHT kümmern, das macht der Sketch.

6.) Noch was wegen der "24" am Anfang. Brauche ich gerade für mich hier (ich hab mehrere Empfänger, und muss die Herkunft der Pakete später bestimmen können), könnt ihr bei Bedarf also getrost "wegoptimieren". Die "24" gehört auch nicht an den Anfang eines zu sendenen Pakets. Jack lebt trotzdem ;-)

7.) Für den Fall, dass ihr mit Roh-Daten spielen wollt, dann schaut Euch das Posting von "Kleiner" nochmal an, er hat den Aufbau des Protokolls beschrieben (danke nochmal, SUPER Arbeit!!!).

Viel Spass!

/Oliver

>>>>>

EDIT: Test-Version gelöscht, bitte nehmt die neueste.