eBus Schaltung in Betrieb nehmen

Begonnen von Reinhart, 23 Dezember 2015, 15:19:45

Vorheriges Thema - Nächstes Thema

f.f

hallo,

ich bin etwas weiter. das re-open Problem konnte ich durch Modifikation der cmdline.txt offenbar erledigen.

allerdings löst das mein Problem leider nicht, ich bekomme nichts rein.
wenn ich den service stoppe und mit   "ebusd -f -d /dev/ttyUSB0 --lograwdata=bytes" starte, bekomme ich aber jetzt:
[main notice] ebusd 3.0.595c7c0 started
[main error] error reading config files: ERR: dublicate entry: last error /etc/ebusd/vaillant/15.400csv:8 ERR: dublicate entry dublicate ID

sollte mir das was sagen?

Gruss

john30

Zitat von: f.f am 27 Dezember 2017, 15:41:05
wenn ich den service stoppe und mit   "ebusd -f -d /dev/ttyUSB0 --lograwdata=bytes" starte, bekomme ich aber jetzt:

[main error] error reading config files: ERR: dublicate entry: last error /etc/ebusd/vaillant/15.400csv:8 ERR: dublicate entry dublicate ID

da fehlt noch "--scanconfig".
Steht da wirklich "dublicate" statt "duplicate"? Das wäre ein interessanter Schreibfehler meinerseits :)
author of ebusd

f.f

Hi John,

keine Ahnung....war aber wohl eher mein Fehler beim abtippen :-)

könnte das  "--scanconfig" mit meinem Problem was zu tun haben?

Ich habe noch etwas weiter probiert. Was ich nicht verstehe ist, das folgende:
wenn der Terminal bei "[bus error] signal lost" hängt, und ich eine der Busleitungen abklemme, dann springt es auf
"[bus notice] signal aquired", aber es passiert weiter nichts. Stecke ich die getrennte busleitung zurück springt es sofort wieder auf.
"[bus error] signal lost". Das ganze ist gut reproduzierbar.

Wenn ich das richtig gelesen habe ist das "signal lost" doch ein Indikator für eine USB Unterbrechung. Dann wundert mich umso mehr dass "aquired" auftaucht wenn ich die Bus Leitung kappe und das signal "abbricht" wenn ich ihn verbinde.

Hatte jemand sowas ähnliches schon mal?

Gruss

Reinhart

wir haben viel getestet und da sind auch die unmöglichsten Situationen wie deine entstanden, wenn wir den Dämon laufen liesen und den Bus ab- und wieder an geklemmt haben. Das mag der Dämon gar nicht und gerät außer Kontrolle.
Wenn du den eBus abklemmst immer auch den Dämon stoppen. Auch umgekehrt, zuerst den Bus anklemmen und dann den Dämon starten. Unter Umständen kann dir in so einer Situtation auch ein eventuell vorhandener Watchdog ganz schön in die Quere kommen.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

Prof. Dr. Peter Henning

ZitatAber leider bin ich in LINUX eine absolute NULL...
Ich denke ohne 100% sicher zu sein, dass der USB Konverter tut was er soll ...
Das steht etwas im Widerspruch zueinander, die zweite Aussage ist einfach wild geraten. So kann man sicher nicht sinnvoll helfen. Und ich schlage vor, sich beim Abtippen von Kommandos und Fehlermeldungen etwas präziser zu sein.

Zweitens: Es scheint auf der EBUS-Seite des Adapters ein Fehler vorzuliegen. Das kann durchaus auf die wilde An- und Absteckerei des EBUS zurückzuführen sein, so ewas sollte man keinesfalls tun.

Drittens: Auch die Konfiguration des ebusd scheint irgendwie wild durcheinander zu gehen - das ist keine "unberührte" Installation.

LG

pah

f.f

Hallo,

naja, ich denke mehr als "es geht nicht" geht nicht. :)....ist ja nicht so, dass ich zunächst nicht für Stunden im 10°C kalten Keller gehockt und probiert habe, bevor ich angefangen habe die BUS Leitungen zu kappen.
Leider ist meine Werkstatt eher mager ausgestattet. Selbst wenn ich einen passenden Prüfwiderstand und eine LED gefunden hätte, wäre eine sinnvolle Fehlersuche wohl am fehlenden, regelbaren Netzteil gescheitert. Bin also nicht zu Faul sondern "verzweifelt"

Nur zur sicherheit: der RX auf der 1.6 Platine muss auf RX vom USB Konverter, oder ist das gekreuzt mit TX/RX gedacht/konstruiert?
 
Gruss

