[gelöst] Wieder ein Anfänger mit 433 Selbstbau-nanoCUL (Empfangen unmöglich)?

Begonnen von titanbird, 18 April 2018, 18:33:16

Vorheriges Thema - Nächstes Thema

titanbird

Hallo an alle.

Bin neu in der Hausautomatisierungswelt.
Fhem habe ich mir soweit ohne Geräte bisher "eingerichtet" auf einem Server (NAS).
Auf dem PC habe ich mir Fhem ebenfalls installiert um erstmal rumzuspielen (Testumgebung).

Nun versuche ich mich an CMI Obi Steckdosen. Diese sind Selbstlernend und fungieren auf 433.92 MHz. Mit Fernbedienung. Im Set sind 3 Steckdosen.

Gesendet habe ich noch nichts erfolgreich... Ich muss erstmal den Homecode der Steckdosen "sniffen".
Wenn ich alles richtig verstanden habe!

Den CUL habe ich mir selber zusammengelötet. Die Verlötung habe ich triple-checked.

Geflasht hab ich a-culfw. Mein PC erkennt den nanoCUL also und in Fhem konnte ich das Gerät anlegen mit:
define CUL CUL /dev/ttyUSB0@38400 1234

Weitere Eingaben von mir:
verbose: 5
rfmode: SlowRF
model: nanoCUL


Zudem habe ich mal set raw x67 probiert (Debugmodus?) bzw. wieder zurück auf X27.

Dabei habe ich immer wieder zum Versuch auf die ON oder OFF Taste auf der Fernbedienung gedrückt. In Fhem tut sich rein gar nichts in dem Moment.

Genauere Infos zu der Hardware des Sticks:

  • CC1101 Wireless RF Transceiver 315/433/868/915MHZ + SMA Antenna Wireless Module
  • Arduino Nano V3.0 controller ATMEGA328P ATMEGA328 original FT232RL +USB cable

Weitere Infos zum CUL in Fhem:
FHTID: 1234
STATE: Initialized
TYPE: CUL
VERSION: V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
initString: X21
CUL ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB


Jetzt die Frage an Euch Cracks:
Was kann ich tun? Woran könnte es hapern?
Ziel wäre es doch erstmal, dass ich etwas sehe was der CUL empfängt? Um dann weiter zu machen. Please help ;-)
Wenn ich zu wenige Infos gegeben habe, bitte fragt mich, ich spuck sie sofort aus.

KölnSolar

Dann fangen wir mal mit dem richtigen Subforum an:Bitte den Post nach CUL/Hardware u. Firmware verschieb(Button unten links)

Auf den ersten Blick sieht der nano OK aus. Stell mal ein list ein.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

andies

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

titanbird

Scusi. Hab ich erledigt.

Gern. Also ein
list CUL
bringt mir aktuell
Internals:
   CFGFN     
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/ttyUSB0@38400 1234
   DeviceName /dev/ttyUSB0@38400
   FD         11
   FHTID      1234
   NAME       CUL
   NR         58
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-04-18 18:35:12   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-04-18 18:00:59   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-04-18 17:55:00   fhtbuf          No answer
     2018-04-18 17:54:53   raw             No answer
     2018-04-18 18:00:59   state           Initialized
     2018-04-18 17:54:46   uptime          0 00:00:25
     2018-04-18 17:55:35   version         V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
Attributes:
   model      nanoCUL
   rfmode     SlowRF
   verbose    5

Phantomato

Zitat von: titanbird am 18 April 2018, 18:33:16
Nun versuche ich mich an CMI Obi Steckdosen. Diese sind Selbstlernend und fungieren auf 433.92 MHz. Mit Fernbedienung. Im Set sind 3 Steckdosen.

Nun ja.. klingt fast so als wären diese steckdosen nicht InterTechno kompatibel. InterTechno sollte out of the box gehen. Alles andere wird kompliziert und Glückssache. Andere Vorschläge: Signalduino firmware nehmen oder den RFLink.

https://forum.fhem.de/index.php?topic=31997.0
Server: RaspberryPi4 4GB @Raspbian GNU/Linux 10 (buster), Docker, FHEM Docker | Homematic nanoCUL868 (VCCU) | Tasmota Switch & Sensors | Tasmota Zigbee | Zigbee2mqtt | SIGNALduino | Alexa & GoogleHome

titanbird

Danke für die Infos und den Link.
Den Link habe ich mir letztens schon angeschaut und habe zu Beginn probiert zu senden um die Steckdose im Lernmodus ansprechen zu können. Da hat sich nichts getan.
Daher wollte ich nun selbst zum Lesen kommen.

Hab im Wiki gelesen. So wie ich es verstanden habe kann ich aus meinem 433 CUL einen SIGNALduino machen mit der richtigen Firmware und sollte dann empfangen können.

Das hab ich eben gemacht:
update
shutdown restart
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
define SIGNALduino SIGNALduino /dev/ttyUSB0@57600
State war dann bei dem Device: Opened
attr SIGNALduino hardware nanoCC1101
attr SIGNALduino verbose 5
attr SIGNALduino debug 1
set SIGNALduino flash

Ein
list SIGNALduino
gibt gerade:
Internals:
   CFGFN     
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/ttyUSB0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/ttyUSB0@57600
   FD         4
   LASTDMSG   nothing
   NAME       SIGNALduino
   NR         31
   PARTIAL   
   STATE      opened
   TIME       1524087265
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   versionmodul v3.3.3-dev_17.04.
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-04-18 23:49:18   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-04-18 23:49:32   cmds             V R t X F S P C r W x e
     2018-04-18 23:49:36   config          MS=1;MU=1;MC=1
     2018-04-18 23:53:41   ping            OK
     2018-04-18 23:47:48   raw             ccFactoryReset done
     2018-04-18 23:54:01   state           opened
     2018-04-18 23:54:01   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     65
     68
     7
     72.1
     80
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     75
     79
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    5


Ich habe dann noch ein paar mal auf der Fernbedienung gedrückt (diese zeigt mit einer LED dass sie tut und dann wohl auch was sendet) aber im Eventmonitor oder Logfile in Fhem sehe ich in dem Moment gar nichts auftauchen.

Hab ich hier was falsch gemacht?

Beta-User

Bei diesen 433MHz-Dingern ist es nicht selten ein Ratespiel. Vielleicht kommst du damit weiter: https://wiki.fhem.de/wiki/Unbekannte_Funkprotokolle

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

Da wird's für meine Verhältnisse kompliziert.
Kann es eigentlich auch sein, dass eine Lötstelle doch nicht ganz korrekt ist oder dass das Funkmodul einfach tot ist? Kann durch das Löten durch die Hitze ein Element schaden auf der Platine davongetragen haben?
Ist es so, dass bei gänzlich unbekannten Geräten gar nichts geloggt wird (Receive) oder sollte eigentlich mit dem SIGNALduino immer etwas im Log zu sehen sein?

Habe hier noch einen Selbstbau 868 CUL, mit dem gleichen Model des Arduinos, nur eben mit anderem Funkmodul:
CC1101 Wireless Module Long Distance Transmission Antenna 868MHZ M115 For FSK GFSK ASK OOK MSK 64-byte SPI Interface Low Power
Kann man den denn für diesen Zweck auch ausprobieren und die 433 a-culfw drauf flashen?

KölnSolar

ZitatKann es eigentlich auch sein, dass eine Lötstelle doch nicht ganz korrekt ist oder dass das Funkmodul einfach tot ist? Kann durch das Löten durch die Hitze ein Element schaden auf der Platine davongetragen haben?
Kann natürlich immer oder der CC1101 war schon defekt. Deshalb ist es immer ungünstig den 1. Funktionstest mit eher unbekannten Geräten auszuführen.
ZitatKann es eigentlich auch sein, dass eine Lötstelle doch nicht ganz korrekt ist oder dass das Funkmodul einfach tot ist? Kann durch das Löten durch die Hitze ein Element schaden auf der Platine davongetragen haben?
Sowohl CUL als auch S'duino würden immer etwas loggen, wenn mit der richtigen Frequenz u. Modulationsverfahren(slowRF) etwas empfangen wird. Der S'duino ist für unbekannte Protokolle besser, weil man mit ihm auch empfangene Signalfolgen von ungewöhnlichen Protokollen "einfach" senden kann.

Beim Suchen habe ich den gefunden. Demnach scheint auch die Artikel-Nr. eine Rolle zu spielen, um welches Protokoll es sich handelt. Der Code des letzten Posts hat auf jeden Fall nicht annähernd etwas mit IT-Protokoll zu tun, sollte aber mit dem S'duino funktionieren.

ZitatKann man den denn für diesen Zweck auch ausprobieren und die 433 a-culfw drauf flashen?
Kannst Du. Hat halt nur ne schlechte Reichweite.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

titanbird

Danke :-)
Der eine Eintrag ist schon interessant, zwecks Benutzung der Soundkarte ;-)

Als ich mir Deine Antwort nun durchgelesen habe, bin ich zu dem Entschluss gekommen, dass ich erst einmal eine Steckdose oder ein Set mit DIP-Schaltern holen muss von einem "bekannten" Hersteller.
Dann testen. Dann kann ich sicher gehen, dass die Steckdosen tun sollten und weiß danach ob mein Funkmodul generell tut oder nicht.

Kannst Du mir günstige 433 Steckdosen empfehlen, die 100% mit Fhem gut und einfach funktionieren?
Damit ich mir diese mal in den Besitz hole und damit einen Test machen kann. Wäre hilfreich

dkreutz

Zitat von: titanbird am 19 April 2018, 09:32:32
Kannst Du mir günstige 433 Steckdosen empfehlen, die 100% mit Fhem gut und einfach funktionieren?
Damit ich mir diese mal in den Besitz hole und damit einen Test machen kann. Wäre hilfreich

Einen von Intertechno, z.B. das IT-1500 3er-Set. Gibt es in vielen Baumärkten (z.B. Bauhaus).
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

titanbird

