LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino

[PeMue]

OK. Der Deal wäre: Du machst ein Layout und ich verwende meinen eigenen BME280 
Aber ohne Scherze, ich will dich da zu nichts drängen, das braucht eh noch Zeit, bis wirklich sicher ist, was drauf müsste, könnte, sollte ....

Schaltplan aus dem ersten Thread? Leiterplattengröße? Wenn klar ist, was drauf soll und wie die Leiterplattengröße ist, warum nicht? So wie es aussieht, besteht sogar bei meinen Layouts die minimale Chance, dass sie funktionieren 

Edit: Nach dem Bibliotheks-"Desaster" korrigiere ich die Größe der Chance, dass die Leiterplatte funktioniert auf ein "muckeseckele" ...

[oli82]

Hab es nun (nach mehreren Anläufen) geschafft, von der 1.01 auf die 1.06 zu aktualisieren.
Da ich unter Windows (VM) aktualisiere, hat es erst geklappt, als ich die Baudrate auf 57600 gestellt habe.
Evtl kann das ja jemand bestätigen 

[AxelSchweiss]

Ich habe das ganz stumpf ... quasi im idiot-mode ... nach der Anleitung aus dem 1. Beitrag gemacht

Alternative für Windows: https://github.com/nodemcu/nodemcu-flasher
Einstellungen (Advanced Tab): 921600 Baud, 4MByte Flash size, 80 MHz Flash speed, SPI Mode: DIO
Auf dem Tab "Config" das LaCrosseGateway.bin auswählen, Ziel-Adresse 0x00000

hat ohne Probleme auf Anhieb funktioniert. Auch mit dieser komischen BaudRate.
Ich musste auch nichts stromlos machen ... Reset hat ausgereicht.

[HCS]

Da ich unter Windows (VM) aktualisiere, hat es erst geklappt, als ich die Baudrate auf 57600 gestellt habe.
Evtl kann das ja jemand bestätigen 

Das kann man nicht pauschal bestätigen. Wzut hatte auch Probleme mit hohen baud raten und mit 57600 hat es geklappt.
Ich bekomme das problemlos mit 921600 baud durch, andere auch.
Die hohen baud raten müssen von der Hardware (oder virtualisierten Hardware) halt unterstützt werden und bei VmWare kann ich mir schon vorstellen, dass das dann nicht klappt.
Ich werde mal im ersten Beitrag oben drauf hinweisen, dass es die Nächsten einfacher haben. Nachtrag: getan.

[BlackFlag]

Hallo HCS,
da ab 1.06 ja OTA funktioniert, wollte ich das jetzt alles platzsparend an einen ESP8266 12E löten, musste aber feststellen, dass es da GPIO6/7/8 und 1 nicht gibt. Wenn ich mir die Firmware selbst kompiliere und andere GPIOs nehme, würde das klappen? Ausreichend GPIOs hat der ja (0,2,4,5,9,10,12,13,14,15,16). Eine alternative Firmware für den 12e willst du nicht schnell mal machen .

Ich würde übrigens den Vorschlag unterstützen, dass man noch einen DHT11/22 dranhängen kann. Dann kann man das ganze auch noch als zusätzlichen Innenraumsensor mit Druck, Temperatur und Feuchtigkeit nehmen.

[BlackFlag]

Hallo HCS,
da ab 1.06 ja OTA funktioniert, wollte ich das jetzt alles platzsparend an einen ESP8266 12E löten, musste aber feststellen, dass es da GPIO6/7/8 und 1 nicht gibt. Wenn ich mir die Firmware selbst kompiliere und andere GPIOs nehme, würde das klappen? Ausreichend GPIOs hat der ja (0,2,4,5,9,10,12,13,14,15,16). Eine alternative Firmware für den 12e willst du nicht schnell mal machen .

Ich würde übrigens den Vorschlag unterstützen, dass man noch einen DHT11/22 dranhängen kann. Dann kann man das ganze auch noch als zusätzlichen Innenraumsensor mit Druck, Temperatur und Feuchtigkeit nehmen.

Beim betrachten des Devkits fiel mir auf, dass da ja ein 12e draufgelötet ist. Also sind die GPIOs nur umbenannt.
Auf dem Bild im Anhang kann man die Zuordnung von GPIO zu Dxx-Pins sehen. Muss also mit der gleichen Firmware gehen.

[HCS]

Muss also mit der gleichen Firmware gehen.