Reinhart

Zitat von: f.f am 29 Dezember 2017, 10:17:40
Nur zur sicherheit: der RX auf der 1.6 Platine muss auf RX vom USB Konverter, oder ist das gekreuzt mit TX/RX gedacht/konstruiert?

Ja, Tx auf Tx und Rx auf Rx.

Aber ärgere dich nicht herum, dein Paket mit dem Bausatz C ist heute Morgen Priority raus gegangen. Die heikle Sache mit dem Poti fällt dann schon mal weg. Sicher wäre die gelötete Version für dich besser gewesen, da die John schon alle vorab testet. Aber der Nachbau sollte kein Problem sein wenn das Löten hinhaut und du ein Multimeter zur Bestimmung der Widerstände hast. Die einzigen möglichen Fehlerquellen sind die richtige Polung der Dioden, Leds und das richtige Einsetzen der ICs. Und aufpassen, ohne Leds funktioniert die Schaltung nicht!

Es haben jetzt schon einige nachgebaut, wobei die meisten Probleme im WLAN/Wemos Bereich und der Software allgemein aufgetreten sind, daher ist auch der Schritt zuerst mit Uart testen sicher der einfachere. Wenn das funktioniert, dann den 2. Schritt mit Wlan. Aus diesem Grund liegt beim Bausatz A auch ein Uart bei, obwohl der sonst überflüssig wäre, der dient nur zur einfacheren Diagnose.

Wenn was unklar ist, einfach fragen!

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

f.f

Hallo,

danke für die Hilfe. Es läuft soweit :)

Ein Verständnisproblem hab ich aber mit der Formatierung  der Ausgabe. Ich habe das ganze wie beschrieben mit etlichen ECMD devices gelöst. Bei den Werten hat das auch ganz gut geklappt, aber bei den ON OFF devices hänge ich. z.B.


get Heizkreispumpe cmd {"r -f Hc1Pump onoff\n"}
get Heizkreispumpe expect ".*\n*"
get Heizkreispumpe postproc { $_ }


liefert mir in FHEM in meinem ECMD device HKP als STATE "Heizkreispumpe on" bzw "Heizkreispumpe off" und als reading zusätzliches Heizkreispumpe mit dem korrekten Status on(off). Ich habe mir einen dummy TT definiert und via timer und

my $test=ReadingsVal("HKP","Heizkreispumpe","off");
if($test eq "on"){
fhem("set TT on");
}
else
{
fhem("set TT off");
}

