eBus Schaltung in Betrieb nehmen

[Prof. Dr. Peter Henning]

Das sehe ich eher kritisch. Wenn nämlich die Heizungssteuerung regelmäßig einen nicht vorhandenen Sensor abfragt und das Register für die gemessene Raumtemperatur überschreibt, kann das die ganze Regelung stören. Aus dem Grund habe ich ja vorgeschlagen, die Raumsolltemperatur zu manipulieren. Das kann man sogar so machen, dass eine vorgegebene Vorlauftemperatur erreicht wird.

LG

pah

[BioBier]

Code Auswählen Erweitern

# ##### Reglerintern #####,,,,,,,,,,,,,,,,
r,,RoomTemp,Raumisttemp,,,,"0000",,,tempsensor,,,Raumtemperatur,,,
Aber leider nur lesend. -> 22.31;ok
Wäre interessant wo dieser Wert her kommt.

Hab es in der Installationsanleitung gefunden:
Bei aktivierter Funktion wird der Raumfühler des zugeordneten Fernbediengerätes
verwendet. Falls kein Fernbediengerät vorhanden ist, wird die Temperatur der
Bedieneinheit genutzt.

In dieser CSV https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/EBUS/vrs620.csv gibt es

Code Auswählen Erweitern

w,HC,DistantRoomTemp,Erwartet 5 Bytes 3C fest/ Roomtemp/ Roomtemp+Offset,,26,B505,2B,,,status;temp;temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Bevor ich probiere zu schreiben habe ich es zuerst mit dem lesen der RoomTemp über hex versucht aber mit

Code Auswählen Erweitern

ebusctl r -h 15 B5 09 04 0000
kein erfolg. Jemand einen Tipp?
Oder alternativ, wie ist die obere config zeile in die eBusd Config 15.ui.csv einzutragen und zu nutzen beim schreiben?

[jkriegl]

@BioBier bekomme Folgendes:
ebusctl r -f -c ui RoomTemp -> 22.81;ok
ebusctl find -f -c ui RoomTemp -> r,ui,RoomTemp,Raumisttemp.,,15,b509,0d0000,temp,s,D2C,,°C,Raumtemperatur,sensor,s,UCH,0=ok;85=circuit;170=cutoff,,Fühlerstatus
ebusctl r -h 15b509030d0000 -> 036d0100 -> (6*16+13+256)/16=22,8125

[m8haben]

Hallo,

wie bekomme ich diese Warnung weg. Bin IT-Neandertaler und kämpfe schon zwei Tage diese Warnung wegzubekommen

2016.03.05 09:28:22 1: EBUS: unexpected answer "14.38;ok\n\n" received (wrote "r -c pms Ntc2Sensor \n", expected \d+\.\d+\n)
2016.03.05 09:28:22 1: PERL WARNING: Argument "14.38;ok\n\n" isn't numeric in sprintf at (eval 94) line 1.
2016.03.05 09:28:22 3: eval: { sprintf("%5.1f",$_) }

Alle 4 Sensoren also Ntc1 bis Ntc4 gleiche Meldung

Danke und Gruß
Roland

[amunra]

Es gibt viele Möglichkeiten
expected \d+\.\d+\n in expected .*\n\n änderst oder gleich in der ebus Abfrage nur temp Wert ausgeben lässt also r -c pms Ntc2Sensor temp (müsst bitte in deiner Definition anschauen welcher Typ definiert ist)
Viele Grüße
Arthur

[Gerd.Ternes]

Bin nicht so der grosse Löter. Gibt es die Platine auch fertig zu kaufen?

[hasenhirn]

Guggst du hier 

Hallo Frank,

willkommen an Bord.

