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

[Omega-5]

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

Ganz schön anspruchsvoll.    Dann würde es sich aber auch anbieten, statt des Portpins für 1-Wire, einen DS2482 I²C 1-Wire Master ein zusetzen. Dann kann man die Auswertung verschiedener 1-Wire-Sensoren in FHEM machen. Für die meisten sind ja schon Module vorhanden. Mit dem Baustein und einem FET bekommt man dann auch die parasitäre Speisung besser in den Griff.

Gruß Friedrich

[habeIchVergessen]

mit dem Busmaster am I²C wäre auch mein Favorit. Bin mir aber nicht sicher, ob das in diesen Thread gehört.

[HCS]

Ganz schön anspruchsvoll. 

Echt?
Wie viele und weche Sorte (12 oder 69) RFMs bestückt sind und ob ein BMP180 drauf ist, erkennt es ja auch schon.
Und was es nicht als Alternativen erkennen kann, bleibt raus.

Das LGW muss nun auch nicht die "AllSensorsYouCanFind" Plattform werden, der primäre Zweck ist der Empfang von LaCrosse.

Und dabei bleibe ich.

Es kann bereits: 1...3 x RFM12 oder RFM69 (auch gemischt) automatisch erkannt
BMP180 für Druck und Temperatur automatisch erkannt.
Es wird auf alle Fälle (auch automatisch erkannt) den BME280 für Temperatur, Feuchte und Druck können.
Der DHT22 für Temperatur und Feuchte ist auch noch machbar, auch automatisch erkannt.

Wie viele Sensoren soll es denn noch können und warum?

[Wzut]

Ganz schön anspruchsvoll. 

Da bin ganz Friedrichs Meinung
@HCS, es ist dein Baby und somit auch deine Entscheidung wieviel Arbeit und welcher Art (und für wen) du dir in Summe ans Bein binden willst.
IMHO hast du mit der Setup Seite im Webinterface schon eine gute Grundlage, warum alle 200 möglichen Anbauteile und deren 500 Ausbaustufen via autocreate erfassen und nicht auf der Setupseite selbst zusammen klicken ?
Ideen was man noch alles anschliessen könnte werden mit Sicherheit noch einige kommen  ( Mir allein fallen da schon spontan das OLED I2C Display und die I2C digital I/O Port Erweiterung ein ... )       

[HCS]

Da bin ganz Friedrichs Meinung

Ist mir nicht ganz klar, was da jetzt so anspruchsvoll ist. Ich habe nur das Konzept für alle Sensoren, die Du ins Spiel gebracht hast, aufgezeigt.
Und die Erkennung, ob ein DHT22 und ein DS1820 angeschlossen ist, hast Du doch auch schon in der InternalSensors implementiert.
Ich habe das Ganze nur ein wenig auf den GPIOs umverteilt und will die InternalSensors ableiten, um nicht andere Projekte dran anpassen zu müssen.

Trotzdem müsste mir jemand noch die Frage beantworten, warum es 5 verschiedene Temperatursensoren unterstützen sollte.

Eine andere (noch völlig unausgereifte) Idee ist mir aber gerade eingefallen: wenn ich auf der seriellen Schnittstelle ein Protokoll zur Verfügung stelle, mit dem man Daten beim LGW abliefern kann, könnte jeder, der Bedarf hat, sich einen Sub-Prozessor dranpacken, z.B. einen kleinen Mega oder 'nen Tiny mit Sensoren dran, was immer er will und das LGW würde die Daten dann stumpf an FHEM übermitteln, z.B. per KeyValueProtocol.
Somit müsste sich jemand nicht mit WiFi, Konfiguration und dem ganzen Kram rumschlagen, sondern nur ein wenig Sensor auslesen implementieren und auf der Seriellen in einem bestimmten Format rausgeben. Das LGW erledigt dann den Rest. Dann wäre das LGW, ohne es ändern zu müssen, universell erweiterbar.

[HCS]

Stabil scheint es auf alle Fälle zu laufen:
<LGW>
  <Info Key="UpTimeSeconds" Value="711895"/>
  <Info Key="UpTimeText" Value="8Tg. 5Std. 44Min. 55Sek. "/>
  <Info Key="WIFI" Value="هذا هو سري"/>
  <Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
  <Info Key="ChipID" Value="10120520"/>
  <Info Key="ReceivedFrames" Value="615949"/>
  <Info Key="FramesPerMinute" Value="94"/>
