Wer bisher schon “ordentlich” unterschiedliche Appliances über weitere Strecken vernetzt hat, als es board-level-Protokolle wie I2C oder SPI hergeben, oder im Automotive-Bereich oder anderen Industriebereichen zu tun hat, hat ohnehin schon längst daran gedacht:
@Basti hatte mir diesen Vorschlag schon recht früh unterbreitet, vor einiger Zeit gesellte sich da dann auch @roh hinzu und jetzt werden wir mit @IngoP vielleicht noch einer mehr.
Präferenzen
@Basti wollte sein System auf Basis von Nucleo/Mbed/STM32 entwerfen.
@roh schielt auf STM32 für das Sensorboard und Pycom ESP32 für das Masterboard. [1]
@IngoP… wird sich vermutlich an ähnlichen Dingen orientieren?
Alternativ zu einem Pycom-Gerät könnte in Richtung SIM800 auch ein TTGO T-Call bzw. dessen Nachfolger GitHub - Xinyuan-LilyGO/T-SIM als Master-Knoten dienen. Das wiederum könnte @clemens und @weef gefallen.
Gleiches gilt natürlich auch für entsprechende integrierte Geräte mit ESP32 MCU und LoRa-Bearer, vermutlich in Richtung SX127x – das wäre wiederum etwas für @Thias. ↩︎
Vielleicht einmal etwas weiter gedacht: Wäre es nicht ohnehin besser, eine eigene Platine mit einem HX711 oder ADS1231 diskret aufzubauen? Mit einer ordentlichen Beschaltung nach Spec, mit externem Oszillator Quartz, usw.
Perspektivisch könnte man diese Variante dann als Multi-Waagensystem auslegen und dann über RS485 SLAVE (MODBUS) mit einem Pycom FiPy verbinden, der als RS485 Master fungiert.
Unser Wägezellenanbieter selbst vertreibt das bereits so, siehe BOSCHE WTS.
Statt RS485 gerne auch CAN bus – Hauptsache Industriestandard!
Auch an dieser Stelle ein Hinweis auf die bienenwaage-0-2-von-sebastian-et-al, da werkelt u.a. ein ADM2582E (RS485), den ich zunächst für einen ADM3053 (CAN) gehalten hatte.
ich dachte an stm32 weil es hier guenstig gleich can on chip gibt (nurnoch externer transciever, wie beim esp32) man aber keinerlei der problematischen hf-radios in der naehe hat. ausserdem ist die platform dann doch ein bisschen… gereifter ;)
avr gibt es nur wenige mit internen can, und die sind dann vergleichsweise teuer. daher leider raus. externes can interface find ich nichtmehr zeitgemaess.
zum prototypen waere mein plan: stm32 blue pill + can interface + waldundwiesen step-down dcdc (9-24V -> 5V) und ein bme280 (direkt mit aufs board). auf dem board auch platz fuer ein ds18b20/uuid chip (3pin wie transistor gehaeuse) vorsehn, falls man im stm keine uuid findet. (can-addresse?)
um stromversorgungsdetails muss sich dieses device nicht kuemmern.
es pollt nur alles an sensoren was es lokal angeschlossen hat und pusht die daten als can-messages.
zum stromsparen disabled man vom zentralen kommunikationsknoten (das mit dem fipy) dann die buspower.