Ich stehe zwar auch noch am Anfang aber der ebusd läuft bei mir sehr stabil.
Meine Platine habe ich von "Helmut H. (der_andere)"  aus dem mikrocontroller-Forum  https://www.mikrocontroller.net/topic/346833 und die Teile von Reichelt.
Das Löten des SMD-Bausteins war für mich zu schwierig und zum Glück hatte ich einen Freund der das für mich erledigt hat 
Björn hatte auch noch fertige Platinen, war mir aber zu teuer da ich 3 Stück brauchte 
Es gibt im Netz auch noch Platinen mit anderem Layout bei denen der USB/Serial-Chip mit einer fertigen Platine ( ca. 5€ bei ebay usw. ) angebunden wird.

Ich hoffe ich konnte dir etwas weiter helfen

Gruß

Thomas

[Gerd.Ternes]

Wie kann ich Björn erreichen? Brauche ja nur 1 Platine. 

[hasenhirn]

Einfach im Mikrocontroller-Forum mal anschreiben 

Gruß

Thomas

[m8haben]

Es gibt viele Möglichkeiten
expected \d+\.\d+\n in expected .*\n\n änderst oder gleich in der ebus Abfrage nur temp Wert ausgeben lässt also r -c pms Ntc2Sensor temp (müsst bitte in deiner Definition anschauen welcher Typ definiert ist)
Viele Grüße
Arthur

Danke, habe es jetzt hinbekommen.

Gruß
Roland

[frenchie71]

Hallo zusammen, ich wollte nur kurz meine Erfahrungen beim Bestücken/Löten/Inbetriebnehmen mit Euch teilen. Vielen Dank an Reinhart, pah und Zentis666 sowie John30 für ihre Arbeit!

Bestücken/Löten : weitgehend problemlos, trotz der bei mir einsetzenden Alters-Weitsicht Lötstop sei dank. Klitzekleiner Verbesserungsvorschlag für die Platine : Vielleicht einen kleinen Tucken größer gestalten, dafür 4 Bohrlöcher spendieren ? Ich habe auf meiner CNC ein kleines Gehäuse gefräst, aber Befestigung leider nur mit Heisskleber möglich...

Inbetriebnahme : Ich hatte glücklicherweise 2 Platinen bestellt - die erste lies sich problemlos in Betrieb nehmen, die zweite hatte einen kleinen Löt-Bug. Gefunden mit OSzi an Pin 4 von U1 (Rechteck-Signal) , dann Pin 2 von U2 (kein Signal) - kalte Lötstelle... gefixt und weiter an an Pin 3 von U2 - kein Signal, also getrimmt mit R3 bis ein sauberer Rechteck erscheint. Am Terminalprogramm gegen-getestet und dort laufend AAh Werte, zeitweise unterbrochen von Telegrammen. Also alles gut.

Nachdem ich dann allerdings das Interface sicherheitshalber nur lesend in Betrieb nehmen wollte (d.h. ich wollte bevor ich ebusd  starte sicher gehen, dass nichts auf den  Bus geschrieben wird) - also einfach Tx abgezogen und - plötzlich alles tot (d.h. im Terminal keine Werte mehr) - wohlgemerkt - nicht Rx sondern Tx abgezogen, d.h. die Sendeleitung _vom_ PC _zum_ eBus.

Seltsam... Tx wieder angeschlossen und geht.... Das Verhalten ist reproduzierbar. Der Grund war auch bald ausgemacht. Ich habe zum Testen unter anderem einen hochohmigen Kristall-Ohrhörer direkt an den eBus angeschlossen. Die 2400 Baud Signale lassen sich so akustisch gut überprüfen ( "Tik-Tik-Tik-Tik-Tik-BRRRZ-Tik-Tik-Tik" - die Tiks sind die AAh Werte, das "BRRZ" die Telegramme). Beim Abziehen der Tx Leitung wurde das Signal wesentlich leiser, also kräftig gedämpft.

Der Grund hierfür ist der "neue" Pulldown-Widerstand R7, der ja beide Eingänge von U2-3 auf Masse zieht und durch das nachfolgende Gatter invertiert wird und dann den Optokoppler U3 sowie in der Folge T1 durchsteuert. Die Folge : Man legt eine laaaaange "1" auf den Bus, die alles andere übertönt. Meine Heizung (Wolf COB20) hat das am nächsten Morgen mit einer Fehlermeldung quittiert (Spannung am eBus nicht ausreichend) - zum Glück war nicht mehr passiert

