Autor Thema: Incoming  (Gelesen 12651 mal)

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1523
Antw:Incoming
« Antwort #45 am: 11 Mai 2020, 09:20:15 »
Öfter habe ich auch gelesen, dass einige gleich CAT7 Verlegekabel nehmen - egal wofür - wäre mit etwas overkill. Manchmal wird Schirmung empfohlen, dann wieder nicht oder wenn, dann nur fliegend - also weder vorn noch hinten den Schirm angeschlossen  :o

Ich lese mit, weil wir vermutlich in nächster Zeit ein Haus kaufen das kernsaniert werden soll, dabei möchte ich auch einen Bus legen und CAN/RS485 ist eine Option (neben HmIP-W und KNX). Warum hältst du CAT7-VK für Overkill?

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13620
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #46 am: 11 Mai 2020, 09:26:42 »
@RichardCZ:  :o 50+? Willst du den Tester machen für "gehen mehr als 32 CAN-Transceiver an einem Bus@MySensors?" (und warum dann nicht gleich 128+?!? :P ). Oder renovierst du grade ein Schloss und willst Technik verlegen, die auch noch für die Ur-Urenkel paßt?

Den RFID-Reader-Sketch habe ich mal angehängt, ist vermutlich nicht in meinem Repo, wie gesagt: No Guarantee, den habe ich derzeit nicht im Einsatz.

Was Kabel angeht, habe ich ein ziemliches Sammelsurium im Einsatz: Vom Server in den Keller ist es CAT6 oder 7 (also ein verdrilltes Paar daraus bzw. gelegentlich 2 für den Hin- und Rückweg, meistens sind dann die 12V in einem weiteren Paar), und im Keller größtenteils auch, der Rest sind handelsübliche 4-adrige Telefonkabel, die Kabelstärke paßt in etwa zusammen. Das ist praktisch an allen Nodes mit kleinen Wago-Steckverbindern zusammengestückelt. Meine Skepsis gg. höheren Datenraten hat daher auch was mit der konkreten Verkabelung zu tun ::) ...

@rob: Im Starter-Guide ist bei RS485 irgendwo ein Link zu einem Berechnungstool, mit dem man bei verschiedenen Kabelstärken auch die Abschlusswiderstände usw. berechnen kann. Das scheint halbwegs valide zu sein, was da rauskommt...

@Gisbert: Bis 8mm hatte ich ausgetestet (12V-Variante, es gibt hier ja eine zentrale Versorgung ;) ); meiner ist ein Zenner, der ähnlich aussieht wie der von hier. Das ist eine der Sachen, bei der die Bebilderung auf der MySensors-Seite übrigens irreführend ist, siehe dazu auch die mMn. nicht ganz unberechtigte "Generalkritik" an der (Aktualität der) Einführungsliteratur zu MySensors hier (u.a. aus diesem Grund wäre es super, wenn PJON ans laufen käme. Dann braucht man zum Einsteigen nur noch zwei Arduinos, und kann sich mit den sehr viel komplzierten Fragen betr. der elektrischen Auslegung von RFM-based Nodes dann beschäftigen, wenn man das Grundprinzip verstanden hat). "Grundsätzlich" scheint mein angehängter "puls-Laser"-Sketch zu funktionieren, ich bin aus diversen Gründen nur noch nicht dazu gekommen, den sauber auszurichten und zu kalibrieren. Aber wenn du denselben Zähler, ein Bildchen vom Aufbau und die genaue Type von dem Näherungssensor hättest, wäre das evtl. auch eine Alternative, die Schaltung vom Näherungssensor hätte ich sonst eben für's Garagentor verwendet...

