Autor Thema: LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino  (Gelesen 285088 mal)

Online Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2701
Dafür gibt es dann ab 1.16 die Möglichkeit, das LGW mit einem SubProzessor zu erweitern (z.B. einem Arduino pro mini)
Wahnsinn, meine Trägheit das endgültige GW bis jetzt noch nicht zusammen zu löten wird auch noch belohnt :)
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline PeMue

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4951
Nunja, das ist ein 3EUR Bauteil und es gibt ja zum Glück ( :) :) ) noch keine Platinen von denen man den 12er wieder runter löten muss.
Habe den Hinweis verstanden: nächste Woche ist Urlaub angesagt, da will ich das Layout fertig machen ;)

Dafür gibt es dann ab 1.16 die Möglichkeit, das LGW mit einem SubProzessor zu erweitern (z.B. einem Arduino pro mini) und an den kann man ja dann einen DHT dranpacken.
Ändert sich dadurch  etwas am Schaltplan?

Gruß PeMue
1x FB7170 (29.04.88) 5.7 1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F)
1x RPi BV2LCDCSM 1.63 5.7 2xMAX HKT, 1xMAX RT, V200KW1
1xFB 7490 (113.06.05) 5.7 1xCUL V3 1.63 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 1xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU 1xRFXtrx 90 1xWT440H 1xCM160 3xTFA30.3150 5xFA21

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
Mit diesem Gateway strebst du die Weltherrschaft an!?  ;D ;D ;D
Nein, lt. Hersteller hat LaCrosse nur eine Reichweite von 100 Metern  ;D ;D

Habe den Hinweis verstanden
Ist schon OK so, wenn jemand einen 12er von der coolen Platine hätte runterlöten müssen, hätte ich ein noch schlechteres Gewissen.
Ich habe die 12er Unterstützung auch nicht explizit ausgebaut, es kann schon sein, dass es noch Szenarien gibt, wo es klappt, nur offiziell ist er nicht mehr drin und ich teste auch nicht mehr mit 12ern.
Gerade der Testaufwand, um alle Kombinationen und Features auch mit dem 12er zu testen und lauffähig zu bekommen, war erheblich.
Die Zeit kann ich sinnvoller in Bugfixes, Verbesserungen und Features investieren.

Ändert sich dadurch etwas am Schaltplan?
Nein, keine Änderung an der Grundplatine, das spielt sich alles auf einer optionalen AddOn-Platine ab, die auf die Pfosten gesteckt wird und SPI, I2C, Reset und Spannung braucht.


Offline Andy89

  • Full Member
  • ***
  • Beiträge: 256
Servus,
ich habe eine Frage zum EC3000. Ich hätte gerne, dass dieser ähnlich wie die PCA301's funktiort, das heißt, dass ich diese um Mitternacht "resetten" kann, damit die consumption zurückgesetzt wird. Wenn ich das Reading manuell auf "0" setze, dann wirds beim nächsten Update der Steckdose wieder mit dem neuen Wert, der kontinuierlich wächst, überschrieben.
Hat dies jemand von euch irgendwie implementiert, oder muss ich wirklich noch ein userReading consumption_today anlegen, damit das klappt?