Ich habe also für mich den R7 masse-seitig aufgelötet und an VDD gelegt - ist jetzt also kein Pulldown sondern ein Pullup-Widerstand, der dafür sorgt, dass T1 bei nicht-angeschlossener Tx Leitung _nicht_ durchschaltet. Seither läuft alles super.

Ach ja - ein Punkt noch - ich habe ebenfalls festgestellt, dass beim Einschalten des Raspi (ich betreibe die Schaltung mit einem USB-Seriell Wandler an einem Raspberry PI) manchmal "Müll" auf der Leitung erzeugt wird. Erste Erfahrungen zeigen, dass dieses Verhalten abhängig vom verwendeten USB-Seriell Wandler ist - falls jemand ähnliche Probleme hat, einfach mal einen anderen Wandler (vielleicht anderen Chipsatz) verwenden.

Seither (jetzt mehrere Wochen) läuft die Schaltung fehlerfrei mit FHEM. Sobald ich etwas Zeit habe, poste ich noch meine Config für Wolf COB20 hier https://forum.fhem.de/index.php/topic,29737.0.html

Setup :

eBus Platine, CP210x UART Bridge, Raspberry Pi 2, Debian Linux, ebusd, FHEM mit ECMD (Telnet-Interface)

[Reinhart]

Im Augenblick wird auf der Seite Tablet UI und Mobile GUI viel entwickelt.
Ich habe mir daher die Mobile Seite auf Basis von roman1528 seiner GUI auf unsere eBus Daten angepasst. Getestet habe ich die Mobile GUI auf Windows-Handy Samsung Ativ-S (Windows 8 ) und Google Nexus mit Android. Am Windows Handy ist die Seite etwas zu breit, dafür am Android sehr passend. Es kommt natürlich immer darauf an, welche Displaygröße ihr habt.

Zur Installation sollte zunächst die FTUI-2.0 von roman1528 installiert werden, und dann mit dem angehängten Zipfile, alles nach ..www/mobile kopieren) die eBuserweiterung zugefügt werden. Nachlesen zur Mobile GUI und deren Installation könnt ihr hier.


Wer Anpassungen machen will (in den meisten Fällen) hier kurz eine Erklärung was zu machen ist (heizung.html).

Code Auswählen Erweitern

<li class="halbTransparent border-left border-right" data-row="2" data-col="3" data-sizex="1" data-sizey="1">
   <header class="headerTransparent">Therme</header>
   <div data-type="switch"
     data-device="Therme"
     data-icon="fa-fire"
     data-get-on="Ein|on"
     data-get-off="Aus|off"
     data-set-on="Ein"
     data-set-off="Aus"
     data-on-color="black"
     data-off-color="#808080"
     data-on-background-color="cornflowerblue"
     data-off-background-color="#3D4C66"
     class="cell">
</li>
ihr braucht bei diesem Schalter nur diesen Device austauschen data-device="Therme" und euren Device einsetzen, fertig.

Wer mit 0 und 1 die Schalter betätigt, verwendet einfach diesen Code:

Code Auswählen Erweitern

     data-get-on="1|on"
     data-get-off="0|off"
     data-set-on="1"
     data-set-off="0"
seht euch dazu einfach mein Beispiel an und es wird sofort klar wie einfach das anzupassen ist.

Bitte noch nicht auf FTUI 2.1 updaten, dann läuft das Demo nicht mehr. Es ist nur auf Basis FTUI 2.0 zu 100% lauffähig. Es wird ja von Setstate gerade auf 2.1 umgestellt, daher wäre es noch zu früh die Mobile GUI auf 2.1 umzustellen. So wie es aber aussieht, wird bei der Umstellung nicht sehr viel zu machen sein.

