nanoCUL mit a-culfw disconnected

Begonnen von moerte, 14 Dezember 2018, 14:15:23

Vorheriges Thema - Nächstes Thema

moerte

So kleine Rückmeldung..
Hab ein USB hub Netzteil mit 4,5A angeschlossen, leider besteht das Problem weiterhin.
Auch ein herabsetzen der Sendeleistung bringt leider nichts.

Was mir noch auffällt, dass mein anderer CUL vom Hauptraspberry (CUL433) auch immer mitsendet. Obwohl ich das Attribut IOdev dem CUL_1 zugewiesen habe. Vlt stören die beiden sich und dann bricht die Verbindung vom CUL_1 ab?

Kleiner Auszug nochmal aus dem Log:


2018.12.18 08:35:27 3: CUL433 IT_set: Bogen_Bad off
2018.12.18 08:35:28 3: CUL_1 IT: Bogen_Bad off->off
2018.12.18 08:35:30 3: CUL_1 IT_set: Bogen_Lucy_links off
2018.12.18 08:35:30 3: CUL433 IT: Bogen_Lucy_links off->off

Beta-User

Hmm, also der Aufbau war (anderes Netzteil)-Pi-aktiver Hub-CUL?
Dann dürfte es nicht an der Stromversorgung liegen.

Und die beiden CUL kommen sich m.E. nur insoweit "in die Quere", dass der eine das empfängt, was der andere sendet. Das ist ganz normal.

Dann ist es entweder die Hardware, oder die Störung kommt aus dem Netzwerk (typischerweise: PowerLAN, gelegentlich auch WLAN - v.a. Pi-WLAN+Fritzbox ist "berüchtigt").
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

moerte

Mhhh- ja die Stromversorgung kann ich denk jetzt ausschließen.
Ich mach jetzt mal noch eins .. da auf dem raspberry ja wirklich nur ser2net  läuft und sonst nichts anderes, ein Upgrade.

Und mhhh, ja er steckt an einen Fritz Mesh repeater über LAN Kabel dran.
Ich schau heut nochmal bisschen, und wenn ich es nicht hinbekomme,  schaue ich mich nach einen anderen und am besten orginal CUL um.

So komm ich denk nicht weiter.
Mich macht es nur eben stutzig warum geht's mit der culfw ohne Probleme Tagelang. Und mit der a-culfw eben nicht.
Da komm ich an meine Grenzen.

Na mal schauen

Beta-User

Wenn es nur ein firmware-Problem sein sollte (kann auch mal vorkommen): mal Signalduino antesten? (die 433-er Geräte muß man dazu nach meiner bisherigen Erfahrung nicht umkonfigurieren).
Einen original-CUL würde ich persönlich nicht mehr kaufen. Wenn es ein neues netzwerkfähiges Interface sein soll, würde ich den MapleCUN ins Rennen werfen... Der kann zum praktisch gleichen Preis viel mehr und du mußt keinen Pi mehr warten ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

moerte

#19
Da höre ich jetzt das erste mal davon .. MapleCUL
.. Selbstbau fällt für mich aus, da ich grobmotoriker bin und keine Lötkenntnisse habe etc.
Jetzt hab ich mal danach geschaut, gibt ja schon viel verschiedenes fertig zu kaufen.
Weiß nicht ob ich das hier darf, einen Link aus der Bucht zu schicken (Ansonsten bitte löschen)

https://rover.ebay.com/rover/0/0/0?mpre=https%3A%2F%2Fwww.ebay.de%2Fulk%2Fitm%2F113408219215


So was in der Art?
Sieht für mich wie ein normaler nano CUL aus und nicht wie in fhem Wiki er beschrieben wird.


Beta-User

#20
Jein.

Es gibt ihn auch mit 4 Transceivern und (v.a.!) Netzwerkanschluß, dazu zwei UART-Anschlüsse, siehe https://wiki.fhem.de/wiki/MapleCUN.
Kann sein, dass der dann mit vernünfitgen Antennen etwas teuerer wäre, Angebote gibt es in der Regel auch hier im Forum (Marktplatz/Güter), da ist in der Regel der Preis halt Material+Unkosten. Wenn du "irgendwo" kaufst, ist der support leider häufig mau, und "Schrumpfschlauch"-Varianten hatten wir leider beim "Selbstbau-CUL" einige, die nicht richtig funktioniert hatten, weil diese Schrumpfköpfe falsche FTDI's untergeschoben erhalten hatten oder sich Spannungsteiler gespart, oder oder oder...

Wo ich das schreibe: Suche nach deiner FTDI-Nummer ergibt u.a. https://softsolder.com/2016/09/02/counterfeit-ftdi-usb-serial-adapter-roundup/
Vielleicht magst du deinem freundlichen Verkäufer auf's Dach steigen!?!

Nachtrag (aus http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html):
ZitatWhy it is important to spot a fake FTDI fake  and why I am posting it ? Because it can ruin your day like it did for me ! Fake FTDI chips are unreliable especially at higher baud rates and you may be pulling your hair troubleshooting your project while the problem is in fact a cheap fake chip.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

moerte

Ja und so ein CHIP wird da bestimmt bei dem Link aus der Bucht verbaut sein.. ich lasse da die Finger von und schau hier mal im Forum unter Güter ..ansonsten mach ich mal ein Kaufgesuch.
Vielen Dank dir für deine Mühen

Edit: ein Upgrade vom raspberry ändert auch nichts. Ist so. Liegt dann wohl doch am CUL

Beta-User

Zitat von: moerte am 18 Dezember 2018, 14:10:19
[...] so ein CHIP wird da bestimmt bei dem Link aus der Bucht verbaut sein..
Nö!
Nur zur Klarstellung, da liegt ein Mißverständnis vor.
Ein Arduino Nano besteht intern aus 2 größeren IC's, nämlich dem eigentlichen Microprozessor (ATMega32) und einem USB-Seriell-Wandler, hier vermeintlich von FTDI.
Der Maple (bzw. der STM32F103) macht das USB-Interfacing selbst. Die Firmware als MapleCUx stellt dabei sogar 3 logische USB-Ports bereit, einen für die eigentliche CUL-Funktion (die 4 gestackten Transceiver), und je einen für die beiden UART (mit denen man dann z.B. ein Pi-Homematic-PCB betreiben kann).

Steht aber eigentlich (in Kurzform) auch in dem Wiki-Artikel ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors