STM32 mit 868Mhz vs. ESP32

Begonnen von ulli, 28 Februar 2018, 09:41:41

Vorheriges Thema - Nächstes Thema

ulli

Hallo zusammen,
ich bin gerade am grübeln ob ich meine aktuelle Haussteuerung mit zahlreichen Sensoren und Aktoren erneuere. (Rollo, Temp/Hum/Lum, IR Tx/Rx, Energie, Katzenklappe) + (Steckdosen 433MHz, HM Fensterkontakte, Lacrosse)
Aktuell setze ich einen Atmega328p mit 868MHz Funktechnik (RFM69) zur Kommunikation ein.

Ich sehe zwei Möglichkeiten:
* Update auf STM32, Funktechnik bleibt RFM69
  Vorteil: gleiche Kommunikation (Batteriebetrieb möglich), Controller mit mehr Speicher (OTA möglich), höhere Geschwindigkeit, Änderungsaufwand überschaubar, eigene PCB weiterhin möglich (hohe integrierbarkeit / Baugröße), keine Anbindung direkt ans Internet / Sicherheit, Strahlungsbelastung/Traffic minimal
  Nachteil: hoher Aufwand bei eigenen PCBs

* ESP32, d.h.Umstieg auf WLAN mit MQTT Broker
  Vorteil: Bequemer Zugriff über Browser, OTA fähig, billige Module, weniger Aufwand bei eigenen PCBs
  Nachteil: höher Änderungsaufwand, kein Batteriebetrieb möglich/hoher Stromverbrauch, umständlich über zusätzlichen Broker, Bauraum größer, Anbindung aller Module ans Internet/Sicherheit?, Strahlungsbelastung/Traffic hoch?

Wie seht ihr das?
Wie würdet ihr euch entscheiden?

Grüße,
  Ulli

Beta-User

Warum überhaupt weg vom ATMega328, wenn es derzeit funktioniert?

Wenn du ein anderes Protokoll benötigen solltest, um die bestehende Sensorik (besser ?) in FHEM einbinden zu können, könnte MySensors in Frage kommen.

Ansonsten finde ich die STM32-Variante ansprechender, WLAN vermeide ich persönlich bei der Hausautomatisierung, wo es irgend geht.

@Ranseyer ist nach meiner Kenntnis gerade dabei, Platinen für MySensors@STM32 (ich meine RFM69-basiert) zu entwickeln, damit würde der eigene Aufwand ggf. überschaubarer (die Platinen sollten sich auch für andere Kommunikationslayer verwenden lassen).

Aber das ist sicher alles Ansichtssache, daher an der Stelle halt meine 2ct...

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

ulli

was sind deine Gründe von wlan Abstand zu halten?
hast du nen link auf die entwicklung von Ranseyer?

ich bin beim Atmega an der Speichergrenze und damit ist OTA update nur bedingt möglich.

Beta-User

Hier erst mal ein Link (ist ein Atmel M0, den Brasletti und Ranseyer da verwenden): https://forum.fhem.de/index.php/topic,81923.msg760677.html#msg760677. Gibt evtl. noch andere Varianten, die beiden helfen sicher gerne, wenn du sie direkt ansprichst.

WLAN mag ich nicht, weil das statt einer simplen seriellen Verbindung für ein IO eine Infrastruktur erfordert, die ganze Ketten von Abhängigkeiten diverser Hardware benötigt. Und eigentlich sollte man m.E. auch die IoT-Geschichten vom "normalen" WLAN trennen; das ist mir aber zu viel Aufwand - geht ja auch anders ;) .
Dann: Speziell auf die ESP8266 habe ich zu viel Zeit verschwendet, und die ganzen Kinderkrankheiten (timing usw.) verfolgt; deswegen habe ich eine persönliche Aversion gegen Espressif und halte deren Produkte für schlecht designete Hardware ::) . Achtung: Bin Laie...
Das beliebte ESPEasy hat dann noch gravierende Sicherheitsmängel, wenn ich den Ausführungen von hexenmeister Glauben schenke. Dann ist die Gefahr von jamming und sonstigen Kollissionsproblemen gerade im WLAN-Frequenzbereich besonders hoch. Und eine Zeitlang war es so, dass man bei den ESP's jedes mal neu flashen mußte, wenn sich an den WLAN-Daten was änderte. Mach das mal, wenn du nach längerer Zeit diverse updates von diversen verwendeten libs durch hast. Das ist schon bei den 328-ern keine Freude und wird sicher nicht wirklich besser, wenn man einen ganzen Haufen weiterer libs braucht.

Dazu dann das Verbrauchs-Thema >:( . Und die hier im Forum beliebte Frage: Warum müllt mir dieser und jener ESP das log voll?!?

Ergo: Wenn es anders geht, muß es anders gehen 8) .

Aber wie gesagt: Das ist meine ganz private Meinung!
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

ext23

Zitat von: Beta-User am 28 Februar 2018, 09:54:24
WLAN vermeide ich persönlich bei der Hausautomatisierung, wo es irgend geht.

Sehe ich genauso! 433 und 868 sind doch gut, Reichweite ist gut bei den "niedrigen" Frequenzen. Batteriebetrieb, jedenfalls mit kleinen Knopfzellen ist kein Thema, mit großen geht es ja auch beim ESP. Wozu brauchst du OTA? Der Sensor wird ein mal programmiert und dann läuft der. Mehr als ab und an die Batterie tauschen möchte kein Mensch.

Ich finde nur eins wichtig, und das ist die Verschlüsselung, und da kommt man beim AVR vermutlich schnell an die Grenzen. Aber ich kann mir gut vorstellen, dass auch AVR was im Angebot hat mit Hardware Verschlüsselung. Ansonsten muss man das eben durch mehr Leistung erbringen, aber das braucht dann auch mehr Energie.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ulli

Ja da habt ihr recht. Ich tendiere auch gerade zum stm32, da die Umstellung vermutlich schneller gemacht ist.
Seitens fhem würde ja alles gleich bleiben, was bei einem esp32 ein riesen Ding wäre.

Bzgl Verschlüsselung bringt doch der rfm69 eine aes encryption mit?

ulli

 
ZitatBatteriebetrieb, jedenfalls mit kleinen Knopfzellen ist kein Thema,

Hast du dazu Details wie du das realisiert hast?

Beta-User

Zitat von: ulli am 28 Februar 2018, 21:19:50

Hast du dazu Details wie du das realisiert hast?
Es gibt hier einen Thread zum Selbstbau-Fensterkontakt (CC1101/HM-basiert), kann sein, dass das schon unter universelle Basis firmiert.

Was signing und MySensors@AVR angeht: wird hard- und softwarebasiert angeboten (ich habe aber keine Erfahrung damit). Details bei MySensors.org

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

ulli


Beta-User

Der ist auch nicht uninteressant, aber gemeint hatte ich eigentlich alles rund um diesen Beitrag bzw. den dort verlinkten Thread:
https://forum.fhem.de/index.php/topic,73954.msg656384.html#msg656384
Das nutzt einen CC1101 als 868MHz-Transceiver, die Platine wäre aber wohl auch für einen nRF24 oder RFM69 geeignet (nach meiner Kenntnis PIN-kompatibel, bitte prüfen).

Gibt auch eine kompakte MySensors-Versionen, siehe hier: https://forum.fhem.de/index.php/topic,75286.msg718228.html#msg718228

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

Ranseyer

FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!