@andies: RFM96 hätte dir übrigens mit großer Sicherheit das Einarbeiten in die Antennentechnik "erspart" (da war doch was mit einem Wasserzähler weit entfernt vom Haus, der "unbedingt" in MomeMatic-BidCoS sein "mußte" ;) ...). Aber man weiß ja nie, für was erweiterte Kenntnisse gut sind ;D .
(Falls jemand in einem größeren Mehrparteien-Haus wohnt und was für den Keller sucht, das so weit funkt: here you are, take RFM96-LoRa... Aber schon mit einem "guten nRF24L+" (die ungeschirmte 1.100m-Variante hatte ich hier mal auf Reichweiten getestet. Ich kam auf  jenseits 100m in einem lose überbauten Wohngebiet, also im Freien ohne ganz direkte Sichtverbindung, das GW innerhalb meiner Hütte. Mit der geschirmten 2.300m (?)-Variante geht da bestimmt noch mehr.)
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: 7099
Antw:Incoming
« Antwort #47 am: 11 Mai 2020, 09:36:33 »
"Damals" hatte ich bei meinen Eltern CAT5e verlegt und für fast alles genommen. Außer wenn wirklich "Strom" (Auch Niederspannung) transportiert werden mußte. Dafür sind Netzwerkkabel wirklich sehr ungeeignet. Ist zwar teurer als "Klingeldraht", aber man spart sich Kabelziehen ...

Bevor ich jetzt einen Hinweis wegen PoE bekomme, man überlege sich, was dort für "Klimmzüge" gemacht werden, um die "Leistung" durchs Netzwerkkabel zu bekommen.
- 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 Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13620
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #48 am: 11 Mai 2020, 09:52:35 »
Nachtrag noch zu meinem Setup:
Die längste Kabelstrecke dürfte zwischen Server und Keller sein. Das Netzteil hängt aber im Keller, das hat mit der Strecke "nach oben" nix zu schaffen.

Meine Versuche mit 5V waren - vermutlich wg. der Leistungsverluste in den Leitungen - nicht sehr befriedigend, daher jetzt (wieder) die 12V-Variante. Da die Nodes selbst kaum Strom brauchen (schwankt etwas, aber insgesamt ~3W für den ganzen Aufbau, wie gesagt: echte Verbraucher sind galvanisch getrennt), dürfte die übertragene Leistung nicht das große Problem darstellen. Hat man kurzzeitige Verbrauchsspitzen, kann man ja vor Ort puffern, hin und wieder ein Kondensator ist sowieso vermutlich eine gute Idee.

Was die Stromversorgung angeht, kann man die ja durchaus "im Stern" machen, also anders als die eigentliche Busverkabelung. (Oder bin ich zu naiv, was das angeht?)

@Christoph Morrison: Wenn du eh' HM-IP im Einsatz hast, wäre vermutlich die HM-Wired-Variante für deinen Anwendungsfall auch eine Option. eQ-3 arbeitet afaik mit 24V und einer Art Widerstandsnetzwerk.

@all: Zum Thema  Busauslegung gab es auch mal einen "Spezialthread"; vielleicht wäre es günstiger, diesen Teil der Diskussion dort weiterzuführen (die Erlaubnis des dortigen TE ist hiermit erteilt...), da ist nämlich auch schon manches Theorieschnippselchen zu finden. (Mir ist das aber im Grunde egal, wo).
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 #49 am: 11 Mai 2020, 09:55:26 »
@RichardCZ:  :o 50+? Willst du den Tester machen für "gehen mehr als 32 CAN-Transceiver an einem Bus@MySensors?" (und warum dann nicht gleich 128+?!? :P ). Oder renovierst du grade ein Schloss und willst Technik verlegen, die auch noch für die Ur-Urenkel paßt?

Schloss ist es nicht gerade, aber bei der letzten Zählung brauche ich mindestens 25, wenn ich "Ein Kästchen pro 'Zimmer'" haben will. Wobei "Zimmer" ein abstraktes Konzept ist. Garage, Dachboden, Garten, 30m³ Regenwasser-Zisterne tief im Erdmantel,.. sind auch 'Zimmer'.

Gehe ich von der MySensors Baumtopologie aus (https://www.mysensors.org/about/network), dann werde ich ein wenig aggregations-Overhead brauchen (Repeater Nodes). Vermutlich bin ich dann froh wenn ich unter 32 bleibe. Wobei mir immer noch nicht ganz klar ist, wie so ein Stern zu einem parallel Bussystem zusammenpasst. Für mich sieht das so aus, als wären die Äste nach den Repeater Nodes eigenständige RS485 Busse.

(Dann wird sicher was kaputt ankommen, bzw. kaputt gehen und irgendwas braucht man auch auf Vorrat.)

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7099
Antw:Incoming
« Antwort #50 am: 11 Mai 2020, 09:56:46 »
Das Problem bei "Stromtransport" ist immer der Querschnitt. 1W bei 10V ist eben 0.1A. Dagegen bei "hypotetischen" 1V gleich 1A und damit Deutlich Wichtiger. Auch ist, vereinfacht gesagt, der "Widerstand" der Leitung bei höheren Spannungen geringer als bei kleinen.

Genau gelernt habe ich es im Studium ... aber mittlerweile als Unwichtiges Wissen aussortiert, außer obiger "Faustformel"

Edit:
@RichardCZ
Kannst Du den Baum ansonsten nicht in mehrere Aufteilen? Hat den Vorteil, das bei Ausfall eines Baumes die anderen weiterlaufen ... bei dem Nachteil, das DU mehr USB-Bussystem-Konverter brauchst. Aber sooo teuer sind die auch nicht.
« Letzte Änderung: 11 Mai 2020, 09:58:56 von Wernieman »
- 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 rob

  • Full Member
  • ***
  • Beiträge: 241
Antw:Incoming
« Antwort #51 am: 11 Mai 2020, 10:04:59 »
Ich lese mit, weil wir vermutlich in nächster Zeit ein Haus kaufen das kernsaniert werden soll...
Das habe ich in 2014 durchgemacht. Leider konnte ich bautechnisch keine strickte Sternverteilung jeder einzelnen Dose/ Lichtanschlussstelle zum Zentralverteiler durchführen (zuviel schlitzen ist wohl schlecht für die Statik ;) )

Warum hältst du CAT7-VK für Overkill?
Nicht pauschal. Nur bezogen auf diesen Zweck. Tatsächlich habe ich damals überall dort CAT7 verlegt, wo ich auch Netzwerk machen wollte.

Jetzt geht es mir z.B. darum die Garagentorsteuerung (ConfigFirmata@Esp8266 funktioniert super, bis auf das schlechte Wifi) durch Kabellösung abzulösen. Dafür benötige ich max. 4 Adern und simplen Schirm. Lass Dich von mir also nicht irritieren :)

