Neuartiges CUL Interface - miniCUL mit WLAN-Schnittstelle

[noice]

Mal ne Frage:

wie genau flasht ihr die esp-link-Software auf den ESP?
Ich benutze den NODE-MCU-Flasher und lade die den Bootloader, die user1.bin und die blank.bin drauf, allerdings macht er dann kein WLAN auf.

Hättest du den cul schon im netzwerk? Wenn ja probiere mal die vorhandene ip. Einfach im Browser eingeben. Bei mir waren nach dem umflashen immer noch die  zugangsdaten gespeichert.

Mobil erstellt daher kurz gehalten

[noice]

Mal ne Frage:

wie genau flasht ihr die esp-link-Software auf den ESP?
Ich benutze den NODE-MCU-Flasher und lade die den Bootloader, die user1.bin und die blank.bin drauf, allerdings macht er dann kein WLAN auf.

Hättest du den cul schon im netzwerk? Wenn ja probiere mal die vorhandene ip. Einfach im Browser eingeben. Bei mir waren nach dem umflashen immer noch die  zugangsdaten gespeichert.

Mobil erstellt daher kurz gehalten

[frank]

Mobil erstellt daher kurz gehalten

besser 1x lang, als 3x kurz. 

[noice]

besser 1x lang, als 3x kurz. 

Tapatalk lässt grüßen

Mobil erstellt daher kurz gehalten

[locutus]

Wie kann man eigentlich den ESP zurücksetzten? Das aufspielen der ESP transparent Firmware hatte allerdings keinen Reset der Einstellungen gemacht.
Nach dem flashen der esp-link Firmware hatte ich zumindest wieder zugriff auf das ESP Modul.

Das ist die Aufgabe der blank.bin Datei.
"blank.bin needs to be flashed only when the sdk version is upgraded or when WiFi configuration parameters have to be erased. Note the different address for blank.bin."

wie genau flasht ihr die esp-link-Software auf den ESP?
Ich benutze den NODE-MCU-Flasher und lade die den Bootloader, die user1.bin und die blank.bin drauf, allerdings macht er dann kein WLAN auf.

Die Parameter und Flashadressen sind hier beschrieben: https://github.com/jeelabs/esp-link/releases/tag/v2.1.7
Du musst nur herausfinden, welchen Flash Size und SPI Mode das ESP-Funkmodul verwendet.

Ich bekomme seit neuestem per autocreate ein CUL_IR_miniCUL.
Wat n dat?

http://fhem.de/commandref.html#CUL_IR
Der miniCUL hat keine Infrarotschnittstelle. Somit kann es nicht an der Hardware liegen.

[RappaSan]

Die fehlende IR-Sensorik ist mir bewußt. Drum hab ich mich auch so gewundert...

Btw.: Wünsche allen ein schönes Weinachten - ist ja schon fast vorbei.

[viegener]

http://fhem.de/commandref.html#CUL_IR
Der miniCUL hat keine Infrarotschnittstelle. Somit kann es nicht an der Hardware liegen.

Nicht bezogen auf das obige Problem aber als Frage für mögliche Erweiterungen:

Wäre es möglich den miniCul um ein Infrarot-Interface (Senden und Empfangen) hinzuzufügen?
Der Code steht ja in der culfw/a-culfw zur Verfügung, man müsste nur möglicherweise schauen ob am 328P noch passende Pins zur Verfügung stehen. Hintergrund: Es wäre damit möglich auch Geräte per Infrarot zu steuern und gerade da ist ja eine dezentrale Positionierung interessant, da FHEM ja nicht unbedingt da steht wo z.B. TV/Audiosysteme stehen.
Alle meine Versuche das über CUL_RFR zu realisieren sind gescheitert, das Protokoll erscheint mir doch recht fragil

[locutus]

Hardwareseitig wäre zumindest IR-Senden möglich. Für IR-Empfangen wird ein freier Interrupt-Port am ATMEGA328P benötigt. Leider sind INT0 und INT1 bereits belegt.
Softwareseitig lässt FHEM ein Infrarot-Interface am CUL nicht zu. Die Definition eines CUL_IR endet mit der Meldung:

Wrong IODev specified or IODev doesn't support CUL_IR

[viegener]

Hardwareseitig wäre zumindest IR-Senden möglich. Für IR-Empfangen wird ein freier Interrupt-Port am ATMEGA328P benötigt. Leider sind INT0 und INT1 bereits belegt.
Softwareseitig lässt FHEM ein Infrarot-Interface am CUL nicht zu. Die Definition eines CUL_IR endet mit der Meldung:

OK, das mit dem fehlenden Interrupt hatte ich befürchtet, da ist der 328 etwas eingeschränkt. Senden wäre eigentlich schon ausrecihende, da man das Anlernen ja auch an anderer Stelle vornehmen könnte (eigentlich sogar getrennt von FHEM und nur den Code eintragen).

Die Meldung müsste sich aber lösen lassen, denn eigentlich müsste im CUL auch CUL_IR als unterstütztes Protokoll aufgeführt sein.

An welchen Pins ist denn ds ESP8266-Modul angeschlossen?

[locutus]

Der ESP ist mit RXD, TXD und RESET verbunden.

IR-Senden ist über folgende Pins möglich:

Code Auswählen Erweitern

#elif defined (__AVR_ATmega48__)    \
   || defined (__AVR_ATmega88__)    \
   || defined (__AVR_ATmega88P__)   \
   || defined (__AVR_ATmega168__)   \
   || defined (__AVR_ATmega168P__)  \
   || defined (__AVR_ATmega328P__)                      // ATmega48|88|168|168|328 uses OC2A = PB3 or OC2B = PD3 or OC0A = PD6 or OC0B = PD5
#if IRSND_OCx == IRSND_OC2A                             // OC2A
#define IRSND_PORT                              PORTB   // port B
#define IRSND_DDR                               DDRB    // ddr B
#define IRSND_BIT                               3       // OC2A
#elif IRSND_OCx == IRSND_OC2B                           // OC2B
#define IRSND_PORT                              PORTD   // port D
#define IRSND_DDR                               DDRD    // ddr D
#define IRSND_BIT                               3       // OC2B
#elif IRSND_OCx == IRSND_OC0A                           // OC0A
#define IRSND_PORT                              PORTB   // port B
#define IRSND_DDR                               DDRB    // ddr B
#define IRSND_BIT                               6       // OC0A
#elif IRSND_OCx == IRSND_OC0B                           // OC0B
#define IRSND_PORT                              PORTD   // port D
#define IRSND_DDR                               DDRD    // ddr D
#define IRSND_BIT                               5       // OC0B
#else
#error Wrong value for IRSND_OCx, choose IRSND_OC2A, IRSND_OC2B, IRSND_OC0A, or IRSND_OC0B in irsndconfig.h
#endif // IRSND_OCx

Am miniCUL sind PD5 und PD6 frei verfügbar.
Achtung! In irsnd.c hat sich ein Bug eingeschlichen. Ein kleiner Hinweis: der Fehler versteckt sich in der Zeile 179 und 180.

Vielleicht hilft dir das weiter. Alle meine Versuche sind misslungen.

[viegener]

Am miniCUL sind PD5 und PD6 frei verfügbar.
Achtung! In irsnd.c hat sich ein Bug eingeschlichen. Ein kleiner Hinweis: der Fehler versteckt sich in der Zeile 179 und 180.

Danke für die Infos, das erspart mir die Kopflupe aufzusetzen 

Ja der Fehler mit DDRB statt DDRD war mir auch schon untergekommen als ich Versuchen unternommen hatte.
Meine Versuche (ohne ESP) waren bisher bei den IR-Teile schon erfolgreich. Allerdings bin ich in Probleme damit gelaufen, dass der Timer für IR-Receive um den Faktor 125 schneller läuft, damit er die IR-Signale samplen kann. Dadurch wird wohl der Empfang von FASTRF (und damit auch von Routing-Signalen) instabil. Also bin ich in die Sackgasse gelaufen. Deshalb wäre der ESP-Ansatz so interessant, man spart sich gleich den Router.

Ich werde erstmal Versuche (Nano plus ESP) auf dem Breadboard machen bevor ich den miniCul angehe.
Für die Zukunft könnte auch ein Leonardo / 32U4 interessant sein, der hat ja mehr Interrupts.

[locutus]

Bist du bitte so freundlich und hängst deinen Source Code (board.h, miniCUL.c, Makefile) hier an. Ich möchte mir den mal ansehen. Danke!

[viegener]

Klar gerne, allerdings habe ich meine Versuche auf der Basis der culfw (nicht a-culfw) und dem Nanocul gemacht.
Dateien dazu anbei, auch wenn ich nicht annehme, dass sie so helfen. Das ist ein Zwischenstand, allerdings habe ich genau damit CUL-Routing nicht stabil zum Laufen gebracht, dann bin ich auf Deinen minicul mit ESP gestossen.

Damit werde ich wohl einen neuen Start versuchen.

[Garagenhaus]

Hallo locutus,
eine Frage hätte ich: sind das nicht zwei Module, die von den Pads ziemlich abweichen?
Vom CC113L finde ich nur ein 433 MHz Modul, und das ist auch kleiner, als das CC1101 (SMD) Modul.
Prinzipiell habe ich natürlich auch Interesse ...

Danke + Gruß

Peter

Ich würde da gerne noch ne Frage nachschieben: Der CC113L klinkt für mich wie ein reiner Empfänger der nicht senden kann.
"The CC113L is a cost optimized sub-1 GHz RF receiver for the 300–348 MHz, 387–464 MHz, and 779–928 MHz frequency bands. The circuit is based on the popular CC1101 RF transceiver, and RF performance characteristics are identical. The CC115L transmitter together with the CC113L receiver enable a low-cost RF link. "
http://www.ti.com/product/CC113L/description
Das würde dann aber kein vollwertiger CC1101 Ersatz sein, oder?

[locutus]

Entgegen den Angaben im Datenblatt sendet der CC113L auf 433 MHz recht zuverlässig. Der Chip verarbeitet SWAP und culfw Funkprotokolle.
Ich muss gestehen, dass ich mich nie mit dem CC113L Datenblatt befasst habe. Nachdem ich das Funkmodul erworben habe, wurde die Schaltung umgehend in der produktiven Umgebung eingesetzt. Und siehe da, das Teil funkt tadellos meine ELRO Funksteckdosen an.
Verschweigt man uns etwas? Ist es eine Verkaufsstrategie?