Neuartiges CUL Interface - miniCUL mit WLAN-Schnittstelle

Begonnen von locutus, 25 Oktober 2015, 23:12:21

Vorheriges Thema - Nächstes Thema

RappaSan

#15
Bei der Versionsabfrage kommt:

VERSION

V 1.10.02 a-culfw Build: private build (unknown) miniCUL (F-Band: 868MHz)

Die 868 MHz irritieren etwas. Sollte doch 433 sein, oder?

Nachdem ich die freq auf 433 umgeschaltet habe ist diese Meldung auch korrigiert. War wohl standardmäßig auf die höhere freq eingestellt.

locutus

Und das passiert wann? Zwischen 3 – 4 Uhr, während die Frite ihre IP erneuert? Vermutlich bricht zu dem Zeitpunkt die TCP Verbindung ab.

Zitat von: RappaSan am 05 November 2015, 14:24:20
Bei der Versionsabfrage kommt:

VERSION

V 1.10.02 a-culfw Build: private build (unknown) miniCUL (F-Band: 868MHz)

Die 868 MHz irritieren etwas. Sollte doch 433 sein, oder?

Nachdem ich die freq auf 433 umgeschaltet habe ist diese Meldung auch korrigiert. War wohl standardmäßig auf die höhere freq eingestellt.
Ein 433 MHz CUL kann auch auf 868 MHz senden/empfangen. Es ist alles Sache der richtigen Konfiguration:
http://www.fhemwiki.de/wiki/CUL

RappaSan

Hallo Locutus, das mit der Umschaltfähigkeit auf 868 MHz ist schon klar.

Die Verbindungsabbrüche habe ich hier übrigens auch. Eine feste Zeit läßt sich hier ebenfalls nicht festmachen.
Nach einem reopen kommt der Status wieder auf initialized. Wenn ich dann aber eine IT-Steckdose  schalte, ist der CUL wieder bei disconnected. Der Schaltvorgang wird nicht ausgeführt.

Omega-5

@locutus
Ich habe gerade ähnliche Probleme mit meiner promicroCUL Anpassung für die Umbelegung der Ports für GDO0 und GDO2.
Kann es sein das in der bord.h der INT falsch ist. Meiner Überlegung nach müßte der dem CC1100_IN_PIN zugeordnet sein,
also :
#define CC1100_IN_DDR DDRD
#define CC1100_IN_PORT PIND
#define CC1100_IN_PIN 3
#define CC1100_IN_IN PIND

#define CC1100_INT INT3
#define CC1100_INTVECT INT3_vect
#define CC1100_ISC ISC30


oder liege ich da falsch?
Ich konnte es bei mir noch nicht austesten, wg. Gartenarbeit.  ::)

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),

locutus

Es liegt nicht an der Hardware. Ich betreibe schon seit Monaten den ESP8266 ohne nennenswerte Ausfälle in Verbindung mit OWX-ASYNC an einem 1-Wire Bus Master.
http://forum.fhem.de/index.php/topic,18996.msg273097.html#msg273097

Es liegt an 00_CUL.pm. SpenZerX hat die Problematik angesprochen, RK sieht jedoch keinen Handlungsbedarf.
http://forum.fhem.de/index.php/topic,42340.0.html

Die JeeLink Verfechter hatten das gleiche Problem und spendierten deshalb der Softwareschnittstelle ein neues Attribut – timeout.
http://forum.fhem.de/index.php/topic,14786.msg342811.html#msg342811


Zitat von: Omega-5 am 06 November 2015, 10:21:40
@locutus
Ich habe gerade ähnliche Probleme mit meiner promicroCUL Anpassung für die Umbelegung der Ports für GDO0 und GDO2.
Kann es sein das in der bord.h der INT falsch ist. Meiner Überlegung nach müßte der dem CC1100_IN_PIN zugeordnet sein,
also :
#define CC1100_IN_DDR DDRD
#define CC1100_IN_PORT PIND
#define CC1100_IN_PIN 3
#define CC1100_IN_IN PIND

#define CC1100_INT INT3
#define CC1100_INTVECT INT3_vect
#define CC1100_ISC ISC30


oder liege ich da falsch?
Ich konnte es bei mir noch nicht austesten, wg. Gartenarbeit.  ::)

Gruß Friedrich
INT3!? Mit welchen ATMEGA Typ ist der CC1101 verbunden? Der ATMEGA328P hat hardwareseitig nur 2 Interrupt-Ports: INT0 und INT1

Omega-5

ZitatINT3!? Mit welchen ATMEGA Typ ist der CC1101 verbunden? Der ATMEGA328P hat hardwareseitig nur 2 Interrupt-Ports: INT0 und INT1

Auf dem SparkFun_Pro_Micro ist ein ATmega32U4. Ich wollte ihn auf dem nanoCUL V3.1 http://forum.fhem.de/index.php/topic,38561.0.html einsetzen
und habe die Verbindungen zum CC1101 schon mal per Drahtverhau nachgebildet bevor die Leiterplatte kommt. Dabei ging öfter die Verbindung verloren.

2015.11.05 00:46:34 1: /dev/ttyACM0 reappeared (CUL)
2015.11.05 00:46:37 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL)
2015.11.05 00:46:37 1: Cannot init /dev/ttyACM0, ignoring it (CUL)

Aber das hat dann wohl bei euch eine andere Ursache.

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),

RappaSan

Hab das schöne Teil erst einmal wieder auf Eis gelegt.
Mit den ständigen Verbindungsabbrüchen ist hier kein sinnvoller Einsatz möglich.
Warten wir auf Verbesserung in der Software.

beSmart

Hallo locutus.

Ich finde das Interface sehr interessant und möchte auch gern eins haben.

Ab wann kann man einen miniCUL mit 868 MHz und 2,4 GHz WLAN-Schnittstelle bei dir erwerben?

Oder kann ich mir das ganze auch aus einem Arduino_nano, ESP8266 ESP-01 WLAN-Funkmodul und einem CC1101-Modul selbst schustern?

Dank und Gruß


beSmart

locutus

@RappaSan & chris1284
Wir haben noch nicht alle Optionen ausgeschöpft. Ich kann die Verbindungsabbrüche reproduzieren. Auf der anderen Seite tritt das Phänomen mit meiner Konfiguration nicht auf. Zum einen betreibe ich den ESP8266 im STA MODE.
+++AT MODE 1
Zum anderen kommuniziert meine a-culfw mit geringerer Baudrate.
define miniCUL CUL 192.168.4.1:23@38400 0000

Ihr benötigt die passende Firmware.

@Omega-5
Du bist auf der falschen Baustelle! Der Quellcode für ATMEGA32U4 ist hier:
http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/

@beSmart
Zitat von: beSmart am 08 November 2015, 16:55:39
Ab wann kann man einen miniCUL mit 868 MHz und 2,4 GHz WLAN-Schnittstelle bei dir erwerben?
Sobald meine Bestellung aus China bei mir angekommen ist.
ZitatOder kann ich mir das ganze auch aus einem Arduino_nano, ESP8266 ESP-01 WLAN-Funkmodul und einem CC1101-Modul selbst schustern?
http://forum.fhem.de/index.php/topic,43267.0.html

RappaSan

Moin Damian.

Das probier ich doch gerne bei nächster Gelegenheit aus.

locutus

#25
Zitat von: chris1284 am 09 November 2015, 19:07:56
was bedeuted mode 1-3 , welche gibt es?
+++AT MODE <mode: 1= STA, 2= AP, 3=both>
Zitatgibt es eine doku zu den befehlen?
https://github.com/beckdac/ESP8266-transparent-bridge
Zitatmit der firmware, mode 1 und 38400 baud (muss das beim flashen im befehl auch angepasts werden?? ) bekomt fhem keine verbindung
An dem avrdude Befehl ändert sich nichts. Der Bootloader kommuniziert nach wie vor mit einer Baudrate von 57600. Einfach im USB Modus flashen. Danach Baudrate und Mode konfigurieren ...
+++AT BAUD 38400
+++AT MODE 1

Anschließend beide Jumper auf WLAN Modus setzen.

RappaSan

Hab hier ein Problem:
Beim flashen über USB oder WLAN kommt immer die Meldung:

"avrdude: stk500_recv(): programmer is not responding"
Nach 10 retrys ist schluß.

Was genau muß ich tun?
Kann ich das hexfile auch über die Windows Arduino IDE einspielen?

RappaSan

Ja. Den Fehler macht man hoffentlich nur einmal.
Gibt es ggf. noch weitere Prozesse, die auf den Port zugreifen?

RappaSan

#28
Langsam macht sich Resignation breit.

Ich krieg das Ding einfach nicht neu geflasht:

root@pi2:~# avrdude -p atmega328p -c arduino -P /dev/ttyUSB0 -F -b 57600 -U flash:w:miniCUL.hex:i
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude done.  Thank you.

Wenn ich das Ganze über WLAN flashen will, kommt zuvor noch die Meldung:

root@pi2:~# echo +++AT GPIO2 2 100 | nc 192.168.10.28 23 | avrdude -p atmega328p -c arduino -P net:192.168.10.28:23 -b 57600 -U flash:w:miniCUL.hex:i
ioctl("TIOCMGET"): Inappropriate ioctl for device
ioctl("TIOCMGET"): Inappropriate ioctl for device
avrdude: stk500_recv(): programmer is not responding



Wat nu?

RappaSan

Das ist einen Versuch wert, den Button hab ich auch schon entdeckt.
Aber momentan bin ich etwas geflasht: Der Stick läuft bereits über 12 Stunden ohne Störung.

Die neue Firmware kommt aber trotzdem drauf - wenn er mich läßt.