Viele Grüße
rob

OT: Ich fand u.a. das Buch "Heimautomation mit KNX, DALI, 1-Wire und Co." (ISBN-10: 383626613X) hilfreich, weil viel auf Grundausstattung+Planung eingegangen wird. Der Rest ist zwar stark auf KNX ausgelegt und m.E. viel nur im Neubau möglich, aber trotzdem half es mir.
fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

Offline RichardCZ

  • Tester
  • Sr. Member
  • ****
  • Beiträge: 597
  • HoBo: zwischen Weltherrschaft und Intensivstation
    • Experimenteller FHEM Fork
Antw:Incoming
« Antwort #52 am: 11 Mai 2020, 10:21:46 »
@RichardCZ
Kannst Du den Baum ansonsten nicht in mehrere Aufteilen? Hat den Vorteil, das bei Ausfall eines Baumes die anderen weiterlaufen ... bei dem Nachteil, das DU mehr USB-Bussystem-Konverter brauchst. Aber sooo teuer sind die auch nicht.

Ich bin eher am Kopfkratzen was die Repeater Nodes anbelangt. Das scheint für kabellos konzipiert zu sein, aber wenn man es "richtig" macht und das GW ist physisch zentral im Haus gelegen, ist das für einen Bus ziemlich schlecht, weil man dann die Kabel "am GW vorbei" von einem Ende des Hauses zum anderen ziehen müsste und dann wieder zum GW zurück.

Aber Du hast recht, vermutlich kann ich Repeater knicken und ein Multi-GW realisieren. Da hätte ich mir dennoch gewünscht, dass man z.B. eine Node mit mehreren RS485/CAN Ports ausstatten kann.

Offline Wernieman

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7099
Antw:Incoming
« Antwort #53 am: 11 Mai 2020, 10:30:21 »
Meine Frage war einfach allgemein. Speziell "RS485/CAN" kenne ich mich nicht aus ...

ich z.B. würde bei I2C einfach viele esp8266 nehmen und damit viele Kleine i2c-Busse nehmen. Andere dagegen legen sich einen riesen Bus ins Haus. Hatt alles seine Vor/Nachteile.

Für mich blöde: esp8266 hat WLAN .... und nicht Kabel. Schade das es keine einfache alternative "Kabellösung" dafür gibt ... andererseits kann ich in meiner aktuellen Mietwohnung schlecht Kabel legen ;o)
- 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 rob

  • Full Member
  • ***
  • Beiträge: 241
Antw:Incoming
« Antwort #54 am: 11 Mai 2020, 10:33:04 »
Den RFID-Reader-Sketch habe ich mal angehängt, ist vermutlich nicht in meinem Repo, wie gesagt: No Guarantee, den habe ich derzeit nicht im Einsatz.
Mit dem Wiegand Dual-Reader 7304D2 (z.B. https://www.ebay.de/itm/Dual-Frequency-RFID-Reader-Wireless-Module-13-56MHz-125KHz-ISO14443A-EM4100/264698370838) habe ich seit >1 Jahr sehr gute Erfahrungen gemacht (können 125KHz + 13,56MHz, was ich beides auch brauche).
Hängt noch an einem EspEasy@Wemos, aber für MySensors gibt es auch schon ein Wiegand-Beispiel https://forum.mysensors.org/topic/5248/rfid-card-reader-wiegand, womit ich mich befassen möchte.

Viele Grüße
rob

fhem@Raspi3B mit DietPi auf USB-SSD am aktiven Hub | Z-Wave Stick Aeotec | Zigbee Stick Conbee2 | nanoJeeLink | SIGNALduino@433 + @868 MHz | Denkovi USB-OW-Busmaster | config. Firmata@Arduino | EspEasy@WemosD1;Sonoff Basic  | MySensors@Arduino

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13620
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #55 am: 11 Mai 2020, 11:57:26 »
Zur Topologie @RS485: Das ist eine strikt lineare Bus-Topologie, die man da planen sollte. Das ganze ist eher zu vergleichen mit dem 1-Wire-System (da hat pah viele wertvolle Hinweise ins Wiki gepackt).

Deswegen hatte ich hier auch geschrieben "Hin- und Rückweg" iVm. dem Hinweis auf ein separates Paar Adern. Repeater braucht man nur bei Funk und nur dann, wenn die Reichweite nicht ausreichend ist (oder man sniffen will). Bei RS485 erreicht aber jede Node das GW...

Zu meinem MFCR522-Sketch: Der funktionierte at the time of writing 8) .
Ich hatte nur ursprünglich mal vor, den Leser (versorgt über Wechselspannung) in meiner Türsprechanlage zu verstecken und eine "öffne mit Handy"-Option damit einzubauen. Zwischenzeitlich habe ich das Problem aber anders gelöst und den Sketch nur mal für einen anderen User hier zusammengebaut, der RS485 nutzt, aber einen anderen Leser (I2C) und Probleme damit hatte, die Wandlung von String nach Char zu machen... Der Teil klappte jedenfalls, danach landete das Ding wieder in der "Grabbelkiste".

