Hallo zusammen!
Ich mache gerade meine ersten Versuche mit fhem und arbeite mich durch die Dokumentation. Setup bisher: Ein Raspi 2 mit Raspbian Buster und fhem (easy way Installation, Betriebssystem und fhem gestern frisch upgedated und neu gestartet).
Derzeit habe ich noch kein USB-Device (nanoCUL ist bestellt), daher (?) hängt fhem nach einem Neustart ("Probing" von diversen Devices, 100% CPU, kein Zugriff auf WebGUI), aber ein Neustart via SSH bringt die WebGUI zum Leben.
OK, ich möchte als erste Übung ein paar Heizkostenverteiler auslesen, diese habe ich nach der Doku angelegt, z.B.:
define T TechemHKV 1234 Treppe
https://wiki.fhem.de/wiki/TechemHKV (https://wiki.fhem.de/wiki/TechemHKV)
https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#R.C3.A4ume_definieren
(https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#R.C3.A4ume_definieren)
Richtige 4-stellige Nr. habe ich aus der Abrechnung.
Danach habe ich die HKVs zu rooms zusammengefasst, wie in "Erste Schritte" beschrieben.
Jetzt wollte ich einen log file für diesen HKV "T" wie "Treppe" anlegen, mit:
define T_log FileLog /opt/fhem/log/T-%Y-%m.log T
https://wiki.fhem.de/wiki/FileLog (https://wiki.fhem.de/wiki/FileLog)
https://fhem.de/commandref.html#FileLogdefine (https://fhem.de/commandref.html#FileLogdefine)
und ich bekomme in der WebGUI unter FileLog angezeigt:
Internals
CFGFN
DEF /opt/fhem/log/T-%Y-%m.log T
FD 12
FUUID 5d2eddf9-f33f-d504-95ab-85a72aa4a86f9749
NAME T_log
NOTIFYDEV T
NR 209
NTFY_ORDER 50-T_log
REGEXP T
STATE active
TYPE FileLog
currentlogfile /opt/fhem/log/T-2019-07.log
logfile /opt/fhem/log/T-%Y-%m.log
Ist das so korrekt, um alle readings aus dem HKV (also current, previous, temp1 und temp2) zu loggen?
https://wiki.fhem.de/wiki/TechemHKV (https://wiki.fhem.de/wiki/TechemHKV)
Sollte Ich für das logging (neben der 16 GB SD-Karte für raspbian und fhem) einen USB-Stick mounten, weil mir sonst die Karte mit den logs nach ein paar Wochen volläuft?
Wie könnte ich alle Werte nur einmal pro Stunde (und den previous gar nicht) loggen?
Tausend Dank vorab!
Hallo,
zu 1. Du kannst die USB-Erkennung ausschalten, indem du in der fhem.cfg das hier suchst
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
und vor das define ein # machst dann shutdown restart in die Kommandozeile für Neustart
zu 2. wenn du ein Device angelegt hast, geht ein LOG anzulegen mit createlog <Devicenamen> recht einfach
Grüße
Christian
Zitat von: cs-online am 17 Juli 2019, 12:33:30
Hallo,
zu 1. Du kannst die USB-Erkennung ausschalten, indem du in der fhem.cfg das hier suchst
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
und vor das define ein # machst dann shutdown restart in die Kommandozeile für Neustart
zu 2. wenn du ein Device angelegt hast, geht ein LOG anzulegen mit createlog <Devicenamen> recht einfach
Grüße
Christian
Da er ja nun Zugriff auf das WebGui hat macht er es natürlich nicht.
Finger Weg von der Konfigdatei bitte. Statt dessen lernst Du den Umgang mit der GUI.
list initialUsbCheckzeigt Dir das Gerät. Ist ja im Grunde ein Notify. Du klickst auf den Namen und kommst in die Details. Da kannst Du dann auf Status disabled oder so mittels set setzen.
Bei Fragen einfach fragen.
Danke für die Antworten!
Das Problemchen ist ja, dass keine WebGUI verfügbar ist nach Reboot, weil fhem nach Devices auf AMA0 sucht, hier ein log nach dem Reboot
2019.07.16 16:20:41 1: Including fhem.cfg
2019.07.16 16:20:42 3: WEB: port 8083 opened
2019.07.16 16:20:42 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2019.07.16 16:20:42 1: Including ./log/fhem.save
2019.07.16 16:20:42 1: usb create starting
2019.07.16 16:20:43 3: Probing ZWDongle device /dev/serial0
2019.07.16 16:20:43 3: Probing CUL device /dev/ttyAMA0
2019.07.16 16:20:43 3: Probing TCM_ESP3 device /dev/ttyAMA0
2019.07.16 16:20:43 3: Probing ZWDongle device /dev/ttyAMA0
2019.07.16 16:20:43 3: Probing SIGNALDuino device /dev/ttyAMA0
2019.07.16 16:20:44 3: Probing MYSENSORS device /dev/ttyAMA0
2019.07.16 16:20:44 3: Probing ArduCounter device /dev/ttyAMA0
2019.07.16 16:20:44 3: Probing ElsnerWS device /dev/ttyAMA0
2019.07.16 16:20:45 3: Probing FRM device /dev/ttyAMA0
CPU hängt bei 100% wegen perl/fhem und WebGUI nicht erreichbar.
Bei mir gibt
list initialUsbCheck
Internals:
DEF global:INITIALIZED usb create
FUUID 5d2368d9-f33f-d504-df40-cc6857297aab595c
NAME initialUsbCheck
NOTIFYDEV global
NR 13
NTFY_ORDER 50-initialUsbCheck
REGEXP global:INITIALIZED
STATE 2019-07-16 16:53:00
TRIGGERTIME 1563288780.03696
TYPE notify
READINGS:
2019-07-16 16:53:00 state active
Attributes:
Was könnte ich das disablen?
_________________
Wegen der logs:
https://fhem.de/commandref.html#createlog (https://fhem.de/commandref.html#createlog)
...verrät nicht viel dazu, da die Techem HKV manuell angelegt werden, bräuchte ich einen Hinweis, wie ich die logs korrekt anlege. Ist der Weg über "define ... LogFile..." komplett falsch?
Sorry aber das verstehe ich nicht. Wenn Du das list machen konntest dann bist Du doch im FHEM GUI.
Internals:
DEF global:INITIALIZED usb create
FUUID 5d2368d9-f33f-d504-df40-cc6857297aab595c
NAME initialUsbCheck
NOTIFYDEV global
NR 13
NTFY_ORDER 50-initialUsbCheck
REGEXP global:INITIALIZED
STATE 2019-07-16 16:53:00
TRIGGERTIME 1563288780.03696
TYPE notify
READINGS:
2019-07-16 16:53:00 state active
Attributes:
Hinter NAME steht ja initialUsbCheck das ist ein Link. Klick drauf und du kommst in die Detailansicht. Hier kannst du glaube set inactive setzen. Das sollte reichen.
Aus meinem 1. Post:
ZitatDerzeit habe ich noch kein USB-Device (nanoCUL ist bestellt), daher (?) hängt fhem nach einem Neustart ("Probing" von diversen Devices, 100% CPU, kein Zugriff auf WebGUI), aber ein Neustart via SSH bringt die WebGUI zum Leben.
Also fhem einmal stoppen und starten, dann habe ich eine GUI
Hinter initialUsbCheck ist ein "Change Wizard", dort kann ich "set initialUsbCheck" auf "inactive setzen, die Einstellung wird nicht übernommen, wenn ich wieder auf dem selben Weg in das Menü gehe, ist "initialUsbCheck" wieder "active"...
Wichtiger sind mir aber eigentlich dir Fragen, wie ich ein Logging für die Techem HKVs hinbekomme. Das mit dem USBcheck sollte ja Ruhe geben, sobald der nanoCUL installiert ist, oder?
1. Lösche das Device initialusbcheck einfach... Du brauchst es nicht, es stört nur... (und vergiß das save nicht)
2. Solche "Trockenübungsthreads" bringen niemandem was. Warte, bis du den CUL hast, im richtigen Modus betreibst und lies ggf. in der Zwischenzeit einfach die vorhandene Doku, z.B. https://wiki.fhem.de/wiki/Quick-Start (https://wiki.fhem.de/wiki/Quick-Start).
Wenn der CUL dann da ist, lies nochmal von vorne, nimm die commandref dazu zu den Modulen, die du benötigst und versuche die erforderlichen Schritte auf deine konkrete Situation zu übertragen.
Dann siehst du, was jeweils passiert (oder eben auch nicht...).
Kurze Frage, kurze Antwort: Wird das Logging funktionieren, so wie ich es angefangen habe oder nicht?
Danke vorab! :-)
Zitat von: claudio-fhem am 17 Juli 2019, 15:43:23
Kurze Frage, kurze Antwort: Wird das Logging funktionieren, so wie ich es angefangen habe oder nicht?
Danke vorab! :-)
Wenn du die Doku gelesen hättest, müßtest du wissen, dass das darauf ankommt, welche Events generiert werden und ob dann der Eventhandler (das FileLog-Device) entsprechend eingestellt ist.
Es ist und bleibt eine unnötige Trockenübung, jedenfalls ich bin nicht in der Lage, das ohne Auszüge aus dem Eventmonitor oder wenigstes eines lists eines Devices, das auch echte Reading hat zu beantworten.
=> ich bin solange raus... (und vermutlich alle anderen auch.)
Ich habe den Abschnitt zu Events gelesen, aber kann mir darunter im Zusammenhang mit einem HKV nichts vorstellen. Bei einem Schalter oder einer Fernbedienung: Klar!
Aber wie soll das im Zusammenhang mit einem HKV funktionieren?
So ein bisschen habe ich schon die letzten Jahre mit pilight Hausautomatisierung gemacht, aber dieses Konzept "Event" für einen Fühler (Wärmeeinheiten, berechnet aus 2 Temperaturen) erschließt sich mir nicht, deshalb frage ich im Forum. War bisher kein Problem irgendwo ein inhaltliche Frage zu stellen, wenn man mit der Dokumentation nicht weiter kommt... :-)
Jetzt ist die Frage auch etwas anders, daher nochmals etwas Theorie...
Im Prinzip ist jede Info, die von irgendwoher über ein "Interface" (wie den CUL) kommt und dann bei einem Client-Gerät des Interfaces "abgeladen wird" ein "Event" - ganz egal, um was für eine Info es sich handelt. Willst du loggen, muß das Event genutzt werden, um das "schreibe ins log" auszulösen.
Welche Events jeweils abgegriffen werden, wird mit Regex festgelegt.
Also: Ohne das "live" gesehen zu haben, ist es weiter eine unnötige Fragerei. Im Prinzip wird das funktionieren, ob es im Detail klappt, ist eine Frage, ob es Events gibt (der jeweilige Modulautor kann bestimmen, wann es Events gibt...) und wie jeweils die Regex des Eventhandlers aussieht. That's all.
ZitatWillst du loggen, muß das Event genutzt werden, um das "schreibe ins log" auszulösen.
Aha, prima, danke, habe verstanden. Dann muss ich jetzt also herausfinden, wie man dieses "schreibe in's log" triggert. ;-)
Zitat von: claudio-fhem am 17 Juli 2019, 16:52:38
Aha, prima, danke, habe verstanden. Dann muss ich jetzt also herausfinden, wie man dieses "schreibe in's log" triggert. ;-)
Gar nicht. Du definierst ein passendes Log-Device.... Ganz so wie im ersten Post beschrieben - wobei mir die Namensgebung da etwas sehr "na ja" vorkommt. Etwas sprechender wie "T" dürfen Devices schon benannt werden, oder nicht? Anmerkdung dazu: Die Doku arbeitet mit Beispielen, die sind oft kurz und prägnant, aber häufig nicht für copy/paste gedacht, sondern zum Anpassen an die eigene Situation auf Basis eines bereits vorhandenen Grundverständnisses.
Btw.: Es könnte sein, dass das Device schon durch autocreate automatisch samt zugehörigem FileLog-Device erstellt worden wäre. Damit sind wir wieder beim Anfang dessen, was ich bereits geschrieben habe: Ohne dass man selbst sieht, was ggf. geschieht, fragt man Fragen, die bereits beantwortet sind und jeder, der dazu was schreibt, schreibt sich die Finger fusselig, ohne dass man einen Schritt weiter ist...
ALSO: GEDULD, bis der CUL da ist ;D . Meine Güte...
Geduld? Du hast Nerven, soviel Zeit habe ich nicht mehr :-D
Die Techem HKV sind manuell zu erstellen (ich habe mich durch die 3-4 Threads im Forum durchgelesen, ja, ganz, von Anfang bis Ende, aber halt nicht ALLES verstanden, da ich die Logik hinter fhem erst so langsma durchsteige). Daher wird wohl auch kein Log automatisch erstellt. Meine manuell erstellten sind jetz aber da im richtigen Verzeichnis und LEER.
Ich werde mich als nächstes mal damit auseinandersetzen, wie man den nanoCUL auf den WMBus schaltet. :-)
TWIMC:
So schaltet man das USB-scanning beim Rapsi ab:
attr initialUsbCheck disable 1
save (ganz wichtig! ;-) )
https://wiki.fhem.de/wiki/Raspberry_Pi (https://wiki.fhem.de/wiki/Raspberry_Pi) "Empfohlener Patch" (Das war jetzt die 4 Anleitung, wie man fhem installieren kann, die ich (durch Zufall) gefunden habe).
Benamung der Devices/Logs: Ich kann mit Abstraktion leben, solange es kurz und knackig bleibt...
Ich widerspreche Jörg mal ein klein wenig in punkto Trockenübung. Du kannst schon etwas trocken üben.
Erstelle ein Dummy Device. Vergebe readingsList und setList so als wären es echte Readingnamen. Oben hattest Du schon welche genannt. Dann kannst Du mit
set DEVICENAME COMMAND WERT
ein Reading schreiben und erhälst dafür auch ein Event.
Doch noch zwei Anmerkungen:
1. https://wiki.fhem.de/wiki/Dokumentationsstruktur => es erschließt sich mir nicht ganz, wieso du ausgerechnet die "offizielle" Anleitung nur "zufällig" findest.
2. Lösch das initial-Ding. Du kannst den scan auch manuell anstoßen. Siehe https://fhem.de/commandref_modular_DE.html#usb. Das kannst du dann machen, wenn du wirklich keine Idee hast, wie du ein bestimmtes USB-Gerät einbinden sollst... (Rudi hängt nur dran und wird nicht begeistert sein, das zu lesen... Meine persönliche Empfehlung dazu wäre sowieso, immer die "by-id"-Option zu wählen, und das kann "usb" nicht ;) ; Details findet man im Wiki, bißchen suchen schadet nicht, und die Zeit geht schneller rum ;D ).
Auch wenn Dummys "von Übel sind" (da meistens unnötig und häufig inflationär für überflüssiges Umpacken von Infos genutzt): Das von CoolTux Vorgeschlagene ist keine "echte" Trockenübung ;D . Du kannst gerne auch ein HTTPMOD-Device oder ein Wetter-Dingens erstellen und da jeweils Echtdaten loggen :P .
Gruß, Beta-User
1. https://fhem.de/fhem.html#Installation (https://fhem.de/fhem.html#Installation)
führt zu
A. "Install this package."
und https://debian.fhem.de/ (https://debian.fhem.de/)
...dies führt zu
B. "Manual Installation"
C. "The easy way" (was dann am Ende geklappt hat) :-)
2. HTTPMOD-Device?
"Wetter-Dingens"? Meinst du 433MHz? Die empfange ich derzeit mit pilight und 6-€ Receivern von eBay
Nein er meint ein Wetter Modul welches Du definieren kannst.
Kleiner Tipp zum stöbern.
Beende mal FHEM mittels systemctl
Dann gehe in das Verzeichnis /opt/fhem
Starte FHEM per Hand mittels
/usr/bin/perl fhem.pl fhem.cfg.demo
Dann rufe das FHEMWEB Gui auf und schaue Dich um.
@CoolTux: Danke für's "Übersetzen" ;D .
Zitat von: claudio-fhem am 17 Juli 2019, 18:57:40
...dies führt zu
B. "Manual Installation"
C. "The easy way" (was dann am Ende geklappt hat) :-)
Zum einen komme ich damit nicht auf 4 Anleitungen, zum anderen ist das genau die eine Anleitung, auf die auch das Wiki zum Pi verlinkt, die dann aber noch ein paar zusätzliche Hinweise zu dieser Hardwarebasis enthält...
Aber da wir da schon dabei sind und du irgendwas-PI erwähnt hast, der Grund, warum ich dich mit dieser Art Antwort nicht schlicht ignoriere...: Mein Tipp an eventuell mitlesende andere Einsteiger:
Finger weg von den PI-GPIO. Der Pi ist eine ordentliche Einsteiger-Hardware, über deren Ersatz man erfahrungsgemäß früher oder später nachdenkt. Da ist es ausgesprochen hinderlich, wenn man dann die GPIO's dieser speziellen Hardwarebasis nicht einfach weglassen kann. Halte dir den Ausgang der Entscheidung, ob du den Pi mittelfristig behalten willst, oder z.B. "normale" x64-Hardware nehmen willst, möglichst lange offen ;) .
(@PI-Nutzer: Ja, ich weiß, das kann gutgehen, und man hat ja backups bla bli blub. => braucht ihr mir nicht mehr zu erklären. Merke: Das ist meine ganz private Meinung, und wer weiß, was er tut, darf das selbstverständlich ruhig machen mit den Pi-GPIO's :P .).
Bei pilight nutze ich ein paar GPIOs, an einem Raspi zum steuern eines Displays und einiger LEDs auch. Gelegentlich ist die serielle Konsole via GPIO ganz handlich, aber für das erste Projekt FHEM ist in dieser Richtung nichts geplant.
A+B+C = drei Wege zur Installation, plus die spezifische Seite für den Raspi sind dann doch 4. ;-)
Gibt's doch noch einen kleinen Tipp, wie man in die Bearbeitung der Logs einsteigen kann (eine Thread, ein Kapitel im Büchlein, etc...), siehe 1. Post? :-)
Ich versteh das Problem mit den Logs nicht, wie gesagt, zu einem Device, das noch kein Log hat, einfach mit createlog <Devicenamen des Devices, zu dem du ein Log haben willst> ein Log anlegen lassen, das muss man dann finden (bei einem frischen FHEM sollte das einfach unter unsorted auftauchen) und das öffnen und dann kann man oben (über dem Create SVG plot) einfach auswählen, auf welche Readings das Log loggen soll, wenn denn gewünscht ist, dass nicht alle Readings geloggt werden sollen... Damit kannst du dann auch gleich ein Diagramm erzeugen....
Grüße Christian
Danke für die Antwort! Vielleicht finde ich deswegen nichts (siehe anbei), weil die Geräte ohne CUL nicht erkannt werden und daher nicht wirklich für fhem existieren?
Ich muss erstmal herausfinden, wie man den nanoCUL in den WMBUS Modus bringt, wenn er ankommt... :-)
Nein, so wie du das Log da angelegt hast, müßte der theoretisch alle Readings des "T" loggen. Wenn da aber noch keine Readings drin sind (wo wollten die auch herkommen ohne CUL), dann wird natürlich das Log auch nur leer sein können, vermute ich... Die richtige Reihenfolge wäre erst Cul in FHEM einbinden, dann, wenn der läuft, den "T" anlegen und den CUL als IODEV anlegen, falls das nicht automatisch angelegt werden sollte... Sonst wird's evtl. frickelinsch, wenn's nicht läuft...
OK, Danke! Soweit verstanden! Alles wieder löschen oder erstmal probieren, was der CUL so macht nach der Installation? :-)
Hiernach
https://wiki.fhem.de/wiki/WMBUS (https://wiki.fhem.de/wiki/WMBUS)
https://wiki.fhem.de/wiki/TechemHKV (https://wiki.fhem.de/wiki/TechemHKV)
muss ich den CUL mit
set [nanoCUL_name] rfmode=WMBus_T
auf den WMBUS T tunen, wobei der nanoCUL ja vorher sicher noch als device angelegt werden muss, oder macht er das (mit FW 1.67 drauf) automatisch beim Einstecken in den Raspi?
Wie oben schon beschrieben, wird der wahrscheinlich nicht mit autocreate angelegt und mit dem USB-Scan legt der dir den Cul nicht mit by-ID an, was bedeutet, dass wenn da mehr als ein USB-Device am Paspi hängt, FHEM den u.U. nach Neustart nicht richtig finden wird, wie die USB-Geräte je nachdem, welches der Raspi bem Booten zuerst findet, auch die erste ID zugewiesen bekommt. Wenn du mit by-ID anlegst, wird FHEM den immer wieder richtig finden und das geht leider nur beim manuellen anlegen, was auch simple ist, bei mir z.B.
define nanoCUL2 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9A1XJZZ-if00-port0@38400 3456
Grüße Christian
Zitat von: cs-online am 19 Juli 2019, 08:02:12
Wie oben schon beschrieben, wird der wahrscheinlich nicht mit autocreate angelegt und mit dem USB-Scan legt der dir den Cul nicht mit by-ID an, was bedeutet, dass wenn da mehr als ein USB-Device am Paspi hängt, FHEM den u.U. nach Neustart nicht richtig finden wird, wie die USB-Geräte je nachdem, welches der Raspi bem Booten zuerst findet, auch die erste ID zugewiesen bekommt. Wenn du mit by-ID anlegst, wird FHEM den immer wieder richtig finden und das geht leider nur beim manuellen anlegen, was auch simple ist, bei mir z.B.
define nanoCUL2 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9A1XJZZ-if00-port0@38400 3456
Grüße Christian
Erstmal ist nur der nanoCUL als USB-device geplant, ich will mich da nach und nach rantasten (eher mache ich mir einen 2. Raspi zum basteln für weitere Devices/Aufgaben...).
Aber ich habe mal in /dev nachgeschaut (der nanoCUL ist immer noch nicht da! Demnächst mache ich ein paar Tage Urlaub, spätestens danach sollte es aber soweit sein...), dort finde ich kein /serial, nur einen link von /dev/serial0 -> ttyAMA0.
Ist der Befehl in deinem Post von einem Raspi oder wird das serial angelegt, wenn Raspbian den nanoCUL erkennt? :-)
ja, wenn kein serielles Gerät am USB hängt, gibt's den Ordner auch nicht ;-) Ist ein schlaues Betriebssystem... Kannst ja vielleicht mal was mit einem Seriellwandler (vielleicht haben USB-Sticks einen ?) anhängen, dann sollte der Ordner auch angelegt werden
So, der CUL kam mit Firmware, reingesteckt in den Raspi und die by-id rausgesucht.
Internals:
CMDS
Clients :TechemHKV:WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0:9600 1134
DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0:9600
FHTID 1134
FUUID 5d409615-f33f-d504-260e-497bdd271774eb7d
NAME CUL868
NR 38
STATE disconnected
TYPE CUL
initString X21
brt
MatchList:
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
J:WMBUS ^b.*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-07-30 21:35:18 state disconnected
Attributes:
rfmode WMBus_T
So sieht er aus, aber der CUL wird immer als "disconnected" angezeigt, auch nach rausziehen/reinstecken oder reboot. Dazu habe ich nichts finden können, was mache ich falsch?
Hmmm, also mal unterstellt, die id paßt:
Vorab checken: blinkt das Teil wild vor sich hin? (=>FTDI-Test-PIN-Fehler); das "disconnected" deutet m.E. in diese Richtung.
Wenn nein, sollte eigentlich wenigstens der FTDI ein "opened" melden. Da ein nanoCUL - anders als ein auf einem ATMega32U aufgebauter - nicht als Modem agiert, kann es sein, dass die Baudrate nicht paßt => versuch mal auch andere (höhere).
Zuletzt: woher nimmst du die Sicherheit, dass das Ding wirklich schon geflasht ist? Kannst ja mal mit screen oder der Arduino-IDE versuchen, mit dem ATMega "zu reden" und diverse Baudraten auszutesten; afaik, sollte mit "v" eine Versionsangabe zurückkommen.
Hallo, Danke für die Antwort!
Blinkt nicht, der CUL.
Kann ich die Baudrate einfach in der Defintion ändern? Den Stick löschen und neu anlegen?
PS: Habe gelöscht und mit 38400 neu angelegt, selbes Ergebnis.
Wenn das Gerät disconnected ist werde ich nicht damit kommunizieren können, oder?
PS:
get myCUL raw C35
No answer
Die FW stand in der Beschreibung in der Bucht....
Hier noch dmesg eines Neustats des Raspi, sieht fehlerlos aus:
$ dmesg
[ 0.000000] Booting Linux on physical CPU 0xf00
[ 0.000000] Linux version 4.19.57-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1244 SMP Thu Jul 4 18:45:25 BST 2019
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 8 MiB at 0x3ac00000
[ 0.000000] On node 0 totalpages: 242688
[ 0.000000] Normal zone: 2133 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 242688 pages, LIFO batch:63
[ 0.000000] random: get_random_bytes called from start_kernel+0xac/0x4b4 with crng_init=0
[ 0.000000] percpu: Embedded 17 pages/cpu s39488 r8192 d21952 u69632
[ 0.000000] pcpu-alloc: s39488 r8192 d21952 u69632 alloc=17*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 240555
[ 0.000000] Kernel command line: coherent_pool=1M bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=PARTUUID=82fc19de-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 939092K/970752K available (8192K kernel code, 629K rwdata, 2176K rodata, 1024K init, 821K bss, 23468K reserved, 8192K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xbb800000 - 0xff800000 (1088 MB)
lowmem : 0x80000000 - 0xbb400000 ( 948 MB)
modules : 0x7f000000 - 0x80000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (9184 kB)
.init : 0x(ptrval) - 0x(ptrval) (1024 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 630 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 822 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 26351 entries in 78 pages
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000010] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.000025] Switching to timer-based delay loop, resolution 52ns
[ 0.000359] Console: colour dummy device 80x30
[ 0.000384] console [tty1] enabled
[ 0.000443] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[ 0.000464] pid_max: default: 32768 minimum: 301
[ 0.000900] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000923] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.002158] CPU: Testing write buffer coherency: ok
[ 0.002845] CPU0: update cpu_capacity 1024
[ 0.002860] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
[ 0.003869] Setting up static identity map for 0x100000 - 0x10003c
[ 0.004103] rcu: Hierarchical SRCU implementation.
[ 0.005293] smp: Bringing up secondary CPUs ...
[ 0.006586] CPU1: update cpu_capacity 1024
[ 0.006600] CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
[ 0.008035] CPU2: update cpu_capacity 1024
[ 0.008048] CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
[ 0.009382] CPU3: update cpu_capacity 1024
[ 0.009393] CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
[ 0.009564] smp: Brought up 1 node, 4 CPUs
[ 0.009580] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[ 0.009587] CPU: All CPU(s) started in HYP mode.
[ 0.009592] CPU: Virtualization extensions available.
[ 0.010980] devtmpfs: initialized
[ 0.026622] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
[ 0.026998] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.027026] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.027881] pinctrl core: initialized pinctrl subsystem
[ 0.029208] NET: Registered protocol family 16
[ 0.032994] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[ 0.040451] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.040464] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.040740] Serial: AMBA PL011 UART driver
[ 0.043781] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[ 0.088791] bcm2835-dma 3f007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
[ 0.091067] SCSI subsystem initialized
[ 0.091386] usbcore: registered new interface driver usbfs
[ 0.091461] usbcore: registered new interface driver hub
[ 0.091622] usbcore: registered new device driver usb
[ 0.110318] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-07-09 14:40, variant start
[ 0.120550] raspberrypi-firmware soc:firmware: Firmware hash is 6c3fe3f096a93de3b34252ad98cdccadeb534be2
[ 0.132493] clocksource: Switched to clocksource arch_sys_counter
[ 0.235120] VFS: Disk quotas dquot_6.6.0
[ 0.235230] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.235453] FS-Cache: Loaded
[ 0.235790] CacheFiles: Loaded
[ 0.250240] NET: Registered protocol family 2
[ 0.251328] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[ 0.251373] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.251501] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.251690] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.251883] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.251948] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.252436] NET: Registered protocol family 1
[ 0.253426] RPC: Registered named UNIX socket transport module.
[ 0.253437] RPC: Registered udp transport module.
[ 0.253444] RPC: Registered tcp transport module.
[ 0.253450] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.255777] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
[ 0.259817] Initialise system trusted keyrings
[ 0.260164] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[ 0.273113] FS-Cache: Netfs 'nfs' registered for caching
[ 0.273940] NFS: Registering the id_resolver key type
[ 0.273982] Key type id_resolver registered
[ 0.273990] Key type id_legacy registered
[ 0.274010] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.277273] Key type asymmetric registered
[ 0.277287] Asymmetric key parser 'x509' registered
[ 0.277380] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 0.277617] io scheduler noop registered
[ 0.277630] io scheduler deadline registered (default)
[ 0.277876] io scheduler cfq registered
[ 0.277888] io scheduler mq-deadline registered (default)
[ 0.277897] io scheduler kyber registered
[ 0.280356] bcm2708_fb soc:fb: FB found 1 display(s)
[ 0.290725] Console: switching to colour frame buffer device 82x26
[ 0.295866] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 656x416
[ 0.298581] bcm2835-rng 3f104000.rng: hwrng registered
[ 0.298949] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 0.299768] vc-sm: Videocore shared memory driver
[ 0.300214] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 0.316256] brd: module loaded
[ 0.330262] loop: module loaded
[ 0.331031] Loading iSCSI transport class v2.0-870.
[ 0.332016] libphy: Fixed MDIO Bus: probed
[ 0.332168] usbcore: registered new interface driver lan78xx
[ 0.332249] usbcore: registered new interface driver smsc95xx
[ 0.332273] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 0.360281] dwc_otg 3f980000.usb: base=(ptrval)
[ 0.560671] Core Release: 2.80a
[ 0.560686] Setting default values for core params
[ 0.560728] Finished setting default values for core params
[ 0.761105] Using Buffer DMA mode
[ 0.761114] Periodic Transfer Interrupt Enhancement - disabled
[ 0.761121] Multiprocessor Interrupt Enhancement - disabled
[ 0.761131] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 0.761156] Dedicated Tx FIFOs mode
[ 0.761834] WARN::dwc_otg_hcd_init:1045: FIQ DMA bounce buffers: virt = bad14000 dma = 0xfad14000 len=9024
[ 0.761866] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 0.761876] dwc_otg: Microframe scheduler enabled
[ 0.761951] WARN::hcd_init_fiq:457: FIQ on core 1
[ 0.761965] WARN::hcd_init_fiq:458: FIQ ASM at 80650d3c length 36
[ 0.761980] WARN::hcd_init_fiq:497: MPHI regs_base at bb810000
[ 0.762006] dwc_otg 3f980000.usb: DWC OTG Controller
[ 0.762054] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 0.762105] dwc_otg 3f980000.usb: irq 56, io mem 0x00000000
[ 0.762156] Init: Port Power? op_state=1
[ 0.762163] Init: Power Port (0)
[ 0.762592] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[ 0.762608] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.762619] usb usb1: Product: DWC OTG Controller
[ 0.762631] usb usb1: Manufacturer: Linux 4.19.57-v7+ dwc_otg_hcd
[ 0.762641] usb usb1: SerialNumber: 3f980000.usb
[ 0.763517] hub 1-0:1.0: USB hub found
[ 0.763588] hub 1-0:1.0: 1 port detected
[ 0.764399] dwc_otg: FIQ enabled
[ 0.764408] dwc_otg: NAK holdoff enabled
[ 0.764415] dwc_otg: FIQ split-transaction FSM enabled
[ 0.764430] Module dwc_common_port init
[ 0.764863] usbcore: registered new interface driver usb-storage
[ 0.765130] mousedev: PS/2 mouse device common for all mice
[ 0.766264] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 0.766556] bcm2835-cpufreq: min=600000 max=900000
[ 0.767159] sdhci: Secure Digital Host Controller Interface driver
[ 0.767166] sdhci: Copyright(c) Pierre Ossman
[ 0.767675] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[ 0.767863] sdhci-pltfm: SDHCI platform and OF driver helper
[ 0.768721] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.768873] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.769118] usbcore: registered new interface driver usbhid
[ 0.769125] usbhid: USB HID core driver
[ 0.770070] vchiq: vchiq_init_state: slot_zero = (ptrval), is_master = 0
[ 0.772030] [vc_sm_connected_init]: start
[ 0.780897] [vc_sm_connected_init]: end - returning 0
[ 0.782409] Initializing XFRM netlink socket
[ 0.782447] NET: Registered protocol family 17
[ 0.782660] Key type dns_resolver registered
[ 0.783225] Registering SWP/SWPB emulation handler
[ 0.784208] registered taskstats version 1
[ 0.784232] Loading compiled-in X.509 certificates
[ 0.793683] uart-pl011 3f201000.serial: cts_event_workaround enabled
[ 0.793806] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 0.793877] console [ttyAMA0] enabled
[ 0.796452] sdhost: log_buf @ (ptrval) (fad13000)
[ 0.842539] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[ 0.844253] of_cfs_init
[ 0.844478] of_cfs_init: OK
[ 0.845352] Waiting for root device PARTUUID=82fc19de-02...
[ 0.931483] mmc0: host does not support reading read-only switch, assuming write-enable
[ 0.934598] mmc0: new high speed SDHC card at address aaaa
[ 0.936175] mmcblk0: mmc0:aaaa SL16G 14.8 GiB
[ 0.940278] mmcblk0: p1 p2
[ 0.978070] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 0.978145] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 0.979124] devtmpfs: mounted
[ 0.982727] Indeed it is in host mode hprt0 = 00021501
[ 1.044717] Freeing unused kernel memory: 1024K
[ 1.069529] random: fast init done
[ 1.072868] Run /sbin/init as init process
[ 1.192577] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 1.192774] Indeed it is in host mode hprt0 = 00001101
[ 1.433008] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[ 1.433030] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.434041] hub 1-1:1.0: USB hub found
[ 1.434183] hub 1-1:1.0: 5 ports detected
[ 1.691124] systemd[1]: System time before build time, advancing clock.
[ 1.752575] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 1.826245] NET: Registered protocol family 10
[ 1.828125] Segment Routing with IPv6
[ 1.874468] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 1.875702] systemd[1]: Detected architecture arm.
[ 1.883044] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[ 1.883064] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.886113] smsc95xx v1.0.6
[ 1.890003] systemd[1]: Set hostname to <raspberrypi>.
[ 1.903343] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument
[ 1.990535] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:48:c2:56
[ 2.082650] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 2.135571] uart-pl011 3f201000.serial: no DMA platform data
[ 2.228759] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 2.228782] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.228794] usb 1-1.2: Product: NANO CUL
[ 2.228805] usb 1-1.2: Manufacturer: SHK
[ 2.228816] usb 1-1.2: SerialNumber: 868
[ 2.317852] systemd[1]: File /lib/systemd/system/systemd-journald.service:12 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
[ 2.317888] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
[ 2.753361] systemd[1]: /lib/systemd/system/smbd.service:9: PIDFile= references path below legacy directory /var/run/, updating /var/run/samba/smbd.pid ? /run/samba/smbd.pid; please update the unit file accordingly.
[ 2.808286] systemd[1]: /lib/systemd/system/nmbd.service:9: PIDFile= references path below legacy directory /var/run/, updating /var/run/samba/nmbd.pid ? /run/samba/nmbd.pid; please update the unit file accordingly.
[ 3.019075] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.035575] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.041455] systemd[1]: Created slice User and Session Slice.
[ 3.041971] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.043092] systemd[1]: Listening on Journal Socket (/dev/log).
[ 3.309739] i2c /dev entries driver
[ 4.002021] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 4.184490] systemd-journald[110]: Received request to flush runtime journal from PID 1
[ 5.003591] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.006581] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 5.006603] [vc_sm_connected_init]: start
[ 5.008354] [vc_sm_connected_init]: installed successfully
[ 5.018353] media: Linux media interface: v0.10
[ 5.061220] videodev: Linux video capture interface: v2.00
[ 5.169469] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.172339] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.191963] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.197209] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.199106] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 5.213056] bcm2835_audio soc:audio: card created with 8 channels
[ 5.221979] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[ 5.222000] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[ 5.236958] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 5.236984] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 5.262339] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 5.262369] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 5.631467] usbcore: registered new interface driver usbserial_generic
[ 5.631573] usbserial: USB Serial support registered for generic
[ 5.671934] usbcore: registered new interface driver ftdi_sio
[ 5.672086] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 5.683462] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 5.683792] usb 1-1.2: Detected FT232RL
[ 5.704764] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 5.847273] smsc95xx 1-1.1:1.0 enxb827eb48c256: renamed from eth0
[ 8.636892] random: crng init done
[ 8.636922] random: 7 urandom warning(s) missed due to ratelimiting
[ 8.999615] 8021q: 802.1Q VLAN Support v1.8
[ 9.049637] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 9.135634] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 9.205648] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 9.544860] smsc95xx 1-1.1:1.0 enxb827eb48c256: hardware isn't capable of remote wakeup
[ 11.075912] smsc95xx 1-1.1:1.0 enxb827eb48c256: link up, 100Mbps, full-duplex, lpa 0xC5E1
[ 16.955449] fuse init (API version 7.27)
Du solltest dir bei IO-Devices angewöhnen, die nur zu ändern.
Und ja, es muß opened bzw. connected kommen.
Nur sicherheitshalber: Der user, unter dem FHEM läuft, darf auch auf USB-Schnittstellen zugreifen (usually: user fhem ist Mitglied in dialout). Sollte eigentlich so sein, wenn du den "Easy-Way" genommen hast.
Ja, easy way wurde installiert auf dem Raspi. Wie soll ich die Berechtigung feststellen? Gibt es auf dem Raspi überhaupt einen User fhem?
"groups" ist dein Freund, und man kann auch den user anfügen. "groups fhem" sollte daher die gewünschte Auskunft liefern (Linux-Konsole).
Dasselbe sollte sich zeigen, wenn du in die Kommandzeile folgendes eingibst:
{qx(groups fhem)}
ähm, wie sieht denn deine Definition genau aus ? Einmal unten beim Device Raw Definition anklicken, bei mir sieht das so aus:
define nanoCUL2 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9A1XJZZ-if00-port0@38400 3456
und da ist bei mir nach port0 ein @, bei dir sehe ich in den Internals da ein ":"
Good catch mit dem "@"!
Jetzt habe ich Status "initialized"....
Mit
get myCUL raw C35
bekomme ich
0D / 13
und mit
get myCUL raw V
1.67. nanoCUL868
Jetzt noch ein paar dependencies für WMBus installiert...
sudo apt-get install libdigest-crc-perl
sudo cpan -i Crypt::Mode::CBC Crypt::Mode:CTRhttps://fhem.de/commandref.html#WMBUS
lief auch ohne Fehler durch, trotzdem gibt
rfmode = WMBus_T als attribute
CULnano Mode WMBus_T not supportedDa lese ich noch:
ZitatIn der culfw muss die Unterstützung des WMBUS-Protokolls aktiviert sein (#define HAS_MBUS). Bei einem CUL mit der Hardwareversion V4 ist das nicht der Fall.
https://wiki.fhem.de/wiki/WMBUS
Wie funktioniert denn das jetzt? :-D
Zitat von: claudio-fhem am 31 Juli 2019, 22:22:54
Wie funktioniert denn das jetzt? :-D
Hmm, klingt danach, als müßtest du die firmware selber bauen; der Modus scheint nicht mit einkompiliert worden zu sein. Startpunkt dafür wäre hier: http://culfw.de/culfw.html.
Kann sein, dass du auch zum Ziel kommst, wenn du das Teil mit einer aktuellen Signalduino-Firmware flashst (Achtung: k.A., ob das funktioniert, ist ungetestet und unrecherchiert!). Wäre aber einen Test wert, da es da fertige binaries gibt.
Prima, Danke! Ja, hatte sowas befürchet nach einer raschen Suche gestern...
In welcher Datei wäre denn "define HAS_MBus" zu aktivieren, vor dem "make"?
Der Verkäufer meint, er hätte ich fertig gebaute Firmware mit MBus enabled, mal sehen wie ich drankomme und das dann aufspiele.
Grundsätzliche Frage: Ich mache das FW-Aufspielen besser auf einem (Debian) Notebook, als auf dem Raspi selbst, oder? :-)
Das müßte ich auch nachsehen, würde aber auf sowas wie boards.h tippen.
Auf welcher Plattform du das erledigst, bleibt dir überlassen; ich würde auch eher den Debian-Laptop nehmen...
...ich hab das immer am Raspi gemacht, sonst alle anderen USB-Geräte abziehen, das Stresst weniger...
Die Beschreibung auf culfw.de ist so mittelgut in der Granularität. Hat da jemand etwas besseres bei der Hand?
Hardware ist ein "nano cul mit ftdi nano".
Also board.h in "Devices" -> CUL sieht so aus:
#ifndef _BOARD_H
#define _BOARD_H
// Feature definitions
#define BOARD_ID_STR "CUL868"
#define BOARD_ID_USTR L"CUL868"
#define MULTI_FREQ_DEVICE // available in multiple versions: 433MHz,868MHz
#define BOARD_ID_STR433 "CUL433"
#define BOARD_ID_USTR433 L"CUL433"
#define HAS_USB 1
#define USB_BUFSIZE 64 // Must be a supported USB endpoint size
#define USB_MAX_POWER 100
#define HAS_FHT_80b // PROGMEM: 1374b, RAM: 90b
#define HAS_RF_ROUTER // PROGMEM: 1248b RAM: 44b
#define RFR_FILTER // PROGMEM: 90b RAM: 4b
#define HAS_HOERMANN
#define HAS_HOERMANN_SEND // PROGMEM: 220
#define HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT // PROGMEM: 118b
#define HAS_CC1101_PLL_LOCK_CHECK_MSG // PROGMEM: 22b
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_SW // PROGMEM: 22b
#undef RFR_DEBUG // PROGMEM: 354b RAM: 14b
#undef HAS_FASTRF // PROGMEM: 468b RAM: 1b
#if defined(CUL_V3_ZWAVE)
# define CUL_V3
#endif
#if defined(CUL_V3) || defined(CUL_V4)
# define HAS_FHT_8v // PROGMEM: 586b RAM: 23b
# define HAS_FHT_TF
# define FHTBUF_SIZE 174 // RAM: 174b
# define RCV_BUCKETS 4 // RAM: 25b * bucket
# define FULL_CC1100_PA // PROGMEM: 108b
# define HAS_RAWSEND //
# define HAS_ASKSIN // PROGMEM: 1314
# define HAS_ASKSIN_FUP // PROGMEM: 78
# define HAS_MORITZ // PROGMEM: 1696
# define HAS_ESA // PROGMEM: 286
# define HAS_TX3 // PROGMEM: 168
# define HAS_INTERTECHNO // PROGMEM: 1352
# define HAS_TCM97001 // PROGMEM: 264
# define HAS_UNIROLL // PROGMEM: 92
# define HAS_MEMFN // PROGMEM: 168
# define HAS_SOMFY_RTS // PROGMEM: 1716
# define HAS_BELFOX // PROGMEM: 214
#endif
#if defined(CUL_V4)
# define HAS_ZWAVE // PROGMEM: 882
# define TTY_BUFSIZE 64 // RAM: TTY_BUFSIZE*4
#endif
#if defined(CUL_V3)
# define TTY_BUFSIZE 128 // RAM: TTY_BUFSIZE*4
# define HAS_MBUS // PROGMEM: 2536
# define MBUS_NO_TX // PROGMEM: 962
# define HAS_RFNATIVE // PROGMEM: 580
# define HAS_KOPP_FC // PROGMEM: 3370
#endif
#if defined(CUL_V3_ZWAVE)
# define HAS_ZWAVE // PROGMEM: 882
# undef HAS_MBUS
# undef HAS_KOPP_FC
# undef HAS_RFNATIVE
# define LACROSSE_HMS_EMU // PROGMEM: 2206
# define HAS_EVOHOME
#endif
#ifdef CUL_V2
# define TTY_BUFSIZE 48
# define FHTBUF_SIZE 74
# define RCV_BUCKETS 2
# define RFR_SHADOW // PROGMEM: 10b RAM: -(TTY_BUFSIZE+3)
# define HAS_TX3
# define NO_RF_DEBUG // squeeze out some bytes for hoermann_send
# undef HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT
#endif
#ifdef CUL_V2_HM
# define CUL_V2
# define HAS_ASKSIN
# define TTY_BUFSIZE 64
# define RCV_BUCKETS 2
# undef HAS_RF_ROUTER
# undef HAS_FHT_80b
# define FHTBUF_SIZE 0
# undef BOARD_ID_STR
# define BOARD_ID_STR "CUL_HM"
# undef BOARD_ID_USTR
# define BOARD_ID_USTR L"CUL_HM"
# define HAS_INTERTECHNO
#endif
#ifdef CUL_V2_MAX
# define CUL_V2
# define HAS_MORITZ
# define TTY_BUFSIZE 64
# define RCV_BUCKETS 2
# undef HAS_RF_ROUTER
# undef HAS_FHT_80b
# define FHTBUF_SIZE 0
# undef BOARD_ID_STR
# define BOARD_ID_STR "CUL_MX"
# undef BOARD_ID_USTR
# define BOARD_ID_USTR L"CUL_MX"
# define HAS_INTERTECHNO
#endif
// No features to define below
#include <avr/io.h>
#include <avr/power.h>
#if !defined(clock_prescale_set) && __AVR_LIBC_VERSION__ < 10701UL
# warning "avr/power.h needs patching for prescaler functions to work."
# warning "for the m32u4 add __AVR_ATmega32U4__ for cpu types on prescale block"
# warning "for the m32u2 add __AVR_ATmega32U2__ for cpu types on prescale block"
#endif
#if defined(CUL_V3) // not sure why libc is missing those ...
# define PB0 PORTB0
# define PB1 PORTB1
# define PB2 PORTB2
# define PB3 PORTB3
# define PB6 PORTB6
# define PD2 PORTD2
# define PD3 PORTD3
#endif // CUL_V3
#define SPI_PORT PORTB
#define SPI_DDR DDRB
#define SPI_SS PB0
#define SPI_MISO PB3
#define SPI_MOSI PB2
#define SPI_SCLK PB1
#if defined(CUL_V4)
# define CC1100_CS_DDR SPI_DDR
# define CC1100_CS_PORT SPI_PORT
# define CC1100_CS_PIN SPI_SS
# define CC1100_OUT_DDR DDRD
# define CC1100_OUT_PORT PORTD
# define CC1100_OUT_PIN PD3
# define CC1100_IN_DDR DDRD
# define CC1100_IN_PORT PIND
# define CC1100_IN_PIN PD2
# define CC1100_INT INT2
# define CC1100_INTVECT INT2_vect
# define CC1100_ISC ISC20
# define CC1100_EICR EICRA
# define LED_DDR DDRC
# define LED_PORT PORTC
# define LED_PIN PC5
#endif
#if defined(CUL_V3)
# define CC1100_CS_DDR SPI_DDR
# define CC1100_CS_PORT SPI_PORT
# define CC1100_CS_PIN SPI_SS
# define CC1100_OUT_DDR DDRD
# define CC1100_OUT_PORT PORTD
# define CC1100_OUT_PIN PD3
# define CC1100_OUT_IN PIND
# define CC1100_IN_DDR DDRD
# define CC1100_IN_PORT PIND
# define CC1100_IN_PIN PD2
# define CC1100_IN_IN PIND
# define CC1100_INT INT2
# define CC1100_INTVECT INT2_vect
# define CC1100_ISC ISC20
# define CC1100_EICR EICRA
# define LED_DDR DDRE
# define LED_PORT PORTE
# define LED_PIN 6
#endif
#if defined(CUL_V2)
# define CC1100_CS_DDR DDRC
# define CC1100_CS_PORT PORTC
# define CC1100_CS_PIN PC5
# define CC1100_IN_DDR DDRC
# define CC1100_IN_PORT PINC
# define CC1100_IN_PIN PC7
# define CC1100_OUT_DDR DDRC
# define CC1100_OUT_PORT PORTC
# define CC1100_OUT_PIN PC6
# define CC1100_INT INT4
# define CC1100_INTVECT INT4_vect
# define CC1100_ISC ISC40
# define CC1100_EICR EICRB
# define LED_DDR DDRC
# define LED_PORT PORTC
# define LED_PIN PC4
#endif
#if defined(CUL_V3)
# define CUL_HW_REVISION "CUL_V3"
#elif defined(CUL_V4)
# define CUL_HW_REVISION "CUL_V4"
#else
//# define CUL_HW_REVISION "CUL_V2" // No more mem for this feature
#endif
#define MARK433_PORT PORTB
#define MARK433_PIN PINB
#define MARK433_BIT 6
#define MARK915_PORT PORTB
#define MARK915_PIN PINB
#define MARK915_BIT 5
#endif // __BOARD_H__
wohin gehört jetzt das define HAS_WMBus? 8-)
Das mit der Hardware ist klar, hab's nicht nachgeschaut, aber prinzipiell sollte da auch ein Zweig nanoCUL exisiteren, also auch für den ATMega328 eine firmware gebaut werden, die man dann eben mit avrdude auf den Nano packt...
Vielleicht hilft dir die aculfw etwas weiter (die kann im Prinzip dasselbe, aber eventuell etwas mehr @433MHz, dafür sind die sourcen in github leichter zu durchforsten, Start z.B. hier: https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices (https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices)).
Zur Beruhigung: Wenn man sowas noch nie gemacht hat, ist das ein steiler Einstieg...
Ich flashe BIOSes und solche Sachen, mit Arduino und Konsorten hatte ich noch nix zu tun. Kompilieren von Source mache ich (wenn es sich nicht vermeiden lässt :-D )...
Gibt es einen Tippppp zu board.h ? :-)
In der Beschreibung auf culfw.de für Linux ist von avrdude gar nicht die Rede, nur dfu-prgrammer "make usbprogram" und geflasht ist der CUL....
http://culfw.de/culfw.html
Brauche ich den avrdude für flashen des nanoCUL am Debian Notebook?
:) Macht schon einen kleinen Unterschied, ob man eine binary nach Anleitung draufbügelt oder die erst selbst erstellt und vorab konfiguriert, aber: auch das ist kein Hexenwerk.
Besonderer Service für Wenigsucher ( :P , damit kann man auch Helfer vergraulen...):
https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/nanoCUL/board.h, dort Zeile 101.
Du mußt vermutlich was anderes definieren, der 328 hat nur begrenzt Speicher. Würde "Moritz" nehmen (ist für MAX), oder das IT-Zeug (besser dafür einen Signalduino besorgen oder jedenfalls weitere Hardware, die das kann).
Vielleicht besorgst du dir auch einen MapleCUx, der ist mit der aculfw zu flashen und hat mehr Speicher und ggf. mehr Transceiver...
Mist, ich hatte immer nach
#define HAS_WMBUS
gesucht und natürlich nichts gefunden... Ich brauche (mehr) Urlaub... :-)
Zitat von: Beta-User am 01 August 2019, 17:47:43
Du mußt vermutlich was anderes definieren, der 328 hat nur begrenzt Speicher. Würde "Moritz" nehmen (ist für MAX), oder das IT-Zeug (besser dafür einen Signalduino besorgen oder jedenfalls weitere Hardware, die das kann).
Du meinst, ich soll etwas anderes LÖSCHEN, damit die FW kleiner wird, oder? Ich wollte zunächst mal nur dieses HKV Projekt machen, später mehr von pilight wegmigrieren, wenn ich das fhem etwas durchschaue...
Sorry, deaktivieren war gemeint. Einfach auskommentieren, so wie das das Zielprotokoll gerade ist...
OK, define HAS_MBUS ist in board.h, wenn ich make usbprogram sage, will er wissen, welches usbprogram erstellt werden soll, _V2, _V2HM, _V3 oder _V4.
Was passt da zu meiner Hardware? Ich komme mir gerade sehr doof vor... Unfug, ich muss ja in nanoCUL bauen... :(
PS: Ich hatte vorher make vergessen... da beklagt er sich, dass avr_gcc fehlt, gcc ist installiert, avr_gcc ist nicht im repo (Debian Jessie 32bit).
PPS: OK, das blöde Paket heisst gcc-avr ....
______
OK, in nanoCUL ist der aktuelle Fehler:
~/Desktop/culfw-1.67/Devices/nanoCUL$ make program
Compiling C: nanoCUL.c
nanoCUL.c:6:22: fatal error: avr/boot.h: No such file or directory
#include <avr/boot.h>
^
compilation terminated.
makefile:327: recipe for target 'nanoCUL.o' failed
make: *** [nanoCUL.o] Error 1
Was fehlt hier? Irgendwer? :-)
Antwort: "avr toolchain" fehlt
https://mightyohm.com/blog/tutorials/avr-toolchain-installation/linux/
wuuuuhhh....
PPPS: Jetzt noch ein "sudo" vor dem "make program", damit make auch Zugriff auf das USB-Device hat und es scheint vollbracht. Wenn ich in fhem als att den rfmode WMBus_T wähle, kommt keine Fehlermeldung mehr. Funzt! :-)
Im Status des CUL steht als VERSION
ZitatV 1.67. nanoCUL433
aber ich will doch 868 MHz, ist da noch ein Fehler oder kann ich das ignorieren, weil weiter unten steht:
ZitatREADINGS:
...
... raw V 1.67 nanoCUL868
...
Internals:
CMDS ABbCEeFfGhiKklMmRTtUVWXxYz
Clients :TechemHKV:WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 3456
DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400
FD 11
FHTID 3456
FUUID 5d418aa6-f33f-d504-e7d9-513a1084e94fb0c3
NAME CULnano
NR 38
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL433
initString X21
brt
MatchList:
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
J:WMBUS ^b.*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-08-01 17:17:14 cmds A B b C E e F f G h i K k l M m R T t U V W X x Y z
2019-07-31 15:30:16 raw V 1.67 nanoCUL868
2019-08-01 17:17:14 state Initialized
Attributes:
rfmode WMBus_T?
Ob da 433 oder 868 steht ist nur Kosmetik.
Wichtig ist, dass das richtige Funkmodul (CC1101 in der 868MHz Ausführung) verbaut ist.
Wie man die unterscheiden kann steht im Wiki Eintrag zum nanoCUL.
WMBUS ist jetzt bei dir auf jeden Fall aktiviert, wichtig ist das kleine b in
2019-08-01 17:17:14 cmds A B b C E e F f G h i K k l M m R T t U V W X x Y z
Ist der nanoCUL eigentlich "reine" fhem-Hardware oder kann man den auch an einem pilight zum laufen bekommen? Ich habe den Kanal ziemlich voll von den schrottigen 433 MHz Empfängern am pilight...
Zitat von: claudio-fhem am 01 August 2019, 22:33:46
Ist der nanoCUL eigentlich "reine" fhem-Hardware oder kann man den auch an einem pilight zum laufen bekommen? Ich habe den Kanal ziemlich voll von den schrottigen 433 MHz Empfängern am pilight...
Die Frage ist vermutlich doppelt falsch gestellt:
Zum einen bist du hier im FHEM-Forum, da wird wohl eher niemand wissen, was sich "außerhalb" tut (warum auch, wenn man mal verstanden hat, wie FHEM tickt und wie mächtig es ist?).
Zum anderen: Versuch's mal @pilight mit einem "Superhet"-Empfänger, die sind viel besser als die aus dem billigst-Pack...
Wenn du mit FHEM und 433MHz (das insgesamt m.E. im Rahmen einer HA-Lösung tendenziell jedenfalls zum Schalten allenfalls für die Weihnachtsbeleuchtung gut ist) weitermachen willst, ist die aculfw zu empfehlen (an passender Hardware einschl. MapleCUx), oder ein nanoCUL (kann man auch selber bauen, steht im Wiki, wie), geflasht mit der Signalduino-Firmware.
Viel Freude jedenfalls beim weiteren Einlesen :) .
Ich nutze die Empfänger für div. Temp./Hum. Sensoren und die Empfangsleistung ist oft grottig. Ich werde mal schauen, ob ich das als nächstes Projekt auch mit fhem hinbekomme...
:-)
Hast du sowas im Einsatz: https://www.ebay.de/itm/433MHz-Superhet-Funkempfanger-Modul-Unterstutzung-1527-2262-Encoder/401748119105?hash=item5d8a0dce41:g:nZ4AAOSwyutcryCL (gibts in einigen Varianten, mir wäre bisher keine mit schlechter Kritik bekannt) oder diesen "xy-mk-5v" hier https://www.ebay.de/itm/433-Mhz-Sender-Empfanger-RF-Funk-Modul-FS1000A-xy-mk-5v-Arduino-Raspberry-Pi/252713874815?hash=item3ad6ebb57f:g:7R0AAOSw7D1cP4go
Letzterer ist m.E. nämlich direkt ab Werk was für den Elektroschrott >:( . Ärgerlich, dass man sowas überhaupt verkaufen darf...
Von den 2. ("Elektroschrott") habe ich ein paar Sender im Einsatz mit angelötetem Kabel als Antenne, die funtionieren gut!
Meine Empfänger habe 2x 4 Beinchen, eher ähnlich diesem hier:
https://www.makershop.de/module/funk/rxb6-433mhz-superheterodyne/
(den habe ich gerade bei einer Suche nach "superhet" gefunden...)
und ich habe auch diesen Filter drin (https://github.com/pilight/pilight_firmware), aber die Empfangsleistung ist meist schlecht, dann plötzlich hat man eine Zeit lang super Empfang (habe ein Script laufen, das loggt mit, wann die letzten Werte von welchem Empfänger ankamen), dann ist von einem Tag auf den anderen fast kein Empfang mehr, ohne dass sich irgendwas verändert hat.
OK, der RXB6 sollte eigentlich soweit ok sein (ich sprach nur vom Receiver, nicht von dem anderen...). Der "Filter" ist interessant, das scheint was ähnliches zu machen wie ein Signalduino.
Vermutlich hast du irgendwo einen heftigen Störsender, die Antennenausrichtung paßt nicht usw... (Siehe Wiki zu 433MHz). Mit CUL u. Signalduino kommt auch (via CC1101) die Info, wie stark das Signal ist (RSSI). Oder (und das ist gar nicht so unwahrscheinlich!) der Pi bockt... Die Verwendung von GPIO kann das Teil nämlich ziemlich blockieren. Ich bin u.a. deswegen kein Freund von GPIO's am Pi (wenn man überhaupt einen einsetzt, was auch schon ein Kompromis ist) und schalte lieber einen Microcontroller dazwischen (bevorzugt einen Arduino@MySensors).
...täusche ich mich, wenn der für 433Mhz kompiliert wird, wird der doch auch auf 433 voreingestellt mit den RF-Parametern und die 868er Pakete (Lacrosse, HM, etc.) werden dann gar nicht mit einkompiliert... Von daher ist das nicht nur Kosmetik, wie der geflasht wird. Wenn er unbedingt 868 empfangen möchte, würde ich auch zu der 868er Firmware raten. "Normalerweise" kann man (zumindest bei der A-FW) über das Script auswählen, ob 433 oder 868 kompiliert werden soll bzw. es werden automatisch beide Files angelegt...
Das hat wirklich keine funktionalen Auswirkungen.
Beim Umschalten auf WMBUS wird der CC1101 paasend konfiguriert, egal was da steht.
ah, wieder was gelernt ;-)
Zitat von: Beta-User am 02 August 2019, 06:13:44
OK, der RXB6 sollte eigentlich soweit ok sein (ich sprach nur vom Receiver, nicht von dem anderen...). Der "Filter" ist interessant, das scheint was ähnliches zu machen wie ein Signalduino.
Vermutlich hast du irgendwo einen heftigen Störsender, die Antennenausrichtung paßt nicht usw... (Siehe Wiki zu 433MHz).
Ick suche mir den Wolf nach einer Wiki-Seite zu 433 MHz, aber ich finde nüscht. Wer hülft mir da weiter? :-)
Fang' mit der Übersichtsseite an: https://wiki.fhem.de/wiki/Kategorie:433MHz
Ich muss sagen: Diese Superhet Empfänger sind der echte Knaller! Bei sonst identischem Aufbau (pilight, Filter, Raspi2, nur den alten Empfänger ausgelötet und neuen rein) mit dieser kleinen Spiralantenne für 433 MHz hatte ich vorher von 2 Sendern (beide extra nochmal mit frischen Batterien bestückt) in 3 Tagen 800 bzw. 25 mal Empfang.
Mit dem neuen Empfänger+Antenne sind es mehr als 3000 pro Sender in 12 Stunden. Problem gelöst!
Tausend Dank!