Prima, ein Bauhaus haben wir und die führen die Dosen und sind vorrätig. Werde mir so ein Set holen und wieder berichten.
Wobei die IT-1500 sind bei denen als selbstlernende geführt. Mit DIP-Schalter wär's aber erstmal besser?

KölnSolar

ZitatMit DIP-Schalter wär's aber erstmal besser?
Das ist egal. Hauptsache Du kannst den Empfang testen. S'duino und CUL können beide Protokolle: Dip(IT-V1) u. selbstlernend(IT-V3).
Etwas günstiger aber nur per Post gibt es diese Dosen.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

titanbird

Werde es mal mit original Intertechnos probieren. Theor. sollte ja direkt was lesbar sein wenn ich die Fernbedienung davon drücke. Das probiere ich wie gesagt heute Abend auch mal mit dem 868er CUL aus (ich versuche da 433 zu flashen).

Beta-User

Zitat von: titanbird am 19 April 2018, 13:27:48
(ich versuche da 433 zu flashen).
Den brauchst du m.E. nicht umzuflashen, der kann auch so 433MHz senden (und vermutlich auch empfangen), wenn ccconf entsprechend eingestellt ist (und rfmode). Das mit der Frequenzumstellung erfolgt btw auch, wenn über einen 868-er 433-er Signale gesendet werden.

Letzteres ist aber nicht so besonders zu empfehlen, da jedesmal ins EEPROM geschrieben wird. Steht glaube ich auch irgendwo im Wiki.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Ich würde dir lieber WLAN Steckdosen empfehlen, das läuft weitaus besser, ist verschlüsselt und man erhält eine Rückmeldung ob geschaltet wurde.
Z.B. eine Sonoff S20 Steckdose, oder von Obi eine WiFi Steckdose für 9,99€ https://www.obi.de/hausfunksteuerung/wifi-stecker-schuko/p/2291706
Es gibt noch einige mehr, ich glaube mit bis zu 3 Relays als Steckdosenleisten. Wichtig ist nur, das ein ESP8266 dort drin steckt.

Löten kannst du ja und dann einfach Tasmota oder Espeasy drauf flashen und dann hast du was zuverlässiges...
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 19 April 2018, 22:29:47
Z.B. eine Sonoff S20 Steckdose, oder von Obi eine WiFi Steckdose für 9,99€ https://www.obi.de/hausfunksteuerung/wifi-stecker-schuko/p/2291706
Kennt jemand da eigentlich den Eigenverbrauch von den Teilen (mal abgesehen davon, dass dafür auch die ganze Netzwerkinfrastruktur zwingend laufen muß)?

Da sind übrigens die Baumarktsteckdosen teilweise auch nicht besser.

Wenn schon "was richtiges mit Rückkanal", dann würde ich aus diesen Gründen überlegen, ob es nicht sinnvoller ist, gleich auf "richtige Hausautomatisierungstechnik" zu setzen. Funksteckdosen mit Rückkanal gibt es nach meiner Kenntnis in jedem größeren Programm, Eigenverbrauch typischerweise <0,5W...

Just my2ct
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Zitat von: Beta-User am 19 April 2018, 22:52:11
Kennt jemand da eigentlich den Eigenverbrauch von den Teilen (mal abgesehen davon, dass dafür auch die ganze Netzwerkinfrastruktur zwingend laufen muß)?

Da sind übrigens die Baumarktsteckdosen teilweise auch nicht besser.

Wenn schon "was richtiges mit Rückkanal", dann würde ich aus diesen Gründen überlegen, ob es nicht sinnvoller ist, gleich auf "richtige Hausautomatisierungstechnik" zu setzen. Funksteckdosen mit Rückkanal gibt es nach meiner Kenntnis in jedem größeren Programm, Eigenverbrauch typischerweise <0,5W...

Ich habe selber nur mal mit einem Schätzeisen nachgemessen, wie er hier: https://www.youtube.com/watch?time_continue=1&v=iljg4oaH9O4
und ich komme auf die selben Ergebnisse.

Wegen der Netzwerkinfrastruktur.. Einen Router und Fhem Server, hat man ja denke ich eh am laufen. Mehr braucht man nicht.  :)

Wenn man Energie sparen möchte, kann man ein 4CH Sonoff verwenden, also 1x ESP mit 4 Relays. Anstatt 4 einzelne WiFi Steckdosen. Von denen habe ich mittlerweile zwei im Einsatz.
Ist halt nur mehr arbeit, das unterzubringen...

Ein weiterer Vorteil ist noch, das man Sensoren anschließen kann (Temperatursensoren oder Bewegungsmelder etc.) und das man es einfach über ein Webinterface konfigurieren kann.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

[Sorry für OT]
Na ja, 1,6-1,7W im "Normalbetrieb" ist nicht die Wucht, war aber nach den Specs des ESP8266 zu erwarten. Und dass das Netzteil an sich schon ca. 0,6W schluckt, ist m.E. auch nicht unbedingt state of the art. Wie viele von deinen ESP's hast du auf diese Art schlafen gelegt?

Was Netz angeht: "Hat man eh' am Laufen" ist schon richtig, aber an sich sollte man HA-Netz und den Rest (mind. logisch) trennen, und - so wie mark79 es beschrieben hat, benötigt man eben (mind.) genau das eine Gerät mehr (Router, ggf. weitere Switches und AP's). Nur wenn du den Server direkt als AP verwendest, müssen - ähnlich wie bei Kauflösungen nur zwei Geräte grade Strom haben, dass das ganze funktioniert.

Und dass die Welt im Übrigen für Bastler noch größer ist (und nicht nur beschränkt auf Bewegungsmelder und Temp-Sensoren), ist klar, aber da gibt es auch noch andere Optionen wie Asksin++, MySensors, KVP.... Nur zur Klarstellung: Modifikationen an Sonoff & Co können zu Problemen mit der Versicherung führen.

Damit sollten wir diesen OT-Exkurs aber wirklich beenden ;) .
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

1,7 Watt wenn das Relay angezogen ist und mit original Firmware. Baumarkt Funksteckdosen kommen da vermutlich auch über 1 Watt Verbrauch. :)

Wenn man bei den WiFi Steckdosen die originale (Cloud) Firmware runterhaut und stattdessen ESPeasy oder Tasmota (Opensource Firmware) drauf flasht, sehe ich keinen Grund das Netz abzusichern.
Weil das Gerät ab dann gar nicht mehr mit einer externen Cloud spricht, sondern alles lokal im Netz bleibt. Es gibt ein Fhem Modul für ESPeasy, oder halt über MQTT.

Der Nachteil ist dann nur noch, das die Hersteller APP fürs Handy nicht mehr funktioniert.
Aber auf die APP kann man gut verzichten, ich habe mir die selber noch nie angeschaut, weil man alles mit Fhem oder alexa schalten kann.
Dazu haben die Steckdosen mit der neuen Firmware auch eigenständige und mächtige Funktionen: https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

Ich habe von 7 WiFi Aktoren, bei 6 den Sleep Modus aktiviert. Das geht glaube ich nur bei der Tasmota Firmware.
2x 4CH, 2x Touch, 1x TH16 1x S20 Sonoffs und 1x Obi WiFi Steckdosen

Ich habe auch mit Funk angefangen, nanoCUL/Signalduino und dazu später noch pilight, viel gelernt, aber mittlerweile verfluche ich das ganze 433MHZ Zeugs:
Bei einer Funksteckdose bzw. Marke konnte der Nachbar mit seinem VW Autoschlüssel die Steckdose schalten.
Einige 433 Kerui Fensterkontakte senden bei Kälte nur noch einen "auf" Status.
Dann habe ich einen Funkschalter, welcher ziemlich schwach auf der Brust sendet und öfters die Signale nicht ankommen.
Und manche 433 Funkthermometer haben des öfteren auch Aussetzer. Die werde ich bald durch ein BME280/AMS2302 Sensor ersetzen, der jeweils an einer Sonoff Steckdose via 2,5mm Klinkenkabel hängt.

MySensors habe ich auch hier liegen, aber bisher noch nicht wirklich dazu gekommen was umzusetzen.
Ist ja nicht ganz OT, er ist noch neu und damit zeigt man ihn die anderen (neuen) Möglichkeiten auf. :)
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

[OT]
Es ist und bleibt hier OT. @TE: Bitte ggf. um klare Worte, wenn dich das nervt (habe aber eigentlich dann auch wirklich fertig).

Nur, um diesbezüglich keine Mißverständnisse aufkommen zu lassen:

Ich bin auch definitiv _kein_ Fan von dem 433MHz-"Gruscht" und stimme @mark79 dahingehend zu, dass sogar die WLAN-Geräte in vielen Fällen besser sind als dieser 433-er Mi*t. (Evtl. Qualitätsware ausgenommen, damit sich hier keiner veranlaßt sieht, "ja aber..." zu sagen).

Ob man getrennte Netze haben sollte, darüber kann und darf man lange streiten. Viele von den "langjährigen" Usern, vor allem, wenn sie aus der Admin-Welt kommen (ich bin nur User, siehe Nickname!), scheinen die Trennung tendenziell zu bevorzugen. Mir ist das zu viel Aufwand, u.A. deswegen meide ich WLAN-Devices, aber dennoch ist "mein" Netzwerk eben auch das meiner Familie - da ist leider nicht ganz auszuschließen, dass immer mal wieder Geräte auftauchen, die da nix zu suchen haben (Für was richte ich ein Gastnetz ein?!?). Solange jemand eigenwillige JSON-Strings senden können müßte, um das Licht auszuschalten oder die Stereoanlage lauter zu drehen, geht das grade noch, aber es nervt mich schon, dass es trouble gibt, wenn ich das Passwort ändern will, die Fritte spinnt, alles mögliche nach Hause telefonieren will usw.. Also: Bogen drum, lieber direkte Anbindung. Ich hatte das "Glück", vor ESPEasy mehrere ESP in der Hand gehabt zu haben und wegen deren Zickigkeit dann rechtzeitig bei MySensors gelandet zu sein :) .