Zur Zeit habe ich meine EC3000-Steckdosen so integriert:
Internals:
   DEF        7A1E
   EC3000_lastRcv 2016-03-19 19:29:40
   IODev      myJeeLink
   LASTInputDev myJeeLink
   MSGCNT     3142
   NAME       EC3000_1
   NR         334
   STATE      Jetzt 2.7 W, Max 390.8 W, Verbrauch 8.229 kwh
   TYPE       EC3000
   addr       7A1E
   myJeeLink_MSGCNT 3142
   myJeeLink_RAWMSG OK 22 122 30 0 13 25 225 0 13 25 191 0 0 32 37 0 27 15 68 1 0
   myJeeLink_TIME 2016-03-19 19:29:40
   reception  0
   resets     1
   secondsOn  858559
   secondsTotal 858593
   Helper:
     Dblog:
       Consumption:
         Logdb:
           TIME       1458411938.5024
           VALUE      8.229
       Consumptioneuro:
         Logdb:
           TIME       1458411938.5024
           VALUE      2.04
       Consumptionmonth:
         Logdb:
           TIME       1458411938.5024
           VALUE      14.299
       Consumptionmontheuro:
         Logdb:
           TIME       1458411938.5024
           VALUE      3.55
       Consumptiontotal:
         Logdb:
           TIME       1458411938.5024
           VALUE      14.299
       Consumptiontotaleuro:
         Logdb:
           TIME       1458411938.5024
           VALUE      3.55
       Consumptionweek:
         Logdb:
           TIME       1458411938.5024
           VALUE      14.299
       Consumptionweekeuro:
         Logdb:
           TIME       1458411938.5024
           VALUE      3.55
       Consumptionyear:
         Logdb:
           TIME       1458411938.5024
           VALUE      14.299
       Consumptionyeareuro:
         Logdb:
           TIME       1458411938.5024
           VALUE      3.55
       Power:
         Logdb:
           TIME       1458411938.5024
           VALUE      2.8
       Powermax:
         Logdb:
           TIME       1458411938.5024
           VALUE      390.8
       State:
         Logdb:
           TIME       1458411938.5024
           VALUE      on
   Readings:
     2016-03-19 19:29:40   consumption     8.229
     2016-03-19 19:29:40   consumptionEuro 2.04
     2016-03-19 19:25:38   consumptionMonth 14.299
     2016-03-19 19:29:40   consumptionMonthEuro 3.55
     2016-03-19 19:25:38   consumptionTotal 14.299
     2016-03-19 19:29:40   consumptionTotalEuro 3.55
     2016-03-19 19:25:38   consumptionWeek 14.299
     2016-03-19 19:29:40   consumptionWeekEuro 3.55
     2016-03-19 19:25:38   consumptionYear 14.299
     2016-03-19 19:29:40   consumptionYearEuro 3.55
     2016-03-19 00:01:06   consumptionYesterday 7.687
     2016-03-19 00:01:06   consumptionYesterdayEuro 1.91
     2016-03-19 19:29:40   power           2.7
     2016-03-19 19:29:40   powerMax        390.8
     2016-03-19 19:29:40   state           on
Attributes:
   IODev      myJeeLink
   event-min-interval *:300
   genericDeviceType outlet
   room       myJeeLink,z_Homekit
   stateFormat Jetzt power W, Max powerMax W, Verbrauch consumption kwh
   userReadings consumptionTotal:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionWeek:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionMonth:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionYear:consumption monotonic {ReadingsVal($name,'consumption',0)},
consumptionEuro {euroBerechnen(ReadingsVal($name,"consumption","?"))},
consumptionTotalEuro {euroBerechnen(ReadingsVal($name,"consumptionTotal","?"))},
consumptionWeekEuro {euroBerechnen(ReadingsVal($name,"consumptionWeek","?"))},
consumptionMonthEuro {euroBerechnen(ReadingsVal($name,"consumptionMonth","?"))},
consumptionYearEuro {euroBerechnen(ReadingsVal($name,"consumptionYear","?"))}

Danke für eure Hilfe.

Beste Grüße
Andy
FHEM 5.8 auf rPi3 (mit Homebridge); dbLog und FTUI auf DS1813+; AMAD für Fire;
HMLAN > HM-Sen-MDIR-WM55, HM-CC-RT-DN, HM-Sec-RHS,HM-TC-IT-WM-W-EU,ZEL STG RM FFK;
CUL433 > IT, Elro; LGW > PCA301,EC3000,BME280,LaCrosse;
Harmony Hub;Sonos;Onkyo AVR;RGB WLAN Controller;Netatmo;Enigma2;Withings Scale;HUE

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
ich habe eine Frage zum EC3000. Ich hätte gerne, dass dieser ähnlich wie die PCA301's funktiort, das heißt, dass ich diese um Mitternacht "resetten" kann, damit die consumption zurückgesetzt wird.
Die consumption wird in der Dose akkumuiliert und von ihr gesendet. Da man nicht wie bei PCA301 mit ihr reden kann, ist da nichts zu machen.
Das muss man mit einem eigenen Reading lösen oder man müsste im EC3000 Sketch was bauen.

Offline Andy89

  • Full Member
  • ***
  • Beiträge: 256
Die consumption wird in der Dose akkumuiliert und von ihr gesendet. Da man nicht wie bei PCA301 mit ihr reden kann, ist da nichts zu machen.
Das muss man mit einem eigenen Reading lösen oder man müsste im EC3000 Sketch was bauen.
das habe ich mir schon fast gedacht. Dann mach ich das mit einem Reading^^
Danke für die Antwort  :)

Schönes Weekend noch
FHEM 5.8 auf rPi3 (mit Homebridge); dbLog und FTUI auf DS1813+; AMAD für Fire;
HMLAN > HM-Sen-MDIR-WM55, HM-CC-RT-DN, HM-Sec-RHS,HM-TC-IT-WM-W-EU,ZEL STG RM FFK;
CUL433 > IT, Elro; LGW > PCA301,EC3000,BME280,LaCrosse;
Harmony Hub;Sonos;Onkyo AVR;RGB WLAN Controller;Netatmo;Enigma2;Withings Scale;HUE

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
V1.16

