Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

noansi · 22 Januar 2018, 22:13:14

Hallo presskopf,

ZitatBei den Bewegungsmeldern fehlen noch welche (RegL_00.,RegL_01.).

Vermutlich wirst Du, je nach Typ, um getConfig mit Knöpfchen drücken nicht herum kommen.

Gruß, Ansgar.

noansi · 22 Januar 2018, 23:06:09

Hallo Heinz,

Zitatbesteht die Möglichkeit auch den CUBE mit TSCUL zu flashen analog zu aCULFW?

Die Möglichkeit würde eine intensive Anpassung des Codes an die Hardware erfordern. Derzeit daher nicht.

Gruß, Ansgar.

presskopf · 23 Januar 2018, 10:58:34

Zitat von: noansi am 22 Januar 2018, 22:13:14
Hallo presskopf,
Vermutlich wirst Du, je nach Typ, um getConfig mit Knöpfchen drücken nicht herum kommen.

Gruß, Ansgar.

Top, ging hier auch wie Schmitz Katze!

Nachtrag: Auch die Templisten flutschen jetzt ohne Murren rüber!

Heggeg · 24 Januar 2018, 19:18:21

Zitat von: noansi am 22 Januar 2018, 22:10:19
Hallo Heggeg,

vielleicht noch eine Idee, kannst Du in Deinem virtuellen Ubuntu USB2.0 Unterstützung abschalten?
Möglicherweise hilft das?

Gruß, Ansgar.

Wen ich das abschalte funktioniert das USB Passthrough des CULs nicht mehr.
Nun habe ich in meinen ESX folgende PCI-E USB Karte eingebaut und meiner VM via PCI-Passthrough präsentiert und siehe da - CUL in einen der Ports von der Karte gesteckt und es gibt keine Fehlermeldungen mehr im dmesg Log. Ich bedanke mich für deine tolle Firmware und die Unterstützung. Endlich kann ich anfangen meine Homematic Landschaft aufzubauen.

Gruß,
Heggeg

noansi · 24 Januar 2018, 22:13:10

Hallo Heggeg,

ZitatNun habe ich in meinen ESX folgende PCI-E USB Karte eingebaut und meiner VM via PCI-Passthrough präsentiert und siehe da - CUL in einen der Ports von der Karte gesteckt und es gibt keine Fehlermeldungen mehr im dmesg Log.

Danke für das Feedback und schön, dass es so funktioniert. Demnach müßte es wohl ein USB-Virtualisierungs- oder Treiberproblem auf Deiner Plattform gewesen sein.

Hätte mich schon interessiert was da wie schief läuft. Sähe aber andererseits gefühlt dann nach Würgarrounds inklusive Übertragungsdelays aus, die dann zu weiteren unerwünschten Nebenwirkungen geführt hätten.

@Joachim: Der Hinweis mit der USB Karte und PCI-Passthrough bei FHEM in VM wäre wohl auch was für den Wiki Artikel.

Gruß, Ansgar.

davedeluxe · 25 Januar 2018, 09:25:25

Hi,

ich nutze seit einiger Zeit diese Firmware da ich mit der "Standardfirmware" immer Probleme mit meinen HM-Rolladenaktoren hatte.
Ich nutze/nutzte zusätzlich noch einen weiteren nanoCUL im SlowRF Mode für meine ESA 2000 Energiemessung.

Beide CULs basieren auf Arduino Nano V3 FTDI´s.

Leider bekomme ich immer wieder Probleme wenn ich beide CUL´s angeschlossen habe. Meistens tritt der Fehler auf das keine Daten mehr von den Homematic-Senoren/Aktoren ankommen bzw. gesendet werden. In der Log finde ich keine Einträge.

Gibt es irgendwas zu beachten wenn ich zwei CUL´s nutze? Kann/muss der CUL für SlowRF auch diese ASKSIN Firmware nutzen oder kann er auch mit der "Standard-Firmware" laufen?

Grüße Dave

Omega-5 · 25 Januar 2018, 09:46:22

Zitat von: davedeluxe am 25 Januar 2018, 09:25:25
Beide CULs basieren auf Arduino Nano V3 FTDI´s.

Du kennst das Problem mit den FAKE-FTDI? Gleiche Seriennummer -> nur einer wird erkannt. Vieleicht hast du ja Nanos aus diesen Produktionen.
Mache mal ein

Code Auswählen

ls -l /dev/serial/by-id
oder

Code Auswählen

ls -l /dev/serial/by-path

Gruß Friedrich

MadMax-FHEM · 25 Januar 2018, 09:47:19

Hi Dave,

ich hatte damals ebenfalls 2 nano-CULs laufen.

Gut nicht wirklich 2 CULs einer war ein mySensorsGateway...

Wie hast du die eingebunden?

/dev/serial/by-id?
/dev/serial/by-path?
/dev/ttyUSB?

Kommen "einfach so" im Betrieb keine Daten mehr oder z.B. nach einem Neustart etc.?

Das wären mal die einfachsten Dinge die zu prüfen sind...