Richtig.
Allerdings ist Dein Bild ein devkit V0.9
Das devkit V1.0 sieht so aus (da sind gpio9 und 10 rausgeführt, gpio9 wird ab LGW 1.07 als CS für den dritten RFM verwendet)
(http://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=41456;image)

[HCS]

Der Mann mit der roten Kleidung und dem Bart hat etwas gebracht:

V1.07

Quellcode verfügbar
hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip
Zum compilieren (wofür es eigentlich keinen Grund gibt, das binary reicht) ist (aktuell) folgende tool chain erforderlich:
- Arduino IDE V1.6.5 (nicht V1.6.6)
- ESP8266 Arduino Library V2.0.0-rc2

Fix OTA-Update bei manchen Browsern
Einigen browser (z.B. Chrome auf El Capitan) haben an die url hinten ein ? angehängt, wo ich es nicht erwartet hätte.
Das hat dann das OTA-Update verhindert.

Neues Setting KV-Identity
Auf der Setup-Page kann nun die identität des LGW für die Statuswerte in FHEM festgelegt werden, bisher war es fix die Chip-ID

Neuer Staus-Wert "RSSI"
Die wifi Signalstärke (dBm). -36 ist besser als -60

Bis zu drei Clients (FHEMs)
Es können nun auf der Setup-Page bis zu drei Ports, auf die sich dann bis zu drei FHEMs verbinden können, definiert werden.
Ports die man nicht benötigt, sollte man leer lassen, um Speicher und Rechenleistung zu sparen.
Die Portnummer 8266 ist verboten, die wird von OTA verwendet, und 80 geht natürlich auch nicht.
Wenn sich mehrere FHEMs ein LGW teilen, kann das natürlich nur mit einer gemeinsamen Konfiguration gehen.
Wenn die FHEMs unterschiedliche initCommands senden, gewinnt das (zufällig) letzte und legt es für alle anderen fest.

Dritter RFM möglich
Es kann nun ein dritter RFM69 / RFM12 angeschlossen werden.
MOSI, MISO und SCK parallel drauf, der ChipSelect für den dritten ist GPIO9 (SD2)
Aktualisierter Schaltplan in Beitrag #1 folgt in Kürze.

Commands Logik für drei RFMs erweitert
Da es nun drei RFMs gibt, die man konfigurieren muss / kann, reicht das System "Kleinbuchstabe ist #1 und Großbuchstabe ist #2" nicht mehr aus.
Es ist zur Kompatibilität noch aktiv, zusätzlich gibt es diese Variante:
<value>#<RfmNumber><command>
Beispiele:
Frequenz des zweiten RFM setzten: 868300#2f
Frequenz des dritten RFM setzten: 868295#3f
DataRate des ersten RFM setzen: 0#1r
DataRate des dritten RFM setzen: 8842#3r


Viel Spaß oder Glück oder was immer man für diese Version braucht ...

[Wzut]

Der Mann mit der roten Kleidung und dem Bart hat etwas gebracht:

Einwandfrei !! , da kann ich die Integration des DHT22 und DS1820 gleich am lebenden Objekt testen.
Ich denke mit den beiden Sensoren werde ich heute fertig.
Leider hat mein LM75 ne Macke so das ich den erst nächste Woche mit aufnehmen kann.

[Wzut]

Zum compilieren (wofür es eigentlich keinen Grund gibt, das binary reicht) ist (aktuell) folgende tool chain erforderlich:
- Arduino IDE V1.6.5 (nicht V1.6.6)
- ESP8266 Arduino Library V2.0.0-rc2

Lief bei mir im ersten Versuch nicht durch. Ich musste #include WiFiUDP.h durch #include WiFiUdp.h ersetzen und in den libs #include "Arduino.h" ganz entfernen.
Im Anhang eine geänderte Version der InternalSensors lib, diese unterstützt einen internen DHT22 und/oder einen DS1820.
Einbinden :
in der LaCrosseGateway.ino bei den includes diese beiden Libs noch hinzufügen:
#include <OneWire.h>
#include <DHT.h>
Aufruf des/der internen Sensor(en) z.B. im Abschnitt setup :

Code Auswählen Erweitern


  internalSensors.TryInitializeBMP180();
  if (internalSensors.HasBMP180()) {
    internalSensors.SetAltitudeAboveSeaLevel(ALTITUDE_ABOVE_SEA_LEVEL);
    if (DEBUG_ESP) {
      Serial.println("BMP 180 found");
    }
  }

danach diese Zeilen hinzufügen :

Code Auswählen Erweitern


  else
   {
    internalSensors.TryInitializeOW(5);   // DS1820 am Pin5 bzw. D1
    internalSensors.TryInitializeDHT(4); // DHT22 am Pin4 bzw. D2
   }

unter der Bedingung das man keinen BMP180 an den beiden I2C GPIOs (4 & 5 bzw. D1 & D2) hängen hat.
Sind die beiden Pins schon belegt kann man auf jeden Pin anderen ausweichen der noch frei ist.
Wichtig : den/die verwendeten Pin(s) je mit einem PullUp (z.B 4,7 K) gegen VCC versehen.
Der DHT22 und der DS1820 meldet sich in fhem wie ein normaler TX29-IT ( der DHT mit der festen ID FE , beim DS1820 hängt die ID von seiner ROM Adresse ab).

Ich habe leider mit der C++ Syntax immer so meine kleinen Problemchen, daher findet sich in der InternalSensors.cpp eine etwas unschöne (doppelte) Verwendung von OneWire ds(pin,false). Vllt kann mir ja mal jemand zeigen wie man so etwas eleganter macht.
 

[AxelSchweiss]

Dritter RFM möglich
Es kann nun ein dritter RFM69 / RFM12 angeschlossen werden.
MOSI, MISO und SCK parallel drauf, der ChipSelect für den dritten ist GPIO9 (SD2)
Aktualisierter Schaltplan in Beitrag #1 folgt in Kürze.

Kann man damit dann auch diese PCA301 Steckdosen mit dem gleichen Sketch schalten?
Soweit ich das begriffen habe scheiterte das bisher an dem anderen Radio und dem zu wenig Ram des Arduino.

[HCS]

Kann man damit dann auch diese PCA301 Steckdosen mit dem gleichen Sketch schalten?
Soweit ich das begriffen habe scheiterte das bisher an dem anderen Radio und dem zu wenig Ram des Arduino.

Das Radio sollte OK sein, PCA301 verwendet glaube ich auch RFMs.
Dass der LaCrosse-Sketch am Anschlag ist, ist richtig.
Ein weiterer Grund ist, dass ich es implementieren müsste, mir also mal PCA301 draufschaffen, so 'ne Steckdose habe ich auch nicht, ...
Ich habe es schon von Beginn an auf der Wunschliste für das LGW, aber ob und wann das was wird, will ich jetzt mal noch keine Prognose abgeben.

[HCS]

Lief bei mir im ersten Versuch nicht durch. Ich musste #include WiFiUDP.h durch #include WiFiUdp.h ersetzen und in den libs #include "Arduino.h" ganz entfernen.

Ja, Groß-/Kleinschreibung falsch. Merkt man unter Windows nicht...
Habe es repariert.

Den Rest muss ich mir dann mal in Ruhe anschauen.
Kannst Du mir noch die DHT-Lib schicken, die Du verwendet hast?

[Wzut]

Kannst Du mir noch die DHT-Lib schicken, die Du verwendet hast?

Ja kein Problem, ich müsste diese haben : http://playground.arduino.cc/Main/DHTLib
Habe aber gerade gelesen das es von adafruit eine Version gibt die man durch einen zusätzlichen Warteparameter besser auf den ESP8266 abstimmen kann ->https://github.com/adafruit/DHT-sensor-library

So when you use an example DHT application make sure to add that extra 15 parameter to the DHT object's constructor call. The parameter tells the code to wait an extra amount of cycles to read ones and zeros from the sensor--normally the library assumes its running on a slower Arduino so it can get a little confused when the processor is faster

werde ich heute Abend mal testen zusammen mit einem anderen LM75

[HCS]

werde ich heute Abend mal testen zusammen mit einem anderen LM75

OK. Bevor Du zu viel Arbeit in die falsche Richtung inverstierst, einige Gadanken und Unumgänglichkeiten dazu:

- Wenn DHT22 / DS1820 unterstützt werden, sollte das auf alle Fälle zusätzlich zu BMP180 gehen, sonst muss man auf den Luftdruck verzichten
- DHT22 / DS1820 würde ich auf einem GPIO abhandeln, es macht ja nur einer Sinn, nicht beide gleichzeitig

- Mögliche GPIO-Verwendung:
GPIO4 und 5 sind immer I2C, da kann ein BMP180, ein BME280 oder sonst ein I2C Baustein (z.B. LM75) dran.
GPIO10: (OneWire oder) DHT22 oder sonstwas wie z.B. ein OOK Radio
GPIO9 ist bereits der CS für den dritten RFM
GPIO0 muss ich mal noch ermitteln, was machbar ist, ohne den Bootvorgang zu gefährden, evtl. ein OOK Sender
     
Wenn man LaCrosse, Temp, Hum und Feuchte will, könnte man verwenden:
  ein bis drei RFMs und einen BME280
  ein bis drei RFMs, einen BMP180 und einen DHT22

Wenn man keine Feuchte will, dann: ein bis drei RFMs, einen BMP180

Wenn man nur die Temperatur will, dann: ein bis drei RFMs und einen (DS1820) LM75

Und das Ganze sollte so werden, dass diese Varianten vom Sketch erkannt werden, ohne dass man Ports konfigurieren
und die Firmware bilden muss.

Wenn der LM75 implementiert wird, dann würde ich auf die DS1820 Implementierung verzichten, weil man dann die Temperatur auf I2C hat und weniger Stress auf GPIO10.
1Wire wäre dann ganz raus.
Das LGW muss nun auch nicht die "AllSensorsYouCanFind" Plattform werden, der primäre Zweck ist der Empfang von LaCrosse.

Das sollte noch von der Architektur anders werden, aus der InternalSensors muss DHT und OneWire raus, weil ich die auch in anderen Projekten verwende (z.B. LaCrosse-Sketch) und es dort eher störend ist. Am besten wird man im LGW eine "LGWSensors" von der "InternalSensors" ableiten.