der Dummy bleibt immer "off" auch wnn das Reading Heizkreispumpe auf "on" geht. Ich schätze im string $test sind noch unsichtbare Formatierungszeichen, weshalb der match nicht geht. LEider bin ich eine perl-null (wie man wohl an meinem Versuch sieht..).....wie bekomme ich das richtig formatiert (am besten gleich beim/nach get in der class definition?

Gruss

Reinhart

@f.f

Du musst ja einen Event auslösen, d.h. den state vom Device HKP überwachen! Wenn dein Device HKP heißt und im state on/off steht, dann sollte das so aussehen:

kannst auch noch hier einen Timer setzen wenn du einen brauchst, hier wird nach 2 Minuten wieder abgeschaltet
define HKP_on notify HKP.on {\
  fhem("set irgendwas on");;\{\
  fhem("define TT_Timer_off at +00:02:00 set irgendwas off")};;{\
  fhem("set irgendwas anders");;\
  }
 
define HKP_off notify HKP.off {\
  fhem("set TT off");;\
  }

der Notify überwacht dann den state "on" bzw. im 2. "off". Jedesmal wenn der sich ändert, reagiert notify und führt das aus.

oder so, du kannst auch noch die Zeit mit einem if verknüpfen, d.h. nur zwischen 7:00 und 20:00 Uhr wird das ausgeführt
define HKP_on notify HKP.on {\
if ($hour>=7 && $hour <20) {\
fhem('set irgendwas on');;\
}\
}

da kannst dich endlos austoben.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

f.f

hi,

danke. Aber mein Problem liegt wohl in der Formatierung. Das ECMD Device erhält als Reading zwar "on, off, bzw. Werte "aber die Zeicjen sind seltsamerweise in einer anderen Schriftart in fhem formatiert und enthalten irgendwie zwei mal das Unicodezeichen am Ende. Auch sind die Zeilen nach einem Auslesen erst mal in fhem erstmal breiter bis zum manuellen reload der Seite im Browser....das macht glaube ich die Problem. Wenn ich in einer if abfrage mit z.b. if ($f eq "on") abfrage, dann ergibt das false obwohl im reading $f  "on" steht...d.h. meine Abfrage zum schalten läuft ins leere, da der Zustand nicht ausgewerrtet wird.
Ich denke es liegt an den Formatierungen die in der clss Definition festgelegt ist. Expect, Postproc etc....da steig ich nicht durch

Gruss

Reinhart

@f.f

ich habe mir jetzt dein Beispiel angesehen und das mit einem DOIF gelöst weil es mir in diesem Fall einfacher erscheint und es funktioniert so tadellos.

meine bai00.class sieht so aus, ich habe den Status01 genommen weil sich da schnell was ändert und ich das auch in fast Echtzeit mit MQTT auswerten kann.
get Heizkreispumpe cmd {"r -m 10 status01 pumpstate\n"}
get Heizkreispumpe expect ".*\n*"
get Heizkreispumpe postproc {$_}

ich hole hier den "pumpstate" heraus.

hier meine Fhem Definition
define Heizkreispumpe ECMDDevice bai00.class
attr Heizkreispumpe IODev EBUS
attr Heizkreispumpe event-on-change-reading .*
attr Heizkreispumpe group Automatik
attr Heizkreispumpe icon sani_pump
attr Heizkreispumpe room Entwicklung
attr Heizkreispumpe stateFormat Heizkreispumpe
attr Heizkreispumpe verbose 3

# Dummy zum Test der Funktion
define dummyPumpe dummy
attr dummyPumpe group Automatik
attr dummyPumpe room Entwicklung
attr dummyPumpe setList on off
attr dummyPumpe verbose 3


und hier ein einfacher DOIF
define Pumpe_do_on DOIF ([Heizkreispumpe:"on"]) (set dummyPumpe on) DOELSEIF ([Heizkreispumpe:"off"]) (set dummyPumpe off)
attr Pumpe_do_on do always
attr Pumpe_do_on group Automatik
attr Pumpe_do_on room Entwicklung
attr Pumpe_do_on verbose 3


Wenn du statt der ECMD Abfrage mit MQTT auswertest hats du den Status fast in "Echtzeit" innerhalb weniger Sekunden.

LG
Reinhart
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

john30

Zitat von: Reinhart am 07 Januar 2018, 10:38:50
Wenn du statt der ECMD Abfrage mit MQTT auswertest hats du den Status fast in "Echtzeit" innerhalb weniger Sekunden.
warum mischt ihr denn ECMD und MQTT?
Man kann doch einfach das entsprechende MQTT topic mit "/set" oder "/get" am Ende verschicken (siehe hier), dann kommt kurz darauf die Antwort via MQTT zurück
author of ebusd

Reinhart

in diesem Fall braucht er keinen "get" wenn die Daten alle paar Sekunden vom Broadcast kommen, deshalb habe ich ja erwähnt das er via MQTT fast Echtzeitdaten bekommt und ohne irgendwelchen Abfragen am eBus initiieren zu müssen.

Bei ECMD ist das schon umständlicher, denn er muss mindestens einen "get" (r -m) durchführen, auch wenn er nur den Cache (Broadcast) ausliest.

Das Ganze funktioniert aber nur bei Broadcasts, sonst muss er den herkömlichen Weg gehen und aktiv aus Fhem abfragen, egal ob ECMD oder MQTT.
Den Broadcast sollte man nicht unterschätzen, denn die wichtigsten Daten kommen da schon an (Vorlauf, Rücklauf, Warmwasser, Pumpenstatus, Aussentemperatur) ohne den eBus zu quälen.

LG
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

TottiToad

#1243
Hallo,

leider habe ich ein wenig den Überblick verloren ... sind ja doch einige Seiten mittlerweile zum Ebus (Wikis, Thread etc.).

Habe jetzt gestern und heute den ganzen Tag gelesen, jedoch "leider" ein paar Grundsätzliche Fragen zum Anschluss einer fertig gelöteten Platine Bausatz A.

Bin ich da hier richtig ? Oder gibt es da einen anderen Thread den ich noch übersehen habe ?


Grüße & Danke
Totti

EDIT: Gerade den Beitrag erstellt und schon den "anderen" Thread gefunden.
Ich denke hier:
https://forum.fhem.de/index.php/topic,79600.0.html
Bin ich richtig mit meinen Fragen zum Bus V2, oder ?

rob uboot

hallo nochmals!

habe mein projekt für ein jahr ruhen lassen und wollte nun nochmal fragen
ob sich in der zwischenzeit etwas getan hat betreffend cvs für HMU, VWZ und FMU?
vielen dank! :)