RFM12 entfallen
Wie schon angekündigt wird der RFM12 nicht mehr offiziell unterstützt, nur noch der RFM69

Bugfixes
- Wenn WIFI deaktiviert war, wurde trotzdem der AP geöffnet
- PCA301: Habe Maßnahmen gegen die "Phantom-PCAs" getroffen.
Da ich immer zwei bis drei Wochen warten muss, bis bei mir mal eine auftritt, kann ich es
noch nicht zu 100% sagen, ob sie weg sind. Wer mit dieser Version immer noch welche bekommt, bitte melden.

Log im frontend
Siehe auch LogPage.png
Mit "Command" kann man Befehle an das LGW senden. Sie entsprechen dem, was man mit "set myJeeLink raw ..." aus FHEM schicken kann.
Die obere Liste enthält die Daten, die an FHEM übermittelt werden (bzw. würden, wenn sich ein FHEM auf das LGW verbunden hat)
Die untere Liste enthält debug-Informationen. U.A. wird hier der letzte Systemstart aufgezeichnet.
Die verwendete SDK-Version und der letzte Reset-Grund werden ebenfalls ausgegeben

Erweiterungsmöglichkeiten
Das LGW kann nun optional mit verschiedenen Komponenten erweitert werden.
Alle Komponenten werden automatisch erkannt, sofern angeschlossen.
Dazu wird ein SC16IS750 verwendet.
http://www.aliexpress.com/item/1x-Breakout-Board-for-SC16IS750-I2C-SPI-to-UART-IC/1327351219.html?spm=2114.30010308.3.38.HxdznQ&ws_ab_test=searchweb201556_9,searchweb201602_2_10034_507_10020_10001_10002_10017_10010_10005_10011_10006_10021_10003_10004_10022_10009_10008_10018_10019,searchweb201603_6&btsid=97b30f2b-e937-426b-8202-de585dd7ee97
Der SC16IS750 wird per I2C an das LGW angeschlossen und bietet eine serielle Schnittstelle und 8 Digital I/Os
Auf dieser Basis sind momentan folgende Erweiterugen möglich:

Alarmausgabe im LGW
Dazu wird an GPIO7 des SC16IS750 ein Summer angeschlossen.
Falls der Strom von 10mA, den die Ausgänge liefern, nicht reicht, ist noch eine Transistor-Schaltstufe vorzusehen
Ansteuerung über das JeeLink Modul in FHEM:
set myJeeLink211 raw 1,60b   -> beep ... beep ... beep                      60 Sekunden lang
set myJeeLink211 raw 2,300b  -> beep beep ... beep beep ... beep beep      300 Sekunden lang
set myJeeLink211 raw 3,120b  -> beep beep beep ... beep beep beep ...      120 Sekunden lang
set myJeeLink211 raw 0b      -> beep stoppen

Radio #4 und #5
Es können zwei weitere RFM69 angeschlossen werden.
Schaltung siehe GW-Addon-With-Example.png
Radio #4 und #5 sind "vollwertig", sie können also alles, was die bisherigen drei auch können.
   
SubProzessor
An die serielle Schnittstelle des SC16IS750 kann optinal ein Arduino angeschlossen werden (z.B. ein Pro Mini)
Entweder ein 3.3V / 8MHz oder ein 5V / 16MHz, der aber dann auch mit 3.3V betrieben wird.
Wichtig: hier läuft alles mit 3.3V, also bitte nirgends 5V ins Spiel bringen.

Die Firmware kann über das LGW auf den SubProzessor (Voraussetzung: er hat einen Arduino bootloader) geflasht werden.
Dazu wird sie einfach hochgeladen auf <LGW-IP>/ota/addon.hex
Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.
Den Upload kann man z.B. so durchführen:
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex
Der Upload dauert etwas, danach sollte man bei Erfolg vom LGW so ein Protokoll zurückgeschickt bekommen:
Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finished

Mit dem SubProzessor kann man was auch immer an Daten messen, empfangen oder erfinden und sie auf zwei mögliche Arten am LGW abliefern:
KeyValueProtokoll:
Format:  KV <Type> <Address> <Key>=<Value>,<Key>=<Value>,<Key>=<Value>, ...
Example: KV DHT 01 Temperature=21.5,Humidity=62
Das LGW übermittelt die Daten als KVP an FHEM und dort entsteht ein KVP Device, das die Daten darstellt.

LaCrosse:
Format:  LC <Address> T=<Temperature>,H=<Humidity>
Examples: LC 9F T=21.5,H=62
          LC 9F T=21.5
Das LGW setzt die Werte in das LaCrosse Protokoll um (wie z.B. ein TX29DTH) und schickt sie an FHEM
In FHEM entsteht ein LaCrosse Device (autocreate, LaCrossePairForSec ...), als ob es ein LaCrosse Sensor wäre.

Das angehängte LGW-Addon.ino ist ein einfaches Beispiel, das diese Technik veranschaulicht.
Es bindet den geliebten DHT22 an und sendet ihn als LaCrosse-Sensor (über das LGW) an FHEM und es misst die Spannung und sendet sie zusammen mit der UpTime des SubProzessors als KVP

LGW-Addon-With-Example.png ist die Schaltung des kompletten AddOn mit allen aktuell möglichen Optionen.
Der umrandete Bereich "Example" ist das zu LGW-Addon.ino passende Beispiel.

Wer jetzt noch über den Sinn des SubProzessors grübelt: er dient dazu, dass jeder mit einem eigenen Sketch Daten erfassen kann, ohne sich um die ganze Nummer, die das LGW macht (WiFi, Kommunikation mit FHEM, Frontend, OTA, ...), kümmern zu müssen.

Und er ist die Option für Dinge, die man aufgrund des Timings dem LGW nicht auch noch aufdrücken kann (z.B. OOK pollen)



Offline Omega

  • Sr. Member
  • ****
  • Beiträge: 537
Super!
Gleich aber mal die 1. Verständnisfrage: werden der BME280 und der SC16IS750 parallel angeschlossen oder müsste ich auf den BME280 verzichten?
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
Verständnisfrage: werden der BME280 und der SC16IS750 parallel angeschlossen oder müsste ich auf den BME280 verzichten?
Musst nicht verzichten, funktioniert parallel.
Das AddOn läuft mit allem zusammen, was es bisher schon gab.

Online Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2701
RESPEKT !!!
Das LGW wird ja langsam ein richtiges Monster :)
Mit dem SC16IS750 habe ich noch ein kleines Problem .... Auf der einen Seite ist mir schon klar das ohne ihn ein OTA Update des Sub Arduino nicht machbar wäre, auf der anderen Seite frage ich mich ob das wirklich unbedingt nötig ist.
Ich könnte mir auch eine Lösung vorstellen wo auf den SC16IS750 ganz verzichtet wird und der Arduino direkt am I2C Bus des ESP hängt, d.h. der Arduino die Hardware des SC16IS750 als Software nachbildet oder habe ich hier einen generellen Denkfehler ?   

Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline AxelSchweiss

  • Sr. Member
  • ****
  • Beiträge: 748
RESPEKT !!!
Das LGW wird ja langsam ein richtiges Monster :)

HäHä .... dann machen wir das doch noch monster-hafter .... :)
Lässt sich für den Debug-Output in dem neuen Log-Dialog noch eine Weiterleitung an einen Syslog-Server realisieren?
Die empfangenen Telegramme würde ich jedoch nicht weiterleiten .... das wird dann doch zuviel.

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
RESPEKT !!!
Mit dem SC16IS750 habe ich noch ein kleines Problem .... Auf der einen Seite ist mir schon klar das ohne ihn ein OTA Update des Sub Arduino nicht machbar wäre, auf der anderen Seite frage ich mich ob das wirklich unbedingt nötig ist.
Ich könnte mir auch eine Lösung vorstellen wo auf den SC16IS750 ganz verzichtet wird und der Arduino direkt am I2C Bus des ESP hängt, d.h. der Arduino die Hardware des SC16IS750 als Software nachbildet oder habe ich hier einen generellen Denkfehler ?

Dazu müsste das LGW auf dem I2C Bus heftig pollen. Den Ansatz hatte ich ursprünglich mal ausgetestet, das haut nicht hin.
Das praktische sind gerade die 64 Byte serial FIFO des SC16IS750. Da muss das LGW nur "ab und zu" mal nachschauen, ob vom SubProzessor was geliefert wurde.

Die Erweiterung mit Radio #4 und #5 benötigt chipselects, die der SC16IS750 in Form seiner 8 IOs reichlich bietet, dazu allein ist kein weiterer Prozessor erforderlich.
Ebenso der Buzzer für die Alarm-Ausgabe.
Ziel war, bestimmte Erweiterungen zu ermöglichen, ohne weitere Software auf einem zweiten Prozessor haben zu müssen und den SubProzessor ganz alleine in die Hand des Anwenders zu geben, falls er so etwas benötigt, wo er dann machen kann, was er will.
Bedeutet: ich werde auch nichts "offizielles" für den SubProzessor liefern.