Wenn da alles passt und eigentlich nichts "durcheinander" kommen kann, muss man weiter analysieren (wenn der Fall wieder auftritt)...

Leider habe ich inzwischen mein Testsystem mit CULs "abgebaut"...

EDIT: und wieder zu langsam

Gruß, Joachim

MadMax-FHEM · 25 Januar 2018, 09:50:36

Zitat von: noansi am 24 Januar 2018, 22:13:10
@Joachim: Der Hinweis mit der USB Karte und PCI-Passthrough bei FHEM in VM wäre wohl auch was für den Wiki Artikel.

Gruß, Ansgar.

Hallo Ansgar,

ich muss mich entschuldigen.

Die Idee mit dem Wiki hatte ich in der "Weihnachts-Frei-Euphorie"

Leider bin ich aktuell etwas eingebunden aber ich hab's nicht vergessen und noch vor...

Ich sammle schon fleißig, muss nur noch Zeit finden das dann zu sortieren und mal zusammenzuschreiben.
Nehme ich mit auf (falls ich's vergessen sollte: einfach erinnern

).

Gruß, Joachim

davedeluxe · 25 Januar 2018, 09:51:40

nein das passt alles, sind 2 unterschiedliche Seriennummern.
ich habe auch schon mehrere Arduinos durchprobiert, kein Unterschied.

Eingebunden habe ich sie per ID, getestet habe ich per path und per tty - alles ohne Erfolg.
Wobei das Fehlerbild das du da beschreibst auf meine Probleme zutrifft.
Ich habe noch nen SuperJee laufen, der macht keine Probleme.

noansi · 25 Januar 2018, 21:40:16

Hallo Dave,

ZitatGibt es irgendwas zu beachten wenn ich zwei CUL´s nutze? Kann/muss der CUL für SlowRF auch diese ASKSIN Firmware nutzen oder kann er auch mit der "Standard-Firmware" laufen?

theoretisch bietet auch die tsculfw ESA Empfang. Allerdings mangels Hardware ungetestet und daher in TS_CUL.pm bisher auch auskommentiert.

CUL und TS_CUL sollten sich eigentlich nicht ins Gehege kommen. D.h. den nano mit tsculfw definierst Du mit TS_CUL und den nano mit Standardfirmware oder a-culfw mit CUL.

Wenn Du das so gemacht hast denke ich auch eher, dass Du schon mal USB Verbindungsverlust hast oder eher das USB Vertauschungsproblem je nach Systemneustartart, wenn Du nicht eindeutig die USB-Seriennummern den seriellen devices in der 99-usb-serial.rules zugeordnet hast oder mit /dev/serial/by-id arbeitest. Die Schnittstellenzuordnung muss eindeutig passen. Nur weil die nanos eindeutige Seriennummern haben bedeutet es nicht, dass sie auch immer den gleichen Schnittstellen zugeordnet werden.

Schau Dir ggf. mit dmesg an, welcher Schnittstelle der jeweilige nano zugeordnet wird. Bei mir war es so, dass beim RasPi Warmstart mit "sudo shutdown -r now" eine andere Zuordnung meiner USB CULs stattgefunden hat, als beim Hochfahren nach stromlos machen.

Gruß, Ansgar.

en-trust · 01 Februar 2018, 17:01:36

Ich wollte nun den CUL neu definieren...

Code Auswählen

define myCUL_868 TSCUL /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5.4:1.0@38400 F088

erhalte aber...

Code Auswählen

FHTID must be H1H2, with H1 and H2 hex and both smaller than 64

Ich habe aber gar kein FHT.

noansi · 02 Februar 2018, 20:17:48

Hallo Sven,

ZitatIch habe aber gar kein FHT.

Aber mit F088 eine FHT Id einstellen wollen, die den korrekten Kriterien nicht entsprechen.
Da Du kein FHT hast, ist 0000 statt dessen richtig.

Die übrigen Fragen hast Du Dir wohl inzwischen durch Lesen und Probieren selber beantworten können.

Gruß, Ansgar.

en-trust · 02 Februar 2018, 20:33:57

Aber ich brauche doch eine hmId analog zur vccu für die Homematic's und da wurde hier immer gesagt nimm einen hexacode. Jetzt heißt es nimm 0000.

noansi · 02 Februar 2018, 20:53:46

Hallo Sven,

ZitatAber ich brauche doch eine hmId analog zur vccu für die Homematic's und da wurde hier immer gesagt nimm einen hexacode. Jetzt heißt es nimm 0000.

z.B.:

Code Auswählen

attr myCUL_868 hmId F1F088

Wenn Du das Attribut nicht setzt, aber eine FHTID (die nicht 0000 ist), dann wird die mit vorangestelltem "F1" als hmID per default benutzt. Aber die FHTID muss immer noch im gültigen Bereich liegen. Dieses (wenig übersichtliche) Verhalten habe ich nur so vom CUL Modul übernommen.

Oder gehes direkt mit einer VCCU an (der Du auch eine hmId zuweisen musst) und weise der Deinen CUL als IO zu.

Gruß, Ansgar.