Von daher: Viel Spaß beim Einarbeiten in das Thema, und vielleicht kommen wir in ein paar Jahren mal dazu darüber zu quatschen, was wir alles besser anders gemacht hätten. Ich hätte mir neben der ESP-Geschichte diverse Versuche mit PI-GPIO's sparen sollen.
[/OT]

Partly back to topic :
Besser Finger weg von PI-GPIO's (Stichwort pilight). Das ist - abgesehen vom HM-PI-Modul und einer RTC - für Anfänger m.E. zu anfällig, da die sehr prozessornah sind. Ich habe mir jedenfalls den ersten PI mit Geh-Versuchen mit 1wire teilweise zerschossen. Außerdem halte ich die damit einhergehende Vermischung von Steuerungslogik und Hardware für tendenziell problematisch; ich bin jedenfalls sehr froh, dass ich _keinen_ PI mehr als Server einsetze.

Wieder nur just my2ct.

Grüße jedenfalls,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Bzgl. Pilights, das stimmt.. Ich hatte die Funk Hardware auch anfangs an den GPIO Ports betrieben, aber da ging die CPU Last ziemlich in die Höhe. Abhilfe schaffte ein Arduino Nano dazwischen zu schalten.
Das ganze ist ein ziemliches gefrickel und ich will auch von pilight weg. Aber mir blieb anfangs keine Wahl, weil ich 3 Temperatursensoren (von Pearl) nur mit pilight zum laufen bekommen habe.
Nach dem Umstieg von RPi1 zum Rock64, ist mir der pilight Daemon vor kurzem Amok gelaufen und hat auf einen Core 100% CPU Last erzeugt und die CPU Temp war fast bei 80 Grad. Zum Glück hatte ich mir ein TEMP Warnung als Benachrichtigung eingerichtet.

Getrennte Netze kann man ja machen, ich habe es nicht umgesetzt und halte das auch nicht für nötig. Besonders nicht, wenn man auf unverschlüsselte Funk Kommunikation setzt.
Man kann in ESPEasy oder Tasmota ein Backup WiFi Netzwerk konfiguieren. Wenn man das WLAN Kennwort wechseln möchte, würde das auch schnell über die WPS Funktion klappen.

Zickig laufen die ESPs bei mir nicht, sondern im gegenteil sehr stabil und zuverlässig. Vielleicht hattest du nur Pech, oder hast es am Anfang der Entwicklung ausprobiert.
Ich habe noch mehr ESP für IR Transmitter, oder als BLE Anwesenheitskontrolle, ESP_HMUART und einer steckt sogar im Briefkasten mit 2 AA Eneloops und die Batterien halten auch mehr als ein Jahr durch.

Das beste wäre natürlich alles über Kabel anzubinden, falls ich mal ein Haus bauen sollte, dann.... :)

So ich bin jetzt aber auch raus, wurde alles gesagt und wir sind uns in bestimmten Punkten sogar einig.  ;)

Wünsche allen ein schönes Wochenende!


Viele Grüße
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

[definitiv OT, sorry]
Hast du für die Pearls auch mal die dev-Version vom Signalduino ausprobiert?
Wenn das noch nicht implementiert ist, kann evtl. sidey&co helfen, die Hardware scheint ja doch eine gewisse Verbreitung zu haben.

Was deine Server-Hardware angeht: Jedenfalls auf den ersten Blick sieht die HW valide aus. Vielleicht magst du einen Eintrag für https://wiki.fhem.de/wiki/Kategorie:Server_Hardware erstellen? (Kann auch ein Thread hier sein, kann das gerne dann übertragen, wenn du einverstanden bist).

Und: A cable is a cable, da hast du recht. Zumindest in unserm Altbau-Keller ist eh' weitestgehend Aufputz angesagt. Bin daher ein RS485-MySensors-Fan :) .

Gruß, Beta-User
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Zitat von: Beta-User am 20 April 2018, 14:20:07
Hast du für die Pearls auch mal die dev-Version vom Signalduino ausprobiert?
Ich hatte das vor etwa 2 Wochen noch mal ausprobiert, jedoch mit der Signalduino FW (CC1101) auf einem ESP8266  ;D Weil bei mir schon alle USB + HUB Anschlüsse belegt sind. :(
Ausprobiert hatte ich das 3.3.1 Release Candidate 4 von hier: https://github.com/RFD-FHEM/SIGNALESP/releases
Damit wurden die leider auch nicht erkannt.

Zitat von: Beta-User am 20 April 2018, 14:20:07
Wenn das noch nicht implementiert ist, kann evtl. sidey&co helfen, die Hardware scheint ja doch eine gewisse Verbreitung zu haben.
Ich kann ihn die Tage mal anschreiben, sind ja auch relativ günstig und die verschiedenen Sensoren von Pearl haben wohl alle das selbe Protokoll... dann könnte ich die Teile wenigstens noch für was anderes verwenden. Hier gibt es zu den Pearl Dingern auch Informationen: https://forum.pilight.org/showthread.php?tid=3080

Zitat von: Beta-User am 20 April 2018, 14:20:07
Was deine Server-Hardware angeht: Jedenfalls auf den ersten Blick sieht die HW valide aus. Vielleicht magst du einen Eintrag für https://wiki.fhem.de/wiki/Kategorie:Server_Hardware erstellen? (Kann auch ein Thread hier sein, kann das gerne dann übertragen, wenn du einverstanden bist).
Was meinst du genau, über das Rock64 Board?
Das läuft bisher ganz gut und auch schnell, USB, Netzwerk und Sound funktionieren stabil. Was nur nicht geht, ist die HMUART MOD RPI PCB Platine via GPIO und bei Python GPIO fehlen ein paar Funktionen. An letzteren wird aber noch dran gearbeitet.
Ich kann darüber was schreiben, aber erst nächste Woche. Habe für das WE noch andere Baustellen eingeplant.

Zitat von: Beta-User am 20 April 2018, 14:20:07
Und: A cable is a cable, da hast du recht. Zumindest in unserm Altbau-Keller ist eh' weitestgehend Aufputz angesagt. Bin daher ein RS485-MySensors-Fan :) .
Ja es geht nix über das gute alte Kabel. :)


Viele Grüße
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 20 April 2018, 14:54:50
Weil bei mir schon alle USB + HUB Anschlüsse belegt sind. :(
Genug USB-Anschlüsse waren einer der Gründe für die Wahl des T5740: 8xUSB bei moderatem Stromverbrauch, das war den Test wert...

Zitat
Ausprobiert hatte ich das 3.3.1 Release Candidate 4
Dann dürfte es da noch keine news geben. Am besten für weitere Protokolle einen issue uf gitub aufmachen, wenn ich das richtig verstanden habe (mit weiteren Angaben aus dem log).

Btw.: Mit einem MapleCUx kannst du bis zu 4 CC1101-Transceiver nutzen (aculfw) - jedenfalls für 433MHz ist da auch einiges implementiert, aber das hast du sicher als erstes probiert? Dann wären da an einem Maple noch 2 serielle Schnittstellen, das würde für das PI-PCB reichen, dazu RX+TX vom Signalduino an die andere, dann sollten wieder USB-Ports frei werden ;) .
Zitat
Was meinst du genau, über das Rock64 Board?
Yup, eilt auch nicht. Finde es aber interessant zu sehen, dass es noch Leute gibt, denen der PI mit der SD-Karte und dem USB-Flaschenhals suspekt ist. Und vom Preis-Leistungsverhältnis her sieht das auch ok aus - je nachdem halt auch, was man schon an Equipment hat.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Zitat von: Beta-User am 20 April 2018, 15:08:57
Genug USB-Anschlüsse waren einer der Gründe für die Wahl des T5740: 8xUSB bei moderatem Stromverbrauch, das war den Test wert...
Stimmt davon kann man irgendwie nie genug haben. :D
Am RPi1 hatte ich inkl. USB Hub nur 5 Slots und die waren alle belegt. Eine DAC Soundkarte, weil die Soundqualität am RPi so schlecht war.. Dann noch 2x Bluetooth Sticks, ein nanoCUL und Pilight.
Die Soundqualität beim Rock ist besser, so das die Soundkarte nun weg fällt.
Ein x86 hat auch seine Vorteile, stabile Hardware mit Sata etc. und sehr gute Treiberunterstützung, aber etwas höherer Stromverbrauch.

Ich habe mit meinen Schätzeisen nach gemessen, im Idle 1,3 Watt und bei Vollast (CPU) mit einem Benchmark Programm 2,6 Watt. Kann ich irgendwie immer noch nicht so richtig glauben.
Ich habe vor ein paar tagen noch MySQL installiert und Nextcloud, bei letzterem traue ich mich nur noch nicht, den Port nach außen freizugeben. :D

Zitat von: Beta-User
Dann dürfte es da noch keine news geben. Am besten für weitere Protokolle einen issue uf gitub aufmachen, wenn ich das richtig verstanden habe (mit weiteren Angaben aus dem log).
Ja Github, muss mir aber erst noch ein Account anlegen. Dann kann ich auch direkt noch den Entwickler für die Debian Distro (ayufan-rock64) anschreiben, wie man den UART auf 115200 Baud setzt. Dann würde evtl. auch die HM Platine am GPIO Leiste funktionieren. Die scheint laut Berichten fix auf 150000 Baud eingestellt zu sein.

Zitat von: Beta-User
Btw.: Mit einem MapleCUx kannst du bis zu 4 CC1101-Transceiver nutzen (aculfw) - jedenfalls für 433MHz ist da auch einiges implementiert, aber das hast du sicher als erstes probiert? Dann wären da an einem Maple noch 2 serielle Schnittstellen, das würde für das PI-PCB reichen, dazu RX+TX vom Signalduino an die andere, dann sollten wieder USB-Ports frei werden ;) .Yup, eilt auch nicht.
MapleCUx kenne ich nur vom Namen her. Aber ich habe mich immer gefragt, wozu man 4x CC1101  benötigt?! Zwei CC1101 kann ich verstehen, auf unterschiedlichen Frequenzen.

Kann man beim Maple CUL zwei verschiedene FW parallel betreiben? Also z.B. einmal acul-fw und einmal Signalduino?
Aber wenn ich da noch die HM Platine anschließen könnte, wäre das schon was. :) Dann muss ich mir mal eine besorgen. :)

Zitat von: Beta-User
Finde es aber interessant zu sehen, dass es noch Leute gibt, denen der PI mit der SD-Karte und dem USB-Flaschenhals suspekt ist. Und vom Preis-Leistungsverhältnis her sieht das auch ok aus - je nachdem halt auch, was man schon an Equipment hat.
Das sehe ich auch so, der war mir zu langsam, zumal das Netzwerk immer noch am USB2 Port hängt. :/
Der einzige Vortei beim RPi ist, dass das teil schon so alt ist und es eine große Community gibt und dadurch guten Support.
Aber für ein headless Server kann man den Schritt schon gehen, weil man keine Grafik Hardwareunterstützung benötigt.

Hier haben einige ein ODROID oder Orange PI, letztere sind auch noch günstiger, aber das liegt wohl eher am niedrigen Ram Speicher.
Der Rock64 hat übrigens noch Hardwareverschlüsslung onboard und man könnte ein VPN darauf betreiben.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

titanbird

Also Ihr, also mich stört das gar nicht dass Ihr mal etwas mehr schreibt und auch etwas weiter ausholt. Hab's gerne durchgelesen. Wobei ich bei vielem da schon aussteige wenn Ihr da mit Begriffen umherwerft  :o ;D

Es gibt aber leider keine (guten) Neuigkeiten zum Thema 433 Steckdose "sniffen".

Was ich jetzt probiert habe, sind folgende Konstellationen:

Arduino nano mit 433 Modul - a-culfw geflashed
Arduino nano mit 433 Modul - SIGNALduino geflashed
Arduino nano mit 868 Modul - a-culfw geflashed
Arduino nano mit 868 Modul - SIGNALduino geflashed

Jedes mal dann auf beiden Fernbedienungen (die CMI Obi Steckdosen und auch die neuen IT-1500 Steckdosen aus dem Bauhaus) rumgedrückt. Entfernung zur Antenne: 2-10cm.
Fhem Event Monitor und Logfile offen (beim Logfile dann immer F5 im Browser gedrückt). Außer die CUL Meldungen wie INIT vom CUL oder auch mal ein
2018.04.20 18:42:39 5: SW: ?
2018.04.20 18:42:39 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of A B C E e F f G i K l M N
2018.04.20 18:42:39 5: CUL/RAW (ReadAnswer):  R T t U V W X x Z

hat sich gar nichts getan zwecks Empfangen von den Daten.

Hier nochmal die Infos zu den einzelnen Konstellationen:


Arduino nano mit 433 Modul - a-culfw geflashed
Info:
Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   CUL_MSGCNT 1
   CUL_TIME   2018-04-20 23:11:10
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/ttyUSB0@38400 1234
   DeviceName /dev/ttyUSB0@38400
   FD         12
   FHTID      1234
   NAME       CUL
   NR         21
   PARTIAL   
   RAWMSG     ��V���ꊨ������U� UUP�X�Q�QT����.UET�T�U����*Q
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-04-20 23:23:01   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-04-20 23:22:40   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-04-20 18:45:59   fhtbuf          No answer
     2018-04-20 23:22:40   state           Initialized
Attributes:
   model      nanoCUL
   rfmode     SlowRF
   verbose    5

Hier mal aus dem Log. Unten nichts obwohl alle Tasten 1x gedrückt:
2018.04.20 23:22:37 3: Setting CUL serial parameters to 38400,8,N,1
2018.04.20 23:22:37 5: SW: V
2018.04.20 23:22:40 5: SW: V
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): V 1.
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): 26.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)

2018.04.20 23:22:40 5: SW: ?
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of A B C e F f G i K L l M N
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer):  R T t U V W X x

2018.04.20 23:22:40 3: CUL: Possible commands: ABCeFfGiKLlMNRTtUVWXx
2018.04.20 23:22:40 5: SW: X21
2018.04.20 23:22:40 5: SW: T01
2018.04.20 23:22:40 5: CUL/RAW (ReadAnswer): 1234

2018.04.20 23:22:40 5: GOT CUL fhtid: 1234
2018.04.20 23:22:40 1: /dev/ttyUSB0 reappeared (CUL)
2018.04.20 23:23:01 5: SW: C0D
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C0D = 10 / 16

2018.04.20 23:23:01 5: SW: C0E
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C0E = B0 / 176

2018.04.20 23:23:01 5: SW: C0F
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C0F = 71 / 113

2018.04.20 23:23:01 5: SW: C10
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C10 = 57 / 87

2018.04.20 23:23:01 5: SW: C1B
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C1B = 07 /  7

2018.04.20 23:23:01 5: SW: C1D
2018.04.20 23:23:01 5: CUL/RAW (ReadAnswer): C1D = 90 / 144


Arduino nano mit 433 Modul - SIGNALduino geflashed
Info:
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/ttyUSB0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/ttyUSB0@57600
   FD         4
   LASTDMSG   nothing
   NAME       SIGNALduino
   NR         20
   PARTIAL   
   STATE      opened
   TIME       1524258744
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   versionmodul v3.3.3-dev_17.04.
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-04-20 23:12:41   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2018-04-18 23:49:32   cmds            V R t X F S P C r W x e
     2018-04-18 23:49:36   config          MS=1;MU=1;MC=1
     2018-04-20 23:15:49   ping            OK
     2018-04-18 23:47:48   raw             ccFactoryReset done
     2018-04-20 23:14:49   state           opened
     2018-04-20 23:14:49   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     65
     68
     7
     72.1
     80
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     75
     79
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    5

Mal was aus dem Logfile (unten leider nichts erschienen obwohl Tasten gedrückt):
2018.04.20 23:14:47 3: SIGNALduino reset
2018.04.20 23:14:47 3: Opening SIGNALduino device /dev/ttyUSB0
2018.04.20 23:14:47 3: Setting SIGNALduino serial parameters to 57600,8,N,1
2018.04.20 23:14:47 1: SIGNALduino/define: /dev/ttyUSB0@57600
2018.04.20 23:14:47 1: SIGNALduino/init: /dev/ttyUSB0@57600
2018.04.20 23:14:47 3: SIGNALduino device opened
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: /Using sF
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: Using sF/IFO
Reading values fom eeprom
CCVersion=4
CCPartnu
2018.04.20 23:14:48 4: SIGNALduino/msg READ: Using sFIFO
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: Using sFIFO
2018.04.20 23:14:48 4: SIGNALduino/msg READ: Reading values fom eeprom
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: Reading values fom eeprom
2018.04.20 23:14:48 4: SIGNALduino/msg READ: CCVersion=4
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: CCVersion=4
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: CCPartnu/m=0
CC1101 found
Starting timerjob

2018.04.20 23:14:48 4: SIGNALduino/msg READ: CCPartnum=0
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: CCPartnum=0
2018.04.20 23:14:48 4: SIGNALduino/msg READ: CC1101 found
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: CC1101 found
2018.04.20 23:14:48 4: SIGNALduino/msg READ: Starting timerjob
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: Starting timerjob
2018.04.20 23:14:48 3: SIGNALduino/init: disable receiver (XQ)
2018.04.20 23:14:48 5: SIGNALduino SW: XQ
2018.04.20 23:14:48 5: SIGNALduino/RAW READ: /receiver enabled

2018.04.20 23:14:48 4: SIGNALduino/msg READ: receiver enabled
2018.04.20 23:14:48 5: SIGNALduino/noMsg Parse: receiver enabled
2018.04.20 23:14:49 3: SIGNALduino/init: get version, retry = 0
2018.04.20 23:14:49 5: SIGNALduino SW: V
2018.04.20 23:14:49 5: SIGNALduino/RAW READ: /V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50

2018.04.20 23:14:49 4: SIGNALduino/msg READ: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
2018.04.20 23:14:49 5: SIGNALduino/noMsg Parse: V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
2018.04.20 23:14:49 5: SIGNALduino/msg READ: regexp=V\s.*SIGNAL(duino|ESP).* cmd=version msg=V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
2018.04.20 23:14:49 2: SIGNALduino: initialized. v3.3.3-dev_17.04.
2018.04.20 23:14:49 5: SIGNALduino SW: XE
2018.04.20 23:14:49 3: SIGNALduino/init: enable receiver (XE)


Arduino nano mit 868 Modul - a-culfw geflashed
Info:

Save config
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Internals:
   CMDS       ABCEeFfGiKlMNRTtUVWXxZ
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/ttyUSB0@38400 1234
   DeviceName /dev/ttyUSB0@38400
   FD         13
   FHTID      1234
   NAME       CUL
   NR         21
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.02 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-04-20 23:07:52   ccconf          freq:3322.000MHz bWidth:58KHz rAmpl:33dB sens:8dB
     2018-04-20 23:06:59   cmds             A B C E e F f G i K l M N R T t U V W X x Z
     2018-04-20 18:45:59   fhtbuf          No answer
     2018-04-20 23:06:59   state           Initialized
Attributes:
   model      nanoCUL
   rfmode     SlowRF
   verbose    5


Arduino nano mit 868 Modul - SIGNALduino geflashed
Info:
Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        /dev/ttyUSB0@57600
   DMSG       nothing
   DevState   initialized
   DeviceName /dev/ttyUSB0@57600
   FD         10
   LASTDMSG   nothing
   NAME       SIGNALduino
   NR         20
   PARTIAL   
   STATE      opened
   TIME       1524256787
   TYPE       SIGNALduino
   sendworking 0
   version    V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   versionmodul v3.3.3-dev_17.04.
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^u30#.*
     18:FLAMINGO ^P13#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
   READINGS:
     2018-04-20 22:51:20   ccconf          freq:790.264MHz bWidth:541KHz rAmpl:24dB sens:16dB  (DataRate:955322.27Baud)
     2018-04-18 23:49:32   cmds            V R t X F S P C r W x e
     2018-04-18 23:49:36   config          MS=1;MU=1;MC=1
     2018-04-20 23:00:44   ping            OK
     2018-04-18 23:47:48   raw             ccFactoryReset done
     2018-04-20 22:48:44   state           opened
     2018-04-20 22:48:44   version         V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
   getcmd:
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     65
     68
     7
     72.1
     80
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     75
     79
     8
     9