Damit sind wir bei zwei anderen Themen:

Wechselspannung (12V?) wäre ggf. eine Variante, die Leitungsverluste zu minimieren. Das erfordert dann aber wirklich wieder weitere Bauteile, um den Arduino damit zu versorgen... (ich habe zwar (Grund: s.o.) ein paar Module aus China rumliegen, kann aber nicht sagen, ob das ggf. funktionieren würde.)

I2C:ALLES, wofür sich eine funktionierende Arduino-lib findet, bekommt man mit MySensors in ein FHEM-Reading!
Da man "sowieso" den Code selbst schreiben muß, sind auch mit einem simplen ATMega32 zwei (oder mehr) gleiche Typen möglich, wenn man die Adressen umschalten kann. Und für die meisten Typen gibt es auch Standard-Formate, letztlich ist es egal, WIE eine Temperatur jetzt gemessen wird...

(Da fällt mir der PCF8583 wieder ein. Ein I2C-Uhren-Bausteinchen, den ich irgendwann mal ::) in meine Super-Duper-Wetterstation mit Windwarner einbauen wollte. Der kann "leise" Zählen und den Arduino dann aufwecken, wenn eine bestimmte Zahl Counts überschritten ist). Na jedenfalls, falls jemand noch einen "schwierigen Baustein" (stimmt vermutlich nicht) für seine China-Bestellung sucht: den habe ich vorhin vergessen...).

Und wer I2C-Bausteine nutzen will, braucht meistens 3.3V. Das ist v.a. dann "gut", wenn man die RFM-Varianten für Funk im Einsatz hat! Damit wird dann das Platinenlayout wieder deutlich einfacher, man muß nur ggf. die Frequenz des ATMega runter nehmen... (@Wernieman: Es gibt afaik. ein paar ziemlich ausgereifte Platinen dafür; RFM ist typischerweise 868MHz oder 433MHz...)
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 Gisbert

  • Hero Member
  • *****
  • Beiträge: 2064
  • Das Ziel ist das Ziel !
