Autor Thema: Incoming  (Gelesen 11834 mal)

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13221
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #90 am: 20 Mai 2020, 13:53:00 »
Na ja, eigentlich ist das ja keine wirkliche MySensors-Frage, oder? Es gibt für Frequenzen innerhalb des Frameworks afaik keinen direkt passenden Datentypen, ich würde vermulich eben irgendwas nehmen (S_CUSTOM, wenn einem gar nichts einfällt), oder eben was, was in die richtige Richtung geht (V_VAR aus S_POWER?).

Die Messung selbst? Hmm, alles was mit 230V zu tun hat, ist immer mit einer gewissen Vorsicht zu "genießen". Suche nach "arduino frequency power" führt z.B. zu https://create.arduino.cc/projecthub/indoorgeek/measure-mains-frequency-using-arduino-8013b7. Dahinter scheint die Idee zu stecken, die 230V mit einem ordinären Trafo auf 12V Wechselspannung runterzuholen und dann die Pulse interrupt-basiert zu zählen. Dann kann man alle Naselang nachsehen, wie viele es denn waren. Wenn man die reduzierte Wechselspannung über einen Optokoppler an den Arduino bringt, sollte sich das halbwegs gefahrlos (für den Arduino :P ) austesten lassen...
Ob es dafür besseres und sichereres Equipment gibt: k.A..

EDIT (Oder statt des Optokopplers einen Transistor, siehe https://i0.wp.com/www.electroniclinic.com/wp-content/uploads/Arduino-Project-Power-line-frequency-or-mains-frequency-Monitoring-%E2%80%9CAC-220V-Frequency-monitoring%E2%80%9D-image8.png?ssl=1)
« Letzte Änderung: 20 Mai 2020, 13:59:51 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #91 am: 20 Mai 2020, 15:13:00 »
Na ja, eigentlich ist das ja keine wirkliche MySensors-Frage, oder?

Ich hatte schon gehofft, dass jemand so ein "Shield" hat.

Zitat
Es gibt für Frequenzen innerhalb des Frameworks afaik keinen direkt passenden Datentypen, ich würde vermulich eben irgendwas nehmen (S_CUSTOM, wenn einem gar nichts einfällt), oder eben was, was in die richtige Richtung geht (V_VAR aus S_POWER?).

Das war/wäre der nächste Punkt meiner Frage gewesen: Falls man eine HW-Lösung hat - wie knüppelt man das in das Protokoll?

Zur Erklärung: In einem Mikrogrid PV System wird die Leistung der PV Inverter über die Netzfrequenz gesteuert

Start       50.2 Hz
Minimum     52.7 Hz
Disconnect  53.0 Hz

(siehe https://www.victronenergy.com/live/ac_coupling:fronius)

Wenn man die Netzfrequenz kennt, kennt man also auch das Maß der Drosselung und folglich die "potentielle Leistung" und folglich die ungenutzten Reserven, die z.B. via Heizstab o.ä. verheizt werden könnten anstatt brach zu liegen.

Ich kann vermutlich diese Info direkt von den Victrons bekommen via MQTT, dachte mir aber, dass es evtl. ganz nett wäre das mal dezentral - sozusagen P2P innerhalb des MySensors Netzwerks lösen zu können. Vermutlich nichtmal P2P, es könnte eine Node machen, die eh im Maschinenraum hängt. Die würde Frequenz messen und gleich die entsprechenden verbraucher (stufenlose Heizelemente) schalten.

Die Steuerung wäre sozusagen Bestandteil des Node-Sketches (Platz ist im Black Pill genug da) und würde nur die Werte ans GW liefern, aber nicht "remote gesteuert werden". Könnte man natürlich noch beliebig ausbauen, aber erstmal Gemach. Einen Aktor habe ich schon, nur hinsichtlich Sensor habe ich nur Strommessung (Hall Sensor) aber keine Frequenzmessung.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13221
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #92 am: 20 Mai 2020, 15:33:03 »
Interessante Überlegung, und auch die dezentrale Auslegung der Logik finde ich einen guten Ansatz.

Das war/wäre der nächste Punkt meiner Frage gewesen: Falls man eine HW-Lösung hat - wie knüppelt man das in das Protokoll?
Die Antwort war also: irgendwie... Letztendlich müssen ja nur alle Beteiligten (Node, GW, FHEM, User) wissen, wie ein Wert zu verstehen ist; aber Datentechnisch spricht z.B. auch nichts dagegen, das als Temperatur- oder Helligkeitssensor zu präsentieren, das irritiert dann nur die letzte Stufe in der Infokette (also den User).

Btw.: hatte gestern etwas Muße und habe mal einen MCP2551 direkt an einen USB-Seriell-Wandler angeschlossen. Eigentlich vorrangig um zu sehen, ob ich damit zufällig irgendwelchen Datenverkehr an meiner Therme sehe (Junkers HT-Bus, der Hinweis von @Ranseyer zum Easy-Bus hat mich auf diese Idee gebracht, weil der ja auch ständig 5V Differenzspannung A-B bringt, ganz wie die vermutete Bus-Anschlussstelle am HT-Bus). Das hat nicht geklappt, aber zum Testen habe ich die Konstruktion mal zum Sniffen des MySensors-Verkehrs benutzt. War interessant, und vor allem irgendwie beruhigend. Denn jedenfalls in der kurzen Zeit des sniffens kam eigentlich nur das "als Klartext" über die Leitung, was offensichtlich Text war (Sketchname und Sketchversion), der Rest war zwar irgendwie strukturiert, aber im Prinzip unleserlich. Ergo kann ein Angreifer, der die Leitung findet zwar Sniffen oder sich ganz einklinken, aber er muß dazu wissen, dass es MySensors ist, was da läuft (und dann noch die Datenrate kennen, wie üblich). Nett...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #93 am: 20 Mai 2020, 15:59:38 »
Ergo kann ein Angreifer, der die Leitung findet zwar Sniffen oder sich ganz einklinken, aber er muß dazu wissen, dass es MySensors ist, was da läuft (und dann noch die Datenrate kennen, wie üblich). Nett...

Trotzdem ist das nur security by obscurity.
Und vermutlich werde ich es - in der Kabelfassung - auch dabei belassen, aber bei einer drahtlos Lösung würde die Entscheidung schon anders aussehen.

Nur mal so als Stand: Ich bin nicht tot, ich bin am basteln.

ULN2803A
74HC165
74HCT245
74HC595

wollen zusätzlich zu dem Experimentierzeug (siehe Bilder oben "Materialschlacht") getestet werden.
"Gute" Nachricht - das Relais was aufgehört hat zu klackern - da ist nicht der uC Ausgang kaputt, sondern das Relais.
Hat in seinem Leben so 10x geschaltet. Werde mich vermutlich nach SSRs umsehen.

edit:

vielleicht noch als Nachtrag zum "bin am Basteln":

Definitiv sei jedem Anfänger und vielleicht auch jedem "ambitionierten Anfänger" empfohlen sich auf alle Fälle zumindest zwei Arduinos zu holen - auch wenn er mit STM32-basierten Nodes plant. Nicht wenige Bibliotheken fliegen einem nämlich um die Ohren, wenn man die "mal eben" auf dem STM32 compiliert. So geschehen gestern mit der u8glib:

WARNING: library U8glib claims to run on avr, sam architecture(s) and may be incompatible with your current board which runs on STM32F1 architecture(s).

Das kann man sich ja dann als ambitionierter Anfänger zu herzen nehmen: https://blog.bastelhalde.de/post/using-the-u8glib-on-the-stm32
aber für einen schnellen Test des aquirierten Materials ist es eher hinderlich in den Basisbibliotheken rumzuhacken.
« Letzte Änderung: 20 Mai 2020, 16:27:05 von RichardCZ »

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13221
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #94 am: 20 Mai 2020, 16:25:11 »
In dem Fall reicht mir security by obscurity ;D . War jedenfalls besser als nRF ohne signing (das kann man da optional in Hardware ergänzen, die RFM-Chips sollten das sogar built-in können). Theoretisch könnte das mit signing auch bei RS485 gehen, aber "obscurity" war für mich bisher ausreichend, um deswegen nicht schlaflose Nächte zu haben...

ULN2803A habe ich jüngst auch ein paar bestellt, das klang sinnvoll, das mit den Schieberegisterdinger ist vielleicht auch noch eine gute Sache (mir sind die Pins an den Arduinos bisher allerdings nicht ausgegangen, und großflächige LED-Anzeigen wollte ich eigentlich nicht aufbauen, da ist ein Blick auf's Handy aufschlussreicher), aber für was sind die 74HCT245 gedacht? Das klingt "speziell".

Was das Relay angeht: shit happens, aber ausgerechnet beim ersten?!? Die Dinger sind nach meiner Erfahrung eher robust...

Wie auch immer: Viel Spaß beim weiteren basteln!

(OT: bisher hat sich keiner über das update der Module beschwert, aber (außer dir) auch keiner irgendwas zu den neuen features rückgemeldet. Strange, und hoffentlich eher beruhigend).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #95 am: 20 Mai 2020, 16:42:21 »
aber für was sind die 74HCT245 gedacht? Das klingt "speziell".

3.3V <-> 5V Interface. Ich habe mir auch 2 Büchlein besorgt:

Mastering STM32 von Carmine Noviello
Beginning STM32 von Warren Gay

In letzterem steht auf Seite 300 eine Application note wie man z.B. ein PWM Signal zwischen der Pille und einem Servomotor mittels dieses Chips "konvertiert".
Da er bidirektional ist, kann er auch dienen die nicht-5V-toleranten Eingänge der pille zu schützen.

Ansonsten siehe: https://www.mikrocontroller.net/articles/Pegelwandler

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13221
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #96 am: 20 Mai 2020, 16:51:33 »
Ah, so einfach ist die Welt manchmal. Man muß nur draufkommen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6902
Antw:Incoming
« Antwort #97 am: 21 Mai 2020, 10:59:06 »
Die Frage ist auch, was Du mit dem Relais geschaltet hast. Speziel bei Induktiven lasten ist das Leben von Relais als "kurz" zu betrachten .. was ich selber mal schmerzlich Erleben durfte.

Auch sind "echte" Umschalter, wo also der Öffner und der Schließer belegt sind, zu vermeiden. Dann lieber 2 Relais parralel, also bei einem den Öffner und beim anderen den Schließer ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #98 am: 21 Mai 2020, 12:45:05 »
Die Frage ist auch, was Du mit dem Relais geschaltet hast. Speziel bei Induktiven lasten ist das Leben von Relais als "kurz" zu betrachten .. was ich selber mal schmerzlich Erleben durfte.

Auch sind "echte" Umschalter, wo also der Öffner und der Schließer belegt sind, zu vermeiden. Dann lieber 2 Relais parralel, also bei einem den Öffner und beim anderen den Schließer ...

Nichts habe ich geschaltet. Ausgänge waren frei, mir ging's nur um das *klack* *klack* zum Testen.

Naja - ist so ein < 2EUR Teil, da lohnt nichtmal die Reklamation. Kann natürlich Pech sein, "Badewannenkurve" - also der Anfang davon, falsche Charge erwischt.
Aber das produktiv zu verwenden hat jetzt schon einen Dämpfer erhalten.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13221
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #99 am: 25 Mai 2020, 16:44:57 »
vielleicht noch als Nachtrag zum "bin am Basteln":

Definitiv sei jedem Anfänger und vielleicht auch jedem "ambitionierten Anfänger" empfohlen sich auf alle Fälle zumindest zwei Arduinos zu holen - auch wenn er mit STM32-basierten Nodes plant. Nicht wenige Bibliotheken fliegen einem nämlich um die Ohren, wenn man die "mal eben" auf dem STM32 compiliert. So geschehen gestern mit der u8glib:

WARNING: library U8glib claims to run on avr, sam architecture(s) and may be incompatible with your current board which runs on STM32F1 architecture(s).

Das kann man sich ja dann als ambitionierter Anfänger zu herzen nehmen: https://blog.bastelhalde.de/post/using-the-u8glib-on-the-stm32
aber für einen schnellen Test des aquirierten Materials ist es eher hinderlich in den Basisbibliotheken rumzuhacken.
Weiß nicht, ob das das Problem vollständig beseitigt:
https://github.com/mysensors/MySensors/pull/1422

Aber auch nach meinem Eindruck sollte man in diese Welt immer mit "möglichst wenig drumrum" einsteigen: zwei Arduinos, zwei (einfache und bekanntermaßen funktionierende) Transceiver, das ganze mit seriellem GW. Komplizierter machen geht immer, selbst wenn es an manchen Ecken nach und nach einfacher wird...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

 

decade-submarginal