</LGW>

Aber länger halte ich nicht durch, ohne neue Firmware zu flashen 

[Doublefant]

Ich lese hier schon eine Weile mit und finde das Projekt sehr interessant.
Die Teile sind jetzt bestellt.
Ich werde mich an der Einrichtung versuchen und Feedback geben.

Ich hätte auch einen Funktionswunsch, auch wenn es nicht out-of-the-box verhanden ist die der LaCrossSketch, aber evtl. besteht ovn anderer Seite auch noch irgendwo Interesse für eine Umsetzung.
Soweit ich es im Datenblatt gelesen habe unterstützt der RFM69 Baustein von Haus aus die OOK Modulation.
Demnach müsste es doch in der Theorie möglich sein, mit dieser Gateway auch die OOK-Wetterstationen einzulesen und/oder Baumarksteckdosen zu schalten?
Speicherplatz müsste ausreichend vorhanden sein.

[Wzut]

Trotzdem müsste mir jemand noch die Frage beantworten, warum es 5 verschiedene Temperatursensoren unterstützen sollte.

Eine andere (noch völlig unausgereifte) Idee ist mir aber gerade eingefallen: wenn ich auf der seriellen Schnittstelle ein Protokoll zur Verfügung stelle, mit dem man Daten beim LGW abliefern kann, könnte jeder, der Bedarf hat, sich einen Sub-Prozessor dranpacken

Es müssen keine fünf sein, nach meiner Meinung eichen auch zwei vollkommen. Entweder man hat noch einen GPIO frei dann den DHT22 oder es sind alle Ports belegt dann weicht man auf auf die I2C Schiene aus.
Sub-Prozessor fände ich suboptimal, klar er bringt dann wieder jede menge IOs, opferst aber die direkte serielle fhem Anbindung. Aussderdem müsste man sich noch einen Baustein programmieren und auf dem ESP ist doch noch jede Menge Platz. Stichwort Platz, im Anhang das LGW mit 128x64 Pixel I2C OLed Display.
(auch da ist noch viel Platz für nette Infos frei ..... )

[HCS]

und/oder Baumarksteckdosen zu schalten?

Das scheint machbar, aber OOK ist bisher nicht unbedingt mein Spezialthema.
Da muss ich mich mal irgendwann in Ruhe mit beschäftigen.

Demnach müsste es doch in der Theorie möglich sein, mit dieser Gateway auch die OOK-Wetterstationen einzulesen ...

Das ist schon heftiger, aber evtl. auch machbar.

Speicherplatz müsste ausreichend vorhanden sein.

Speicherplatz ist nicht das Problem. Es könnte eher ein Problem sein, dass man bei OOK heftig das RSSI pollen muss und das könnte auf dem ESP, der "nebenbei" ja den kompletten IP protokoll stack, wifi und sonst einiges in Schwung halten muss, problematisch werden. Eventuell wird da noch ein Signalisierungs-Port des RFM benötigt, für den dann noch ein GPIO des ESP8266 frei sein muss.
Ich habe das auf der Langzeitagenda, aber Prognosen, ob überhaupt oder wann das was wird, gebe ich mal noch keine ab.

Wichtig: ich habe gerade den ChipSelect des dritten RFM auf GPIO0 (D3) verlegt (ab V1.08)
Grund: GPIO0 ist der flash taster mit PullUp. Das spielt für den CS keine Rolle, da er erst nach dem Booten zum Ausgang wird und ein RFM69 hier nicht stören kann.

Somit sind dann GPIO9 und GPIO10 noch verfügbar, und die können beide als Eingänge oder Ausgänge verwendet werden, weil sie keine Spezialfunktionen wie z.B. die Bootsteuerung haben.

GPIO9 "opfere" ich für einen internen Sensor (z.B. DHT22), der andere bleibt als Vorrat für OOK oder sonst was "wichtiges".

Sub-Prozessor fände ich suboptimal, klar er bringt dann wieder jede menge IOs, opferst aber die direkte serielle fhem Anbindung