Wie ihr eure Zugänge gestaltet ist jedem selbst überlassen. Ich bediene dies hauptsächlich von Zuhause über Wlan im eigenen Hausnetz, habe aber auch eine VPN Verbindung am Handy eingerichtet da mir diese mehr Sicherheit als eine Passwortabfrage gibt, dann gehts auch von überall mit dem Handy.

Der Post sollte eigentlich nur eine weitere Ideenanregung zur Anzeige und Visualisierung eurer eBusdaten sein, zumindest war es bei so und ich habe es gleich umgesetzt. Die Geschwindigkeit ist noch nicht gerade ideal, soll aber dann in der 2.1 sehr viel besser werden, da hier nur mehr die geänderten Daten aktualisiert werden und nicht jedes mal die ganze Seite neu geladen werden muss. Dazu könnt ihr aber in dem entsprechenden Thread nachlesen.

LG
Reinhart

[Prof. Dr. Peter Henning]

Ich rede diesbezüglich immer gegen Wände, aber versuchen wir es noch einmal: Die Darstellung "hell auf dunkel" ist ergonomisch extrem schlecht. Details werden nicht wahrgenommen, Warnhinweise übersehen - kurz, das Dingens ist wesentlich schlechter lesbar, memorierbar und verstehbar, als die gleiche Information "Dunkel auf Hell".

Anbei noch mein Tablet-Bild der Heizungsanlage - dargestellt im Floorplan.

LG

pah

[Reinhart]

Hallo Pah!

Ich glaube das sollte jeder Anwender für sich entscheiden welche Ansicht er haben möchte, die Wissenschaft ist in diesem Fall hinter dem persönlichen Geschmack eingereiht. Mir persönlich gefallen auch dunkle Hintergründe mit heller Schrift besser als umgekehrt, deshalb habe ich mich für die Variante von roman1528 entschieden.

Der dunkle Hintergrund hat vor allem bei AMOLED Displays den Vorteil weniger Strom zu verbrauchen. Es kann aber jeder das Hintergrundbild austauschen und die Farben ändern wenn wer möchte (in der ../css/fhem-tablet-ui-user_mobile.css). Mir gefällt es so besser, vor allem geht es ja nur um das Handy und dieses Hintergrundbild suggeriert einen "metallischen" Effekt.

Da ich nicht mehr die besten Augen habe und Brillenträger bin, habe ich bei weißen (oder sehr hellen) Hintergründen das Problem der Blendeinwirkung und sehe dann den Vordergrund kaum mehr scharf genug (weil die Iris abblendet und zu macht), umgekehrt ist das besser. Die Natur gibt uns ja "dunkel auf hell" schon vor, der Sternenhimmel ist gut sichtbar, was ich umgekehrt wohl kaum ausnehmen könnte.

Schaut man in den Thread der FTUI, dann tummeln sich die "dunklen" Beispiele, weil es eben den Anwendern mehr gefällt.

PS: deine Zeichnung gefällt mir trotzdem (weiß mit schwarzer Schrift) sehr gut!

LG
Reinhart

[Prof. Dr. Peter Henning]

Na, mal langsam - Du äußerst Dich auf einem meiner Arbeitsgebiete.

Erstens: Die Verringerung der Pupillenöffnung schafft ein schärferes Bild - ohne Ausnahme.
Zweitens: Wir sehen immer besser bei hoher Gesamthelligkeit - davon gibt es nur eine Ausnahme, die ich mal per Ferndiagnose vermute, nämlich eine altersbedingte Makuladegeneration.
Drittens: Dass die Natur uns "hell auf dunkel" vorgäbe, ist - sehr vorsichtig gesagt - unhaltbar. Das Sehen hat sich nicht in der Dunkelheit entwickelt, insbesondere das Sehen mit den Zapfen-Sinneszellen ist sogar an hohe Gesamthelligkeit als Voraussetzung gebunden.

LG

pah