Selbstbau CUN (MapleCUN)

Begonnen von Telekatz, 09 November 2016, 20:29:52

Vorheriges Thema - Nächstes Thema

vbs

Ja, Kondensator ist dran, jedoch nur 22uF. Hab gerade nochmal auf 100uF upgegradet. Kann aber nicht wirklich einschätzen, wie hoch die Chancen sind, dass es daran liegt.

Ranseyer

Schwer zu sagen. Solange ist nicht sauber läuft würde ich:
-gutes USB Netzteil
-mindesten 100uF nehmen.
Wenn es läuft kannst du ja abrüsten.

(100uF ist beim Raspi Homematic Adapter für den HM_Mod-UART auch dabei, Achtung Tantal = ggf. kleine Bombe falls verpolt)
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!

vbs

Ok, Danke für die Tipps!

Hab jetzt:

  • 100uF Kondensator
  • USB-Netzteil angeschlossen (Sony 1,5A Handyladegerät. Ist wahrscheinlich auch nicht gerade der Inbegriff von "gutes Netzteil", aber mal gucken...)
  • ... hab ansonsten noch einen anderen Maple da (aber auch nicht-Baite), den ich dann nochmal ins Rennen schicken würde

Markus.

Hab da ein seltsames Problem beim Umstieg der Definition auf STACKABLE.
Getestet habe ich vorher mit STACKABLE_CC und da ist alles soweit gelaufen. Dann habe ich alle Devices mit STACKABLE_CC
gelöscht und FHEM neu gestartet und folgende Definition verwendet.


define MAPLECUN_0_868 CUL 192.168.178.21:2323 4444


define MAPLECUN_0_868Stack STACKABLE MAPLECUN_0_868
define MAPLECUN_1_433 CUL FHEM:DEVIO:MAPLECUN_0_868Stack:9600 0000

define MAPLECUN_1_433Stack STACKABLE MAPLECUN_1_433
define MAPLECUN_2_868 CUL FHEM:DEVIO:MAPLECUN_1_433Stack:9600 0000

define MAPLECUN_2_868Stack STACKABLE MAPLECUN_2_868
define MAPLECUN_3_868 CUL FHEM:DEVIO:MAPLECUN_2_868Stack:9600 0000


Die devices werdn auch als initialized angezeigt. Dann habe ich ein bei einem IT Stecker das IO Device auf den Maple (433) umgestellt und danach hängt FHEM komplett. Nur ein Neustart des Raspis hilft da und der dauert dann auch ewig lange.

Wie gesagt mit STackable_CC habe ich dieses Problem nicht.

Hoffe da hat einer eine Idee..

Gruß

Markus

Markus.

Und noch ne Frage, da ich gerne viel austeste ;-)

Die Platine kann ja auch Homematic mit einem CC1101 868MHz, worin liegt der da der Vorteil Wenn man einen HMUart zusätzlich verbaut? Erschlagt mich nicht direkt wenn das irgendwo steht und ich es überlesen haben sollte ;-)
Macht das nur Sinn wenn man alle 868 Radios bereits anderweitig nutzt?
Mit der letzten Firmware-Version werden ja auch Lacrosse erkannt als Homematic devices oder...?!?

Gruß

Markus

dkreutz

Zitat von: Markus. am 23 November 2018, 08:35:21
Die Platine kann ja auch Homematic mit einem CC1101 868MHz, worin liegt der da der Vorteil Wenn man einen HMUart zusätzlich verbaut? Erschlagt mich nicht direkt wenn das irgendwo steht und ich es überlesen haben sollte ;-)
Macht das nur Sinn wenn man alle 868 Radios bereits anderweitig nutzt?
HM-UART ist "das Original", bei CC1101+(a)culfw ist das Protokoll reverse-engineered. Ob sich das praktisch auswirkt hängt von vielen Faktoren ab.