Darum ist es ja auch ein Sub(optimal)-Prozessor 
Die direkte serielle Anbindung an FHEM wollte ich nicht opfern, ich dachte eher an ein SoftSerial über nur einen Pin.

im Anhang das LGW mit 128x64 Pixel I2C OLed Display.

Coole Sache. Auch auf die Gefahr hin, dass ich die permanente Spaßbremse bin, was ist denn da der use case?

[AxelSchweiss]

Coole Sache. Auch auf die Gefahr hin, dass ich die permanente Spaßbremse bin, was ist denn da der use case?

Man könnte doch da einen loadabhängigen Pacman drüber flitzen lassen  ? ..... nur'n Scheerz.

Habe ich mich auch gefragt wozu das soll  ... aber welche Lib hast du den dafür verwendet .... U8glib ?

[HCS]

Man könnte doch da einen loadabhängigen Pacman drüber flitzen lassen

Besser so einen use case als gar keinen 

[Wzut]

Auch auf die Gefahr hin, dass ich die permanente Spaßbremse bin, was ist denn da der use case?

[OT on]
Wenn ich ich gemein wäre würde ich mit der Gegenfrage antworten "warum lecket der Hund sich die Eier ?" (Antwort : "weil er es kann")
Das Display hängt bei mir sowieso am Devkit weil ich es für eine andere noch offene Baustelle benötige. Die verwendete Lib ist von Adafruit.
[OT off]
Bei mir soll später das LGW mit drei RFMs und einem kleinen Schaltnetzteil zusammen in einem Steckgehäuse irgendwo in der Wohnung an einem zentralen Punkt in einer Steckdose stecken. Z.Z. überlege ich noch ob ich dem LGW ein/zwei LEDs spendiere um zumindest etwas vom Status direkt anzuzeigen oder doch noch so ein Oled kaufe und neben Status Infos auch Temperatur und Luftfeuchte des interen Sensors anzeige. So wie der beliebte   TX29DTH-IT Sensoren sein kleines LCD auch nicht für einen internen PacMan hat ....     

[AxelSchweiss]

Die Idee das in ein Steckergehäuse zu verpacken finde ich gut.
Ich möchte nä(h)mlich das LGW einfach in die Ecke werfen und nicht mehr sehen .... es soll dann einfach nur noch funktionieren.

[HCS]

Ich möchte nä(h)mlich das LGW einfach in die Ecke werfen und nicht mehr sehen .... es soll dann einfach nur noch funktionieren.

So ich auch. Am besten hinter einem Schrank.
Das war auch die Grundidee des LGW, dass die ideale Position zum Empfang aller Sensoren meist nicht mit dem Standort des Servers übereinstimmt.

Die Idee das in ein Steckergehäuse zu verpacken finde ich gut.

Die Frage ist, wie realistisch die Temperaturwerte in einem Steckergehäuse mit Spannungsversorgung innen drin sind.
Ich glaube, dass ich es lieber in ein kleines Gehäuse setze (auf einer hübschen kleinen Platine, habe es nicht vergesen, PeMue) und mit einem externen USB-Steckernetzteil versorge.
Aber dass kann ja dann zum Glück jeder nach seinem Geschmack gestalten.

Ich werde noch den beliebten DHT22 und den BME280 mit autosense implementieren, und dann ist erst mal gut mit lokalen Sensoren.
Wer jetzt schon Hardware bastelt, sollte aber zu Sicherheit noch etwas Platz lassen, um irgend welche weitere Hardware später noch rein zu bekommen.

[habeIchVergessen]

ich habe mir ebenfalls ein NodeMCU zugelegt und wollte ein wenig damit spielen. Meine Idee ist es, mit UDP-Multicast ins Netz zu brüllen. Ggf. sinkt damit der CPU-Aufwand im Gateway (mehr Nachrichten pro Minute).
In FHEM könnte anhand der ChipID (wird mittels http gelesen) selektiert werden, welche Nachrichten verarbeitet werden sollen (mehrere Gateways in einem Netz). Nur so eine Idee für ein kleines Framework, die ich zur Diskussion stellen wollte.
Würde gut zum KeyValueProtocol passen (schön generisch).