Auf der einen Seite ist mir schon klar das ohne ihn ein OTA Update des Sub Arduino nicht machbar wäre, auf der anderen Seite frage ich mich ob das wirklich unbedingt nötig ist.
Fast nichts in FHEM ist "unbedingt nötig"  ;D ;D
Aber wenn ich ein LGW per OTA updaten kann, ist es dann schon doof, dass ich für den SubProzessor mit Laptop und Kabel hinlaufen muss.

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
HäHä .... dann machen wir das doch noch monster-hafter .... :)
Lässt sich für den Debug-Output in dem neuen Log-Dialog noch eine Weiterleitung an einen Syslog-Server realisieren?
Die empfangenen Telegramme würde ich jedoch nicht weiterleiten .... das wird dann doch zuviel.
Das Log kannst Du ganz einfach selbst abrufen
mit: <LGW-IP>/getLogData
Besipiel: //192.168.31.211/getLogData

Liefert
DATA:OK 22 117 196 0 58 226 102 0 58 191 86 0 0 40 172 0 105 1 101 3 0 [75 C4 E2 66 00 00 BF 56 00 00 00 02 3B FC DC 00 69 01 65 4A A4 C4 F9 F2 4F 11 A4 F6 7C 03 A0 00 00 00 00 03 A0 38 09 21 27]
DATA:OK 9 11 130 4 173 125 [92 D5 97 7D 75]
DATA:OK EMT7110 84 81 8 207 0 36 0 1 1 199 1 [25 6A 54 51 40 02 00 24 C3 41 C7 9B]
SYS: AddOn: KV ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK VALUES ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK 9 38 1 4 67 65 [99 84 91 41 07]
DATA:OK 9 55 1 4 202 42 [9D C6 26 2A 19]
DATA:OK 9 41 1 4 177 53 [9A 46 01 35 41]
DATA:OK 22 126 67 0 65 236 34 0 65 231 116 0 0 32 103 0 48 0 134 1 0 [7E 43 EC 22 00 00 E7 74 00 00 00 01 C7 AC D7 00 30 00 86 00 57 E4 69 1E 46 8E D4 68 C7 04 10 00 00 00 00 04 10 18 0A DC F7]
DATA:OK 9 36 1 4 128 61 [99 05 52 3D 96]
DATA:OK WS 0 4 4 185 255 255 255 255 255 255 255 255 255 0 3 252

DATA: für die obere Liste
SYS: für die untere Liste

Bei jedem Aufruf werden die seit dem letzten Abruf neu aufgelaufenen Logeinträge geliefert.
Intern werden maximal 40 Einträge gepuffert (aber kein Ringpuffer, weil die ersten 40 mit dem Bootlog erhalten bleiben müssen)

Aber die Abruferei nicht übertreiben, sonst zwingst Du das LGW in die Knie.
Und nicht von zwei Instanzen gleichzeitig abrufen, das nimmt das LGW ganz krumm.

So generell: das Log ist eher als Hilfsmittel bei der Fehlersuche gedacht.
Z.B. um bei PCA301 zu verfolgen, wann wer was wie frägt und antwortet oder um zu schauen, ob irgend welche Sensoren überhaupt empfangen werden und die Daten an FHEM geliefert werden.

Offline AxelSchweiss

  • Sr. Member
  • ****
  • Beiträge: 748
Ahhh ... guck ... Danke
Mir ging es auch primär um ein klassisches Logging.
Warum ?  .... Bei mir hängt das LGW via WLAN an einem Powerline-Backbone.
Und der ist alles andere als stabil (deswegen fliegt der auch so schnell wie möglich raus ... nach dem Kabelziehen  .... irgendwann)
Dann würde ich die Reconnects und Fehler in meinem zentrale Syslog finden.
Die ganzen Telegramme via Syslog mitzuschreiben halte ich auch für Overkill.

Offline HCS

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3045
Mir ging es auch primär um ein klassisches Logging.
Nun ist mir noch nicht ganz klar, ob das oben Beschriebene Dir hilft oder nicht.

Einen reconnect von FHEM auf das LGW kannst Du auch aus dem FHEM-Log rauslesen:
2016.03.21 09:07:10 3: Opening myJeeLink device 192.168.31.211:81
2016.03.21 09:07:10 3: myJeeLink device opened