Zitat von: Markus. am 23 November 2018, 08:35:21
Mit der letzten Firmware-Version werden ja auch Lacrosse erkannt als Homematic devices oder...?!?
Ja, LaCrosse über CC1101-868 wird erkannt, aber nicht als Homematic sondern HMS. (Wenn Du bisher einen JeeLink-CUL hattest, dann musst Du alle LaCrosse-Devices neu als HMS-Device anlegen (bzw. werden durch autocreate neu angelegt).
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

Markus.

danke dir erstmal für die Antwort...
Nun muss ich nur noch dieses seltsame STACKABLE(_CC) Problem in den griff bekommen.

Gruß

Markus

vbs

#877
So wie ich das bzgl. Homematic verstehe, sind die Timings des Protokolls ein großes Problem. Gibt dafür einen eigenen Fork der cul-FW, die das wohl schon besser beherrscht. Aber wohl auch nicht perfekt. Daher wird von vielen empfohlen, für Homematic immer ein original HM-IO-Device zu benutzen (also z.B. HM-MOD-UART). Da kümmert sich dann dieses Device selbst um das Einhalten der Timings. So zumindest mein Verständnis.


Zu meinen Abstürzen:
Also das scheint momentan stabil zu laufen: 2 Tage ohne Abstürze. Werde es weiter beobachten, aber scheint nun stabil zu sein. Ich habe momentan einen 100uF Kondensator dran und zusätzlich ein externes USB-Netzteil.
Eigentlich würde ich das externe Netzteil gerne wieder los werden. Ist schon sexy, wenn das Ding direkt vom PC per USB-Kabel gepowert wird. So wie ich das sehe, ist Kondensator C5 im Schaltplan mit 220uF angegeben. Macht es Sinn auszuprobieren, das USB-Netzteil wegzulassen und dafür den 100uF durch 220uF zu ersetzen?

Das Ganze würde dann bei mir in der Kategorie "Viel hilf viel!" laufen  :-X

Ranseyer

Zitat220uF zu ersetzen?
Die Zahl ist von mir. Ich hätte das Feld leer lassen können. Statt dessen habe ich halt 220uF vorgesehen. Ich verbaue meist 47uF. (Und nutze nur noch gute USB-Netzteile. Der CUL in der Garage wird vom Router gespeist, aber nur weil es halt zufällig funktioniert)

Das Problem ist doch auch dass dir keiner sagen kann welche Spannung an Deiner USB Buchse wirklich noch anliegt wenn diese belastet wird. Zweitens: die Qualität der Spannung = Restwelligkeit unter Last = ???
Falls du die Speisung über die Hohlbuchse machst wäre z.B. ein dickeres Kabel denkbar, und auch das kann notfalls an einem USB-A Stecker enden...
Was sicher nicht schadet: ein kleiner Keramik-Kondensator zusätzlich am Eingang um evtl. hochfrequente Sachen kurzzuschliessen. Kann ja sein dass Du Powerline oder anderes Zeug in der Nähe hast.

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!

vbs

Ok, danke für die Tipps! Muss zugeben, dass mich das schon an die Grenzen meiner bescheidenen Elektro-Kenntnisse bringt...
Ich hab an dem gleichen Rechner bisher einen HM-USB-CFG2 und einen RfxTrx433 per USB betrieben und das war problemlos. Ist sicherlich nicht dasselbe wie der Maple aber ich würde hoffen zumindest vergleichbar.
Also ich werde da mal einfach etwas rumprobieren mit Kondensatoren und Kabel usw. Der Baite-Maple ist ja auch unterwegs. Evtl. ist der ja auch etwas stabiler bzgl. Spannunsgschwankungen. Der wird aber sicherlich noch ein paar Wochen unterwegs sein. Blöd, dass ich wohl besser mit dem Löten auf die Platine warten sollte, bis das alles geklärt ist  :-\

vbs

Ja klasse, ist doch wieder passiert... kaum hat man's gesagt  >:(

Aber eine neue Erkenntnis: ich hab jetzt ja am Maple eine externes USB-Netzteil, so dass der Maple weiter läuft (nicht gepowercyclet wird), wenn ich den normalen USB-Stecker abziehe. Und interessanterweise ist es so, dass der Maple wieder funktioniert (also ich wieder per seriell mit dem HM-MOD-UART reden kann), wenn ich USB einmal abziehe und wieder dran stecke!
Also was sich offenbar nur aufhängt, ist die USB-Verbindung an sich (dieses Device /dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04).
Ich ziehe momentan in Betracht, dass es gar nix mit der Spannungsversorgung zu tun hat.

Das Ding bietet ja in Linux drei serielle Devices an. Es betrifft nur das Device, über den der HM erreichbar ist (/dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if04). Das "normale" Device, mit dem der 433-CUL bedient wird (/dev/serial/by-id/usb-STM32_MapleCUL_a3b08c7a-if00), läuft dauerhaft durch.
Könnte also auch ein Firmware-Bug in der aculfw sein? Oder ein Problem mit meinem Linux? Oder was ganz anderes... Vielleicht frage ich mal drüben im aculfw-Thread...

Eistee

Also ich hab über WLAN/RJ45 keine Probleme mit dem MapleCUN und ich habe auch Homematic und gleichzeitig noch MAX mit scanner am laufen. USB nutze ich nicht in meinem Produktivsystem da kann ich nur sagen das es funktioniert wenn ich ihn anstecke. Wie lang das stabiel läuft weiß ich aber nicht. Ich habe mal gemessen das mein MapleCUN im leerlauf 250mA zieht. Um Stromspitzen beim senden zu messen habe ich leider kein Messgerät für. aber mit einem Noname 500mA Netzteil gibt es keine Probleme. Was ich weiß ist das es wohl Probleme mit Schnelladegeräten gibt wie Apple sie z.B. meist zu Handys zu legt da diese nur dann Strom liefern wenn dem Netzgerät ein Chip sagt was es tun soll. Mit Apple Netzgeräten habe ich definitiv Rückmeldungen bekommen das es beim Senden zum Absturz bzw neustart des MeplaCUN kommt.

vbs

In meinem Fall ist es so, dass der Maple nicht resettet wenn Homematic ausfällt, sondern weiter läuft. Halte es eher für unwahrscheinlich, dass der Controller wegen Spannungsproblemen aufhört, eine Schnittstelle zu bedienen. Aber ausschließen will ich nix.

Leinad

Eine Frage für dummies 😀

Ich blicke nicht ganz durch.
Wie/wo wird konfiguriert an welcher Position welches Funkmodul hängt (433 / 868)? Der Wikieintrag hat mich bisschen verunsichert.
Ist es nicht so, dass die Anordnung total egal ist, solange ich die Reihenfolge beim define bzw. beim Auswählen des Funkprotokolls beachte?

RaspiLED

Ja ist richtig, aber der Werksreset Standard ist 1,3,4 auf 868 und 2 auf 433. okay die meisten Platinen zählen 0-3: 0,2,3 auf 868 und 1 auf 433
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...