Antw:Incoming
« Antwort #56 am: 11 Mai 2020, 14:01:53 »
@Beta-User: zum induktiven Näherungssensor LJ18A-A3-8-Z/BY am Wasserzähler (Foto im Link), der bei mir funktioniert, siehe diesen Thread.
Aktuelles Fhem auf HP ThinClient T610 | Debian10 | UniFi-Controller | Homematic, VCCU, HMUART | ESP8266, Platinen von Papa Romeo | Gas-, Wasser-, Stromzähler | Sonoff | 1-Wire-Temperatursensoren | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21RF

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13620
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #57 am: 11 Mai 2020, 14:13:54 »
Ah ok, den Thread kannte ich, es fehlte mir nur das Bild dazu (ist im ersten Beitrag hier: https://forum.fhem.de/index.php/topic,110021.msg1040217.html#msg1040217).
Meiner ist ein "MNK" (S. 6 hier) ohne "Fernausleseoption"). Ich vermute zwar, dass in der Mitte trotzdem irgendwas magnetisches verbaut ist (wie bei dem "MNK-N") anzunehmen, aber "auf Risiko" hole ich mir im Moment nicht "noch einen" Sensor aus China, sondern werde erst mal meinen "Pulser" versuchen richtig auszurichten. Mal schauen, ob ich schneller bin wie der lokale Wasserversorger - der muss kommendes Jahr sowieso wieder getauscht werden (von daher ist zum "veralgen" eh' nicht mehr so viel Zeit, falls ich das mit dem Pulsen doch sein lassen müßte)...

Für die Zähler mit dem relativ großen roten Halbreis würde mMn. auch ein (ggf. auf grünes Licht modifizierter) TCRT5000 gehen, bei Stall.biz gibt's dafür eine schöne Bauanleitung. Ein "normaler TCRT5000" (in Fertigmodulform) werkelt hier auch ohne erkennbare Probleme beim Gaszähler (Pipersberg Balgenzähler mit reflektierender 6).

EDIT sagt:
LJ18A-A3-8-Z/BY
Der hat 8mm, nicht 12, oder? Die 8mm-Variante habe ich nämlich (nach einer netten Diskussion mit Schotty zu diesem Thema) extra auch ausgetestet. Der wollte nichts erkennen (dahinter war eine Optokopplerschaltung; der Teil funktionierte...).
« Letzte Änderung: 11 Mai 2020, 14:19:06 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 Gisbert

  • Hero Member
  • *****
  • Beiträge: 2064
  • Das Ziel ist das Ziel !
Antw:Incoming
« Antwort #58 am: 11 Mai 2020, 15:07:15 »
Hallo Beta-User,
ich habe genau den hier, Durchmesser 16.5mm und Detection distance: 8mm, vielleicht liegt hier die Dieskrepanz. Es gibt, glaube ich, noch fettere Teile, deren Detektionsdistanz noch größer ist, vorausgesetzt, es gibt etwas Metallisches, was sich detektieren lässt.
Viele Grüße Gisbert
Aktuelles Fhem auf HP ThinClient T610 | Debian10 | UniFi-Controller | Homematic, VCCU, HMUART | ESP8266, Platinen von Papa Romeo | Gas-, Wasser-, Stromzähler | Sonoff | 1-Wire-Temperatursensoren | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21RF

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 13620
  • "Developer"?!? Meistens doch eher "User"
Antw:Incoming
« Antwort #59 am: 11 Mai 2020, 15:32:39 »
Na ja, zusammengefaßt zu dem [OT-] Thema Wasserzähler: nix genaues weiß man nicht, die Zähler sind auch definitiv nicht dieselben. Was auf dem Bild mit dem "-N" gut zu erkennen ist: Zenner selbst scheint eher einen Reed-Kontakt einzusetzen, und den dann ziemlich genau in der Mitte des Zählers zu positionieren. Von daher bin ich eher skeptisch, ob der Magnet/das Metallplättchen da wirklich auch bei der "Nicht-N"-Variante drin ist. Irgendwo gab es auch Zeichnungen, wie mein Zähler intern aussieht, und da könnte es schon sein, dass das als Zusatzbauteil ausgelegt ist, das man bei Nichtbedarf weglässt... Falls es weiter regnet, finde ich vielleicht Zeit, die Laser-Variante mal wirklich zu fixieren (das Problem ist: Man muß den Laser in einem gewissen Abstand über dem Zähler fixieren, und dann das reflektierte Restlicht detektieren. Die simpelste Variante wäre ein Kunststoffrohr drüberzustülpen (auch wegen anderen Lichteinflüssen) und beide Teile daran innen festzuzurren. Aber da war irgendwann die Geduld aus und kein passendes Stück Rohr zur Hand, und auch keine große Rohrschelle, mit der ein Winkel über dem Zähler zu justieren gewesen wäre... Muß aber wohl eh' demnächst mal wieder mit die Maske überziehen und den Baumarkt überfallen ::) .)


Back in topic:
Hier berichtet jemand, dass er aktuell Probleme hätte mit der Blue Pill: https://forum.mysensors.org/topic/11151/how-to-compile-mysensors-on-platformio-for-blue-pill. Das sieht mir aber nicht nach Problemen beim Flashen aus, sondern eher mit dem STM32-Core (ich bin mir aber ziemlich sicher, dass ich im Keller ein RFM69-Gateway auf Maple-Basis liegen habe, das mit älteren libs compiliert wurde und funktioniert.



Was das Thema Sternverkabelung angeht: PJON schein in die Richtung toleranter zu sein (war jedenfalls auf den neulich hier verlinkten Seiten zu lesen, wenn auch nicht im Zusammenhang mit MySensors).
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