Attributes:
   debug      1
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   hardware   nanoCC1101
   verbose    5



Also irgendwas muss ich hier doch komplett falsch machen... Ich kann mir nicht vorstellen dass das so schwer sein kann, irgendwo übersehe ich doch was?!
Die ccconf          freq:3322.000MHz ist auch merkwürdig. Jedes mal wenn ich ccconf abfrage, sind da willkürliche, teils sehr hohe Werte. Ich glaube nur beim 868er CUL.

Hoffe Ihr habt wieder ein paar Tipps was ich noch so machen/beachten könnte.

mark79

Hi,

ich kann dir leider auch nicht so wirklich weiter helfen, hier ist ein List von meinem (arduino) nanoCUL:

Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXx
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT::OREGON::Hideki:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9SZV11H-if00-port0@38400 4444
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9SZV11H-if00-port0@38400
   FD         17
   FHTID      4444
   NAME       nanoCUL
   NR         248
   PARTIAL   
   RAWMSG     om8AAAA0F6
   RSSI       -28.5
   STATE      Initialized
   TIME       1524335202.38965
   TYPE       CUL
   VERSION    V 1.26.01 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   nanoCUL_MSGCNT 6242
   nanoCUL_TIME 2018-04-21 20:32:26
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-01-21 15:57:06   ccconf          freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB
     2018-04-20 00:03:01   cmds             A B C e F f G i K L l M N R T t U V W X x
     2018-04-15 15:56:01   raw             is11DD1FDDDDF1
     2018-04-21 20:32:26   state           Initialized
Attributes:
   DbLogExclude .*
   model      nanoCUL
   rfmode     SlowRF
   verbose    5


Setzte evtl. mal die bWidth hoch. Ansonsten müssen dir da leider andere helfen, von den Funkgedöns habe ich zu wenig Ahnung.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

RalfRog

Hi
Wenn Du schon die Verbindungen zwischen Arduino und dem CC1100 geprüft hast (bei dem Fehlerbild insbesondere GD00 und GD02) ist vielleicht tatsächlich der Sendeteil des CC1100 defekt.
Ein CUL auf 868 MHz kann zwar 433 senden hört aber auf der Frequenz 433 nicht mit.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Beta-User

Zitat von: titanbird am 20 April 2018, 23:26:27
Die ccconf          freq:3322.000MHz ist auch merkwürdig. Jedes mal wenn ich ccconf abfrage, sind da willkürliche, teils sehr hohe Werte. Ich glaube nur beim 868er CUL.
Wenn die Antwort auf ccconf jedes Mal anders ist, stimmt entweder die Verkabelung nicht, oder der CC1101 ist kaputt. Das solltest du prüfen, ob das wirklich nur "beim 868-er CUL" so ist (oder ob das nur zufällig so war, dass nach dem flashen ein Wackelkontakt auf diese Art erkennbar war).
Und wenn du einen für 433MHz optimierten Transceiver verwendest, macht eine Firmware für 868MHz keinen großen Sinn. aculfw oder Signalduino sind da m.E. die einzigen beiden Varianten (Signalduino muß nach dem flashen übrigens einmal resettet werden ("raw e"?).

Zitat von: titanbird am 20 April 2018, 23:26:27
Also Ihr, also mich stört das gar nicht dass Ihr mal etwas mehr schreibt und auch etwas weiter ausholt. Hab's gerne durchgelesen. Wobei ich bei vielem da schon aussteige wenn Ihr da mit Begriffen umherwerft  :o ;D
Danke für die Rückmeldung, die Stichworte waren für die SuFu gedacht ;) .

Zitat von: mark79 am 20 April 2018, 22:21:39
Ich habe mit meinen Schätzeisen nach gemessen, im Idle 1,3 Watt und bei Vollast (CPU) mit einem Benchmark Programm 2,6 Watt. Kann ich irgendwie immer noch nicht so richtig glauben.
Das kommt mir auch sehr wenig vor, aber selbst wenn es 5W sind, ist es für die Leistung doch ein sehr guter Wert!

Zitat
[...]wie man den UART auf 115200 Baud setzt. Dann würde evtl. auch die HM Platine am GPIO Leiste funktionieren. Die scheint laut Berichten fix auf 150000 Baud eingestellt zu sein.
Genau solche Sachen sind es dann, die im Wiki für mutige Nachahmer gut aufgehoben wären...

Zitat
MapleCUx kenne ich nur vom Namen her. Aber ich habe mich immer gefragt, wozu man 4x CC1101  benötigt?! Zwei CC1101 kann ich verstehen, auf unterschiedlichen Frequenzen.
Die Frage hatte ich mir früher auch mal gestellt, mittlerweile finde ich 4 Transceiver fast etwas wenig ;) : 2*SlowRF (433/868), HM (ok, da baut man besser das PI-Modul ran), MAX... Dann hast du noch kein ZWave...

Zitat
Kann man beim Maple CUL zwei verschiedene FW parallel betreiben?
Nein, es ist ein Microcontroller, also eine Firmware, die dann aber auf den verschiedenen Transceivern unterschiedliche Protokolle senden und empfangen kann (s.o.).

Zitat
[...] Signalduino?
Den kannst du dann an der 2. durchgereichten seriellen Schnittstelle anschließen (separater Microcontroller, ein mit RX/TX fix und fertig verdrahteter Sockel für einen Pro Mini ist auf der Platine schon drauf, soweit ich mich entsinne (für ein MySensors-GW...).

Kurz: Das Ding ist ein richtiges "Schweizer Taschenmesser", gehört damit aber nicht zu den "ganz einfachen" Devices...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

Moin zusammen.

ZitatWenn die Antwort auf ccconf jedes Mal anders ist, stimmt entweder die Verkabelung nicht, oder der CC1101 ist kaputt. Das solltest du prüfen, ob das wirklich nur "beim 868-er CUL" so ist (oder ob das nur zufällig so war, dass nach dem flashen ein Wackelkontakt auf diese Art erkennbar war).

Das heißt ich muss weiter "ausprobieren" und testen.

Ich werde heute Abend nochmal:

  • die PIN-Belegung erneut prüfen (und nur am 433 Modul, denn das interessiert uns ja nur)
  • nochmal die a-culfw downloaden, compilieren und flashen und mir dann die eingestelle Frequenz ansehen (ob die wieder zu hoch ist oder korrekt auf 433 steht) und natürlich testen mit der Fernbedienung

ZitatWenn Du schon die Verbindungen zwischen Arduino und dem CC1100 geprüft hast (bei dem Fehlerbild insbesondere GD00 und GD02) ist vielleicht tatsächlich der Sendeteil des CC1100 defekt.
Mit Sendeteil meinst Du damit dann auch den Empfänger, richtig?

ZitatUnd wenn du einen für 433MHz optimierten Transceiver verwendest, macht eine Firmware für 868MHz keinen großen Sinn. aculfw oder Signalduino sind da m.E. die einzigen beiden Varianten
Hol mich hier bitte nochmal kurz "für Dumme" ab :-D   Ich habe einen 433 Transreceiver. Aber ich dachte die a-culfw (oder auch die culfw) kann man "in den 433" Modus versetzen. Man muss vorher die board.h anpassen wenn ich das richtig verstanden habe.
Bei der a-culfw ist das in der board.h:
/* if you are using a CC1101 module for 868MHz disable the next line */
#if defined (nanoCUL433)
#define HAS_CC1100_433
#endif

und in der culfw ist das in der board.h:
/* if you are using a CC1101 module for 868MHz disable the next line */
/*#define HAS_CC1100_433*/

Habe ich irgendwo denn versehentlich eine 868 Firmware geflasht die ausschließlich für 868 Module ausgelegt ist?

Desweiteren habe ich folgende Idee.
Kann ich mir denn nicht auf einem Steckboard mal einen arduino Nano hernehmen, ein paar Steckkabel und dieses RXB6 Modul hier:
https://www.aliexpress.com/item/RXB6-433Mhz-Superheterodyne-Wireless-Receiver-Module-ARM-AVR/32712577501.html

Oder dieses RXB8 Modul hier:
https://www.aliexpress.com/item/RXB8-433Mhz-Superheterodyne-Wireless-Receiver-Module-Perfect-for-Arduino-AVR/32821761257.html

Diese mir auf dem Board zusammenstecken und damit die Codes der Fernbedienung empfangen und im Fhem anschauen?
Oder bin ich da total auf dem Holzweg.
Zum Arduino Nano mit einem RXB6 zum Beispiel habe ich nicht wirklich das konkretes im Netz gefunden bis auf das hier:
https://forum.pimatic.org/topic/202/4-homeduino-433-mhz-sending-receiving-and-even-more/2
Bin mir nun unsicher ob ich das mal einfach so zusammenkaufen/zusammenstecken soll als Versuch oder ob sich das nicht lohnt.
Dort ist von "Homeduino" die Rede. Ich frage mich wie gesagt ob ich die a-culfw "im 433 Modus" auf dem Arduino belassen kann und eben den RXB6 nehmen kann?

Kennt Ihr Euch damit aus, funktioniert das mit der aculfw und wäre das ein Versuch wert?
Was sind die Unterschiede zwischen dem RXB6 und dem RXB8 und wie finde ich raus welche für meine Idee kompatibel sind?
:-)

Beta-User

Zitat von: titanbird am 07 Mai 2018, 09:50:34
Hol mich hier bitte nochmal kurz "für Dumme" ab :-D   Ich habe einen 433 Transreceiver.
Nicht ganz: du hast auf dem Transceiver-Modul einen Chip, der - aus dem Kopf - alles zwischen 350MHz und 915MHz empfangen und senden kann. Wie gut das klappt, ist eine Frage der Dinge, die um den Transceiverchip "drumrum" verbaut sind (siehe Modulbeschriebung im Wiki), also vor allem der Antenne. Und eine 433-er Antennen-Beschaltung ist halt nicht (gut) für 868MHz geeignet. ABER: die SW ist im Kern dieselbe, wie eben auch der eigentliche Transceiver-Chip; es werden ggf. andere Standardeinstellungen vorgenommen und andere Protokolle aktiviert. Aber mit einer 868-er firmware eher keine aus dem 433MHz-Bereich ;) .

Also nochmal kurz gefaßt: Wenn du 433MHz haben willst, nimm die aculfw, bzw., wenn du Alternativen suchst stand das Stichwort "Signalduino" ja schon im Raum; da geht auch der RXBx. Es muß dann nur die jeweils passende firmware ausgewählt werden. Aber (a-)culfw und RXBx geht nicht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

OK, Merci :-)
Was ich jetzt gleich gemacht habe, hab mir bestellt:

  • (mein erstes) Steckboard
  • paar Kabel
  • ein FS1000A Sendemodul (dabei ist gleich ein billiges XY-MK-5V-Empfängermodul)
  • und gleich noch ein besseres RXB6 Empfangsmodul

Damit werde ich dann was zusammenstecken nach Anleitung und SIGNALduino nochmal sauber nach Anleitung flashen.
Sagen wir es so: Wenn dann immer noch nichts reinkommt wenn ich auf der Fernbedienung drücke, muss was anderes ganz faul sein, oder? ;-)
Eine Frage noch zur SIGNALduino Firmware:
ZitatEs muß dann nur die jeweils passende firmware ausgewählt werden.
Ich werde für die Testvariante auf dem Steckboard SIGNALduino verwenden. Muss ich hier auch noch auf eine "passende Variante" achten oder ist und bleibt SIGNALduino SIGNALduino?

Wie kann man sicherstellen oder testen, dass z.B. das Sende- und Empfangsmodul an meinem "433 CUL" defekt ist?
Ich habe letztens mal einen Raw Code an den CUL gesendet, der testet, ob der Empfang eingeschaltet ist.
https://wiki.fhem.de/wiki/CUL
Ist Empfang eingeschaltet ?
get myCUL raw C35 (13 = ja, z. b.: C35 = 0D / 13)

Da kam bei mir 13 bzw. "OK" zurück. Bedeutet das, dass mein CUL keine Defekte hat, wohl eher nicht?
Wisst Ihr denn ich tappe da ja schon sehr im dunkeln. Ist es die Firmware, die Verkabelung, oder doch ein Defekt (? zu viele Unbekannte :-D ). Wenn ich wenigstens ausschließen könnte, dass etwas defekt ist, wäre das schon mal was.
Natürlich kann ich auch 5 Mal etwas zusammenlöten / auf dem Board stecken und austesten, auch eine Möglichkeit :-D ;-)

Beta-User

Wenn über die firmware bzw. die Anfrage der raw-Codes was zurückkommt, ist das erst mal gut, dann ist zumindest der CC1101 richtig verbunden (Wackler aber nicht ausgeschlossen). Für einen ordentlichen Funktionstest müßte man irgendwas verwenden, von dem man weiß, dass es erkannt wird (IT-Fernbedienung).

Ob der diskret aufgebaute Signalduino mehr hergibt, wage ich zu bezweifeln, es bleibt eher bei dem hier:
Zitat von: Phantomato am 18 April 2018, 21:58:03
Nun ja.. klingt fast so als wären diese steckdosen nicht InterTechno kompatibel. InterTechno sollte out of the box gehen. Alles andere wird kompliziert und Glückssache.
Ergo: Kauf' ordentliche Funksteckdosen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

OK das klingt doch schonmal nicht verkehrt. Bei den Raw Codes kommt in der Tat immer was (sauberes) zurück.
Das zeigt sich im Log mit "(ReadAnswer)".

Ich weiß nicht, ob ich es schon erzählt habe. Aber mittlerweile habe ich "ordentliche" Funksteckdosen, also keine Baumarkteigenbausteckdosen sondern zumindest originale InterTechno IT-1500 aus dem Bauhaus.

titanbird

Hallo zusammen wieder :-)

Es gibt Neuigkeiten.

Zitat von: titanbird am 07 Mai 2018, 11:52:28

  • (mein erstes) Steckboard
  • paar Kabel
  • ein FS1000A Sendemodul (dabei ist gleich ein billiges XY-MK-5V-Empfängermodul)
  • und gleich noch ein besseres RXB6 Empfangsmodul

Erhalten und zusammengesteckt und getestet mir der SIGNALduino Firmware. Erfolge habe ich. Allerdings tun sich gleich wieder ein paar Fragen auf. :-D

Zunächst mal ein Bild von dem Board mit dem ich sauber empfangen kann (board.jpg).
Damit klappt es mit dem Empfang, da kommt viel im Log (er versucht den empfangen Code zu erkennen und das richtige Protokoll (Flamingo, IT, usw.) zu finden).

Senden klappt nicht (vermute ich). Denn FHEM hat die IT-Steckdose als ich sie mit dem ON-Knopf angelegt habe automatisch als Device angelegt. Wenn ich on/off anklicke in Fhem rührt sich die Steckdose nicht (aber auf dem Arduino blinken die LEDs und zeigt kurz eine Aktivität an).

Fragen:

  • Mein Sendemodul sieht anders aus als ein Bild was ich im Netz gefunden habe. Bei mir fehlt im Vergleich eine der beiden Spulen. Siehe Bild meines Empfängers sender1.jpg und das Bild aus dem Netz sender2.jpg. Ist da was faul oder sieht das OK aus?
  • Ich habe eine kleine Antenne mitgeliefert bekommen. Ich weiß nicht mehr ob die für den Empfänger oder den Sender bestimmt ist :-D Sollte ich die an den Sender löten? Wenn ja: Dort ist der Lötpunkt mit ANT gekennzeichnet. Welches der Lötstellen ist aber die richtige? Ich vermute das kleine Loch direkt beim "T" von "ANT"?
  • Wo würdet Ihr den Fehler jetzt noch suchen, eher bei der Hardware (Sendemodul) oder fehlt einfach die Antenne am Sendemodul oder liegt es jetzt nur noch an der FHEM-Config (Sendecode usw.)? Beim Versuch die Steckdose über FHEM einzuschalten habe ich die Steckdose lediglich 10 cm vom Sendemodul entfernt gehabt.
  • Der Empfang klappt aktuell nur mit dem RXB6. Wenn ich das RX-RM-5V (siehe empfänger1.jpg) drin eingebaut habe bekomme ich gar nichts rein (egal wie nah ich mit der Fernbedienung bin). Der Arduino Nano blinkt dann auch nicht (logisch). Darf man hier sagen dass RX-RM-5V wirklich einfach Billig-Schrott ist und das ganz normal ist dass nichts tut?

Vielleicht könnt Ihr mir noch mehr Klarheit in diese Fragen reinbringen... :-) Würde mich freuen.
Wie würdet Ihr nun an meiner Stelle weitermachen um mal eine Steckdose über FHEM und dem Board zum Schalten zu bekommen?


Grüße!

Beta-User

Zunächst ist es immer eine eher schlechte Idee, Sender ohne Antenne zu betreiben. Habe "das andere" Modul mal im Einsatz gehabt, von daher würde ich behaupten, dass die Antenne auch bei diesem Modul in das Loch oben rechts gehört (also verwirrenderweise das Loch, das am weitesten von "Ant" weg ist...).

Also erst löten, dann sehen wir weiter.

Und ja, dieses "andere" Empfangsmodul gehört auch m.E. in die Kategorie Elektroschrott....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

Moin, Merci. Dort habe ich sie sauber dran gelötet.
Klappen tut es leider noch nicht. Gleicher Effekt, Arduino Blinkt kurz auf, im Log steht dass was in die Send Queue gestopft wurde und dann auch raus ging, ITclock 250, diesen Wert habe ich testhalber auch auf 230 mal gesetzt. Kein Erfolg.

Anbei ein Foto bei ebay wie das Funkmodul laut Foto aussehen sollte... (ebay.jpg).
Aber ich vermisse dort diese 2. Spule, die sehe ich über all auf den Bildern im Netz. Dezent angemerkt: WTF?!?! An der wird es wohl doch liegen?

Beta-User

Leider kann ich dir nicht sagen, ob es an der fehlenden Spule liegt; du kannst ja den Test machen und einfach einen gewickelten Draht reinlöten - schlechter wird es kaum werden...

Ansonsten sollte es so klappen, wie von dir beschrieben: Bei den von autocreate erstellten Devices auf "on" bzw. "off" klicken, das sollte es gewesen sein. Vielleicht postest du die lists von den IT-Devices mal, dann kann sich jemand das ansehen, der davon mehr versteht als ich. Testweise kannst du dafür ja mal den 868-er CUL als IO definieren (die IT-Definition sollte damit auch unverändert funktionieren).

Ansonsten solltest du den Sender doch wechseln, wobei ich insgesamt zur CC1101-Variante raten würde. "Eigentlich" ist das stressreier.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

Schlecht Nachricht zu erst: Das mit dem Draht hat nicht funktioniert. Werde es umtauschen oder einfach ein neues kaufen.

Jetzt kann ich mal behaupten es gibt gute Nachrichten.

Ich habe aber sehr viel rumprobiert.

SIGNALduino: Arbeitet super :-) Er snifft alles und schreibt's ins Log was er nur zu lesen bekommt.
Senden geht nicht... Siehe erster Satz.

Zum ersten mal hat sich was getan als ich per autocreate, wie Du es geschrieben hast, das Gerät so behalten habe und dann den 868er CUL angeschlossen habe. Erfolg!
Aber: Ich hatte ja am Anfang hier mal geschrieben dass der 868er spinnt. ccconf gibt immer wieder Werte aus von 0 MHZ bis 8000 und mehr MHZ. Zwischendrin als ich oft versucht habe zu senden hat er sogar die Verbindung verloren und sich dann wieder initialisiert. Hier muss ein Wackler oder Defekt vorliegen wie schon richtig angenommen wurde. Die Verlötung war nicht gut oder das Sendemodul hat eine Macke gehabt.
Jetzt kann ich es leider nicht nochmal neu anlöten bzw. die Kabel ins Board stecken um auf dem Board "sicherzugehen" dass es wirklich eine Macke hat oder nicht. Denn:
Mir passiert es schon zum dritten mal dass die Lötstellen an der Platine des Sendemoduls abreißen wenn ich etwas zu fest an einem Kabel ziehe, z.B. um es herunterzubiegen.
Ich löte aktuell halt erst seit kurzer Zeit intensiver, ich denke da fehlt Übung. Dieses Modul werfe ich jetzt knallhart weg und bestelle mir neue.
Ich behaupte jetzt mal, das Ganze funktioniert! Und es liegt an dem Problem des CULs dass es sporadisch mal funktionierte, und mal nicht... Also OK! Muss einfach nur einen neuen bauen und gescheit löten!

Dann habe ich weiter gemacht. 433 CUL dran, "ON" geklickt... Nichts tut. Gar nichts. Die LEDs blinken kurz, in FHEM wird angezeigt dass was "rausgeschickt" wurde, sah alles OK aus, aber die Steckdose: Arbeitsverweigerung! Da dachte ich mir, jetzt prüfst Du mal alles schön weiter. Also, alles abgelötet, Kabel frisch dran gelötet ("gewissenhaft") und die Kabel aber ab ins Board und per Steckkabel an den Arduino Nano. Frisch geflasht... Klick auf "ON". Works! Und zwar bei allen Versuchen ohne "Fehlzündung"!.

Übrigens: Bei meinen Tests habe ich immer folgende Szenarien probiert:
Steckdose: 20cm entfernt, 2.5m entfernt, 4.5m entfernt + eine Wand und Bett dazwischen, 6m entfernt schräg durch 1 Wand, 7.5m entfernt durch 1-2 Wände und schräg. Bei allen versuchen: WORKED! Ohne Probleme.



Was mich wundert:
SIGNALduino empfängt immer fleißig wenn ich auf der Fernbedienung drücke. Aber ich muss ganz oft drücken und nach einigen malen (Zufall?) legt er dann ein Gerät an. Ab und zu schreibt er ins Log sowas in die Richtung: "UNDEFINED IT blah blah". Warum ist das da so sporadisch und funktioniert nur manchmal, ist das normal?
Und mich wundert dass ich so schlecht löten kann, hab mir eigentlich Mühe gegeben... Kein CUL hat zu  100% funktioniert was ich da verbrochen habe...  :-X  ;D ;D

titanbird

Ich wollte mich an dieser Stelle einfach nochmal für Eure Unterstützung bei meinen Startproblemen bedanken! Ihr habt mir sehr gut weitergeholfen.  :D

andies

Ich hatte mit diesen Empfängern massive Probleme, die haben einfach nichts sauber empfangen (damals noch mit pilight, steht irgendwo auf deren Seite im Forum und kann ich bei Bedarf raussuchen, wenn dich das interessiert). Bei IT Geräten musst du beim Signalduino eventuell die ITclock einstellen, bei mir geht 290 stabil. Alles andere ist unzuverlässig.

PS https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=164177&start=50
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

titanbird

Merci. Ja wenn Du das raussuchen könntest wäre das super.
Empfangen war eig. von Anfang an möglich bei mir wenn ich richtig sauber gelötet bzw. dann beim "Verlegen" der Kabel aufgepasst hätte :)

Einzige Seltsamkeit: Ich musste mit der IT-Fernbedienung häufig drücken. Oft kam unknown code aber irgendwann hat er sie erkannt und als Device angelegt... Sind das die Probleme, die Du gerade angesprochen hast die mit der ITclock gelöst werden können?

andies

defmod Steckdose_A IT 0FF000FFFF 0F F0
attr Steckdose_A IODev sduino
attr Steckdose_A ITclock 302

Ja, Probleme sind gelöst. Link steht oben.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zwei Dinge sind hier m.E. noch offen:
@titanbird: Ist dein Problem jetzt gelöst - dann bitte den Thread entsprechend kennzeichnen.

[OT]
@mark79: Zwischenzeitlich alle offenen Fragen zum Rock64 soweit gelöst? (Bislang tauchte nichts in den "neuen Seiten" im Wiki auf ;) )
[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

titanbird

Ja alles super. Danke nochmal an alle. Sehr hilfreich.
Habe noch nie ein Thema als gelöst markiert - ich bearbeite den Titel einfach jetzt. Wenn noch was fehlt einfach sagen.

mark79

Zitat von: Beta-User am 13 Juni 2018, 12:18:32
[OT]
@mark79: Zwischenzeitlich alle offenen Fragen zum Rock64 soweit gelöst? (Bislang tauchte nichts in den "neuen Seiten" im Wiki auf ;) )
[/OT]

Nein die sind noch nicht geklärt, also bzgl. HM-MOD aufstecken wird wohl denke ich nicht gehen.
Das schreibt nun auch Armbian: UART is accessible on pin(6 gnd), pin(8 Tx), and pin(10 Rx) and with unusual speed: 1500000 @ https://www.armbian.com/rock64/
Wenn man die HM-MOD Platine modifiziert und einen anderen UART Port benutzt, dann wird es gehen. Aber da kann man direkt ein Seriellen Adapter nehmen...

Ich habe mir jetzt auch ein MapleCUN von Ranseyer zugelegt und dort drauf steckt nun die HM-MOD Platine. Läuft wunderbar. :)

Wegen dem Wiki Eintrag, habe ich ein bisschen was angefangen und das ganze vom ODROID Board übernommen: https://nopaste.xyz/?98c665df8a6590da#uWYPfIr/4hNpPkDyFHJWokRkFqGDPCClfPfgwLdefs8=
Wo beantragt man den Wiki Zugang? Ich finde nur anmelden, aber kein registrieren... Dann kann ich es noch erweitern, wenn ich Zeit und Lust habe.


Viele Grüße
Mark
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Danke euch beiden!

@mark79
Direkter Link, da kommt man über Hauptseite -> unterstütze uns -> Details hier hin (steht auch im Wiki-Bereich hier im Forum beschrieben, meine ich).

Klasse Sache, dass der Artikel praktisch fertig ist! Kann das gerne auch so ins Wiki packen, allerdings habe ich den Eindruck, dass ein eigener Account gut für alle wäre ;D .

Besonders gut gefällt mir diese humoristische Komponente hier  8) 8) 8) :
Zitatmit hilfe eines Windown PC
Redmond war also nur ein klein wenig hilfreich, also eher hinderlich ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Ahh alles klar, danke dir. Ich habe Peter eine Mail geschrieben.

Ein eigener Account ist schon besser, wegen dem bearbeiten. Paar Fehler habe ich auch noch gefunden.

Zum Board, so bin ich mit dem Board immer noch zufrieden, habe nun auch eine SSD über USB3 angeschlossen und darüber bootet er auch.
Was mir noch fehlt ist ein komplett Backup Lösung. Ich wollte bald mal das brtfs Dateisystem ausprobieren, wegen den Snapshots. Mal schauen, ob das so eine gute Idee ist.  8)

Zitat von: Beta-User am 13 Juni 2018, 14:48:46
Besonders gut gefällt mir diese humoristische Komponente hier  8) 8) 8) :Redmond war also nur ein klein wenig hilfreich, also eher hinderlich ;D .
Manchmal ist Klickibunti aber auch nicht verkehrt. :)
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 13 Juni 2018, 15:20:43
Was mir noch fehlt ist ein komplett Backup Lösung.
Ja, das ist so ein Thema...
Zwischenzeitlich bin ich eher auf dem Trip, nur die wichtigen Daten zu sichern und den Installationsweg aufzuschreiben - im Zweifel wird man darüber auch Altlasten wieder los, die sich fast zwangsläufig über der Zeit ergeben.

Aber auch das hat seine Tücken, je mehr "Zeugs" auf so einer Kiste läuft. Bei meinem T5740 ist das im Moment nur FHEM und Mosquitto, da geht das im Problemfall noch fix - aber potente hardware will ggf. auch genutzt sein, und du gehörst wohl zur Kategorie der Spielkinder und Ausprobierer; vielleicht wäre Virtualisierung was für dich. Stichwort wäre LXC, Thread von Ranseyer im Server-Bereich.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Zitat von: Beta-User am 13 Juni 2018, 15:42:05
Kategorie der Spielkinder und Ausprobierer
Das stimmt, ich probiere viel aus. :D

Zitat von: Beta-User am 13 Juni 2018, 15:42:05
Zwischenzeitlich bin ich eher auf dem Trip, nur die wichtigen Daten zu sichern und den Installationsweg aufzuschreiben - im Zweifel wird man darüber auch Altlasten wieder los, die sich fast zwangsläufig über der Zeit ergeben.
Eine Doku habe ich leider nicht, ich wühl mich durchs Forum und Wiki, wenn mal eine Neuinstallation ansteht. Vielleicht sollte ich damit mal anfangen...
Mir graut es dann, die ganzen Pakete erstmal zu finden, nachzuinstallieren, besonders python und cpan. Wegen den ganzen Gedöns was ich hier mittlerweile habe.
Altlasten sind ja nicht weiter schlimm, die verbrauchen nur etwas Platz.

An Virtualisierung habe ich auch schon gedacht, aber es verworfen, weil die HW jetzt auch nicht so potent ist.
Ein Vorteil für mich wäre an Virtualisierung, das man Dienste voneinander abschotten kann. Wie z.B. Nextcloud (öffentlich zugänglich) und Fhem (nur per VPN) auf einem Gerät.
Ja und das man es einfacher sichern und zurück spielen kann.

LCX schaue ich mir dann mal an, das soll ja Leichtgewichtig sein, das ist schon mal gut. Danke :)

Docker mag ich nicht, ich halte das für nicht so sinnvoll, jeden Dienst in einer eigenen Instanz laufen zu lassen.
Updaten geht dann auch nicht mal so einfach.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 13 Juni 2018, 17:10:39
Mir graut es dann, die ganzen Pakete erstmal zu finden, nachzuinstallieren, besonders python und cpan. Wegen den ganzen Gedöns was ich hier mittlerweile habe.
Für Perl-Module, die nicht per deb verfügbar sind, verwende ich mittlerweile dh-make-perl - damit bekommt man die Pakete notfalls auch wieder sauber aus dem System und updates, wenn jemand die ins Repo bringen sollte ;) .
Aber wissen, was man warum installiert hat muß man halt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Zitat von: Beta-User am 13 Juni 2018, 20:36:59
Für Perl-Module, die nicht per deb verfügbar sind, verwende ich mittlerweile dh-make-perl - damit bekommt man die Pakete notfalls auch wieder sauber aus dem System und updates, wenn jemand die ins Repo bringen sollte ;) .
Aber wissen, was man warum installiert hat muß man halt...

Das kannte ich auch noch nicht.. Werde ich bei der nächsten Neuinstallation dann wohl auch verwenden. :)

LXC habe ich auch ausprobiert, startet echt schnell und ich werde da wohl Nextcloud reinpflanzen und vllt. auch Fhem, wenn das mit dem USB Interfaces keine so großen Probleme macht.

Aber noch eine Frage, wo ich noch keine richtige Antwort zu gefunden habe.
Kann man mit der Snapshot/copy Funktion auch im laufenden Betrieb ein Snapshot machen und von diesem ein Backup erzeugen, ohne Angst zu haben, das im Backup was kaputt geht?

P.S. Der Wiki Artikel ist jetzt auch online.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Zitat von: mark79 am 14 Juni 2018, 18:30:18
P.S. Der Wiki Artikel ist jetzt auch online.
Danke!
Habe eben noch ein paar interne Links ergänzt. Einen Änderungsvorschlag hätte ich noch: Die FHEM-Installation ist ja "Standard-Debian" (Easy-way), oder? Dann wäre es m.E. besser, die FHEM-Installationsbeschreibung auf den simplen Hinweis zu beschränken (siehe auch die aktuelle Neben-Diskussion zum HM-Mod-PCB im Wiki-Bereich).

Zitat von: mark79 am 14 Juni 2018, 18:30:18Aber noch eine Frage, wo ich noch keine richtige Antwort zu gefunden habe.
Kann man mit der Snapshot/copy Funktion auch im laufenden Betrieb ein Snapshot machen und von diesem ein Backup erzeugen, ohne Angst zu haben, das im Backup was kaputt geht?
Worauf beziehst du das? Wenn es um LXC geht, wäre die Frage vermutlich am besten bei Ranseyers Thread aufgehoben.
Wenn es um Linux allg. geht: Backups aus dem laufenden Betrieb sind immer ein Problem, auf sowas sollte man nicht (alleine) vertrauen.

Kannst zu dem Thema oder zu dem Board aber gerne auch einen Thread im Server- oder Wiki-Bereich aufmachen, vor allem, wenn es Hardwarespezifisch sein sollte (aber an sich dürfte das ähnlich sein wie bei anderen Boards, bei denen das OS auf einem steckbaren eMMC-Modul sitzt: Am besten regelmäßig (oder vor bzw. nach größeren Änderungen) runter damit, Adapter auf SD-Karte, dd oder irgendein Windowstool zur Partitionsverwaltung nehmen, image erstellen und irgendwo hinschreiben, wo man's wiederfindet...). Das kombiniert mit regelmäßigen Backups der Konfigurationsdateien und FHEM-Backups, und man sollte einigermaßen ruhig schlafen können.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Zitat von: Beta-User am 15 Juni 2018, 10:22:08
Danke!
Habe eben noch ein paar interne Links ergänzt. Einen Änderungsvorschlag hätte ich noch: Die FHEM-Installation ist ja "Standard-Debian" (Easy-way), oder? Dann wäre es m.E. besser, die FHEM-Installationsbeschreibung auf den simplen Hinweis zu beschränken (siehe auch die aktuelle Neben-Diskussion zum HM-Mod-PCB im Wiki-Bereich).
Ja das ist im Grunde nur einfach ein Image aufziehen, wie beim RPi und es bootet dann schon fertig eingerichtet...
Wegen der Fhem Installation und der HM-MOD Varianten, kann ich das gerne noch verlinken.
Aber wenn du es machen möchtest, kannst du auch gerne Hand anlegen, du hast auch mehr Erfahrung als ich. :)

Zitat von: Beta-User am 15 Juni 2018, 10:22:08
Worauf beziehst du das? Wenn es um LXC geht, wäre die Frage vermutlich am besten bei Ranseyers Thread aufgehoben.
Wenn es um Linux allg. geht: Backups aus dem laufenden Betrieb sind immer ein Problem, auf sowas sollte man nicht (alleine) vertrauen.
Auf LXC, du hast mich da auf den Faden gebracht :D Aber ich werde es einfach selber ausprobieren.  Vielleicht noch in Kombination mit btrfs.

Zitat von: Beta-User am 15 Juni 2018, 10:22:08
Kannst zu dem Thema oder zu dem Board aber gerne auch einen Thread im Server- oder Wiki-Bereich aufmachen, vor allem, wenn es Hardwarespezifisch sein sollte (aber an sich dürfte das ähnlich sein wie bei anderen Boards, bei denen das OS auf einem steckbaren eMMC-Modul sitzt: Am besten regelmäßig (oder vor bzw. nach größeren Änderungen) runter damit, Adapter auf SD-Karte, dd oder irgendein Windowstool zur Partitionsverwaltung nehmen, image erstellen und irgendwo hinschreiben, wo man's wiederfindet...). Das kombiniert mit regelmäßigen Backups der Konfigurationsdateien und FHEM-Backups, und man sollte einigermaßen ruhig schlafen können.
Genau das möchte ich ja vermeiden... weil irgendwann lässt man das schleifen und dann steht man da. Ich suche sozusagen noch nach den Heiligen Gral der Backup Lösung. :D
Ich habe auch kein emmc aufgesteckt, sondern boote direkt von USB3 mit einer 120GB SSD.
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Thx für die Erläuterungen.
Ich ergänze das dann im Wiki, aber eine Frage ist noch: Das Image hast du also direkt auf die USB3-SSD geschrieben. Ist das dann wie beim Pi und den SD-Karten, dass das Filesystem automatisch vergrößert wird?
So wie du das schilderst, muß man sonst nichts einstellen für den USB-Boot, es darf halt vermutlich nichts anderes an Massenspeicher drin stecken (Vermute Prio: eMMC, SD, dann USB, das Teil kat ja keinen SATA-Anschluß, oder?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Ich weiß ehrlich gesagt nicht, ob man standardmäßig von USB booten kann, ich würde eher sagen nein.

Anfangs hatte ich eine Zeit lang den Rock64 mit einer SD Karte im Betrieb und die USB SSD kam erst später.

Da ich das Dateisystem behalten wollte, habe ich von der SD Karte ein Image gezogen und das auf die USB SSD geschrieben, danach noch die Partition mit resize2fs vergrößert.

Bei USB boot muss man den SPI Speicher mit ein u-boot image flashen, damit er von USB bootet. Dafür gibt es Scripts, bzw. ein Image was man auf eine SD Karte flashen kann, die das erledigen.

Beim Ayufan Image kann man das mit rock64_write_spi_flash.sh flashen und bei Armbian geht das über die armbian-config...
Am besten auf das Wiki verweisen: https://github.com/aw/linux-build/blob/2fec6745b584c2bbc5fbe15d4cbaacd62c096b24/recipes/flash-spi.md

Weil damit kenne ich mich auch nicht wirklich aus, kenne nur lilo und grub und das wars. :D

EDIT: Sata hat das Board leider nicht. Nur MicroSD, eMMC, USB3 und halt diesem SPI Flashspeicher mit 128 MB
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Beta-User

Danke nochmal.
Habe jetzt die Installationsanleitung für FHEM noch etwas generalisiert und den Hinweis aufgenommen, dass die aktuell beschriebene SD-Karteninstallation _ein_ Weg ist, es aber Alternativen gibt. Wer daran Interesse hat, wird sich hoffentlich zu helfen wissen.
Super wäre noch, wenn man irgendwie den Hinweis unterbringen könnte, dass der wesentliche Vorteil zum Pi darin besteht, dass nicht die ganze Peripherie über einen einzigen USB2-Chip/Kanal geht - so hatte ich das jedenfalls verstanden. Also eine direkte Verbindung zu GB-Ethernet, eine zu USB3, eine zu den USB2-Schnittstellen (gemeinsam), eine zu eMMC usw..
Aber wen sowas interessiert, wird's ggf. selber rausfinden, und hoffen wir mal, dass es dann vielleicht irgendwann auch beim Pi4 so ähnlich ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mark79

Die Änderung sehen gut aus! :)

Ich denke auch, wer sich so ein Board holt, der wird schon wissen wie man das OS auf eMMC oder USB installiert.
Zumal das auch bei den einzelnen Linux Distributions erklärt wird. Mittlerweile gibt es auch schon den Rock64 Pro: https://www.pine64.org/?page_id=61454

Wie die Verbindung bzw. die Aufteilung zwischen Gigabit LAN und USB 3 beim Rock64 ist, weiß ich auch nicht und ich konnte dazu auch nichts finden.
Was noch interessant wäre, ein Speedtest über USB3 mit Verbrauchswerten: https://forum.armbian.com/topic/5098-mini-review-rock64-sata-cable/
Rock64 4GB mit Debian Strech, FHEM im LXC, Sonoff Switches/Touch, HM Thermostate, HMUART/Zigbee2MQTT@MapleCUN, ESP RGBWW Wifi Controller, ESP8266 Door Sensor/Briefkastenwächter, BT CSL Stick, BT iTags, Alexa, FireTV, RPi2 mit Kodi, Xiaomi Vacuum v1/Smarthome Komponenten

Omega-5

Hallo Leute,

seit Beitrag #44 hat das jetzt leider nichts mehr mit dem Titel zu tun. Ihr hättet besser einen neuen thread angefangen.

LG 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),