eBus Schaltung in Betrieb nehmen

[john30]

Den ebusd habe ich bei mir als Dienst eingerichtet. Nach der Konfiguration mit ebusd --httpport=xxxx habe ich den Dienst auch neugestartet. Allerdings war hinterher auch kein Port in netstat zu sehen.Ich hätte gehofft, dass das Befehlszeilentool also wenn ich ebusd --httpport=xxxx aufrufe, dass dies gleichzeitig in der Dienstkonfiguration eingetragen wird.

Nein, so machen das die wenigsten Dienste, wenn überhaupt einer.
Das musst schon in die Datei eintragen.

Die Daten möchte ich gerne via HTTP im JSON oder XML Format abholen, weil sich dies für die Weiterverarbeitung am einfachsten erweist.

Dann brauchst Du auch keine Dateien in den http Ordner legen, sondern lediglich die URL /data/ nutzen, wie hier beschrieben

Du schreibst das die HTML-Schnittstelle noch als experimentell anzusehen ist. Ist es denn das Ziel das diese zuverlässig funktioniert.

Ja natürlich. Sie funktioniert auch zuverlässig, aber halt bis jetzt nur lesend. Ist alles eine Frage von privater Freizeit...

Irgendwo im Netz habe ich auch gelesen, dass sich jemand mit einem Java-Tool bei Dir melden wollte, der seinen Java Code nach C portiert, damit eben eine XML Abfrage möglich wird.

Das ergbit jetzt nicht wirklich viel Sinn. aber macht nix

[Orpheus]

Hallo Reinhard

Zeig doch mal ein Log wenn und wie oft die "Signal Lost" kommen.

Hab an den Buchsen 12 angelegt (gemessen nach dem 330 Ohm Widerstand zum Einstellen.
Dann den Poti solange gedreht, bis die RxD LED das flackern anfängt (2,157 V am Pin 2 des 4011).
In dem Moment läuft auch die Protokollierung los. Bei ca. 2,18 V hört sie wieder das flackern auf. Hier kommt dann auch "signal lost". Auch bei fallender Spannung unter 2,157 V, wenn die RxD LED wieder erlischt kommt es "signal lost". Drehe ich etwas "um diese Spannung", kommt dann "signal lost", "signal acquired", wieder ein paar Werte usw.
Denn oberen Spannungswert zu ermitteln ist übrigens nicht einfach. Auch bei ganz langsamen drehen des Poti springt die Spannungsanzeige wild herum. Zwischen 1/10 bis 1/100 Volt plus oder minus. Eigentlich sollte ein drehen des Poti's im Uhrzeigersinn die Spannung verringern, dann geht sie doch wieder leicht nach oben?? Ich kann es mir nicht erklären.
Kurz noch meine Beobachtung zusammengefaßt, wenn die RxD LED erlischt, kommt auch "signal lost".

Vielen Dank und beste Grüße
Jürgen

[Reinhart]

oh, du hast das falsch interpretiert. Wenn du ein Netzteil angeschlossen hast du ja keine Verbindung zum eBus (hoffentlich)  und brauchst auch nicht zu loggen, das dient ja nur zum exakten finden des Schaltpunktes (Potistellung ) . Hänge es doch einmal an das Gerät und schaue was vom eBus nun kommt.

LG

[Orpheus]

Hallo Reinhart,

alles klar, danke Dir, versuche ich am WE mal. Melde mich wieder mit den Ergebnissen.

Beste Grüße
Jürgen

[theotherhalf]

Das "raw logging" klappt nun ganz gut, nachdem Reinhart meine Boards "geheilt" hat.
Ab und zu mal ein "Signal lost", aber ansonsten sind ständig hex Zahlen zu sehen. Das kann ich mehrere Tage laufen lassen und es gibt kein Problem.

Schalte ich aber den ebusd Service zu, passiert etwas seltsames:

2017-03-20 20:25:18.844 [main notice] ebusd 2.4.79708d2 started
2017-03-20 20:25:18.849 [bus notice] signal acquired
2017-03-20 20:25:18.852 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2017-03-20 20:25:21.003 [bus notice] max. symbols per second: 418
2017-03-20 20:25:26.009 [bus error] signal lost
2017-03-20 20:25:29.728 [bus notice] signal acquired
2017-03-20 20:25:32.036 [bus error] signal lost
2017-03-20 20:25:32.875 [bus notice] signal acquired
2017-03-20 20:25:35.020 [bus error] signal lost
2017-03-20 20:25:38.636 [bus notice] signal acquired

Das setzt sich dann so fort....Übersehe ich etwas? Wieso wird nichts geloggt?

Ferner stürzt mir dann der VRS620 ab. Kann das auch reproduzieren.
@John, hast du eine Idee woran das liegen könnte?

[Prof. Dr. Peter Henning]

Ferner stürzt mir dann der VRS620 ab

Das ist ein Hinweis auf einen Hardwarefehler auf dem Board - offenbar zieht der Transistor den Bus ins Nirwana.

LG

pah

[theotherhalf]

Das ist ein Hinweis auf einen Hardwarefehler auf dem Board - offenbar zieht der Transistor den Bus ins Nirwana.

Etwas seltsam ist, dass diese Schaltung bei Reinhart einige Zeit ohne Probleme lief nachdem er den Widerstand auf dem Board gewechselt hat.
Auch sollte das dann doch beim raw logging auch passieren, oder?

[Prof. Dr. Peter Henning]

"logging" greift nur passiv lesend auf den Bus zu. Hier sieht es aber so aus, als ob irgendetwas den Bus aktiv stört.

LG

pah

[Orpheus]

Hallo Reinhart,

.. Melde mich wieder mit den Ergebnissen.

große Katastrophe.
Nach dem Anschluss an den eBus der Heizung gestern lief alles einwandfrei, mit ebusctr -r -w find usw. Ich konnte also Werte lesen und schreiben.

Code Auswählen Erweitern


..
2017-04-02 11:21:49.270 [update notice] update bai Mode QQ=10: standby
2017-04-02 11:21:53.351 [update notice] update bai Status01 QQ=10: 32.0;32.0;12.
875;37.0;44.0;16
2017-04-02 11:21:55.303 [update notice] update broadcast outsidetemp QQ=10: 12.8
75
2017-04-02 11:21:59.430 [update notice] update bai Mode QQ=10: standby
2017-04-02 11:22:03.450 [update notice] update bai Status01 QQ=10: 32.0;32.0;12.
875;37.0;44.0;16
2017-04-02 11:22:05.450 [update notice] update bai Status02 QQ=10: auto;60;75.0;
80;60.0
2017-04-02 11:22:09.500 [update notice] update bai Mode QQ=10: standby
2017-04-02 11:22:13.530 [update notice] update bai Status01 QQ=10: 32.0;32.0;12.
875;37.0;44.0;16
2017-04-02 11:22:15.550 [update notice] update bai DateTime QQ=10: valid;11:22:1
7;02.04.2017;12.875
2017-04-02 11:22:15.763 [update notice] unknown BC cmd: 10feb505020400
2017-04-02 11:22:17.559 [update notice] update bai Mode QQ=10: standby
..

Und dann: Durch den Gang gelaufen, in das Kabel des Staubsaugers nähe der Steckdose verheddert, Stecker wird seitlich gedrückt, im Inneren der Steckdose bricht die Halterung, die Phase kommt an den Schutzleiter, FI fliegt raus. Tausch der Steckdose, FI wieder rein.
Als ich mich dann wieder dem eBus widmete, musste dieser erst neu gestartet werden. Und dann ging nicht mehr, nur noch die Fehlermeldungen:

Code Auswählen Erweitern


2017-04-02 12:24:23.485 [main notice] found messages: 14 (0 conditional on 0 con
ditions, 0 poll, 7 update)
2017-04-02 12:24:23.684 [bus notice] signal acquired
2017-04-02 12:24:29.489 [main notice] starting initial scan for fe
2017-04-02 12:24:32.084 [bus notice] new master 10, master count 2
2017-04-02 12:24:37.805 [bus error] send to 15: ERR: read timeout, retry
2017-04-02 12:24:37.850 [bus error] send to 15: ERR: read timeout, retry
2017-04-02 12:24:37.894 [bus error] send to 15: ERR: read timeout, retry
2017-04-02 12:24:37.940 [bus error] send to 15: ERR: read timeout
2017-04-02 12:24:37.940 [main error] scan config 15 message: ERR: read timeout
2017-04-02 12:25:57.527 [main notice] found messages: 14 (0 conditional on 0 con
ditions, 0 poll, 7 update)
2017-04-02 12:26:05.934 [main notice] starting initial scan for fe
2017-04-02 12:26:06.004 [bus error] send to fe: ERR: read timeout, retry
2017-04-02 12:26:06.057 [bus error] send to fe: ERR: read timeout, retry
2017-04-02 12:26:06.100 [bus error] send to fe: ERR: read timeout, retry
2017-04-02 12:26:06.144 [bus error] send to fe: ERR: read timeout
2017-04-02 12:26:06.144 [main error] initial scan failed: ERR: read timeout
2017-04-02 12:26:17.552 [bus notice] new master 10, master count 2
2017-04-02 12:26:26.214 [bus error] send to 15: ERR: read timeout, retry
2017-04-02 12:26:26.264 [bus error] send to 15: ERR: read timeout, retry
2017-04-02 12:26:26.310 [bus error] send to 15: ERR: read timeout, retry
2017-04-02 12:26:26.356 [bus error] send to 15: ERR: read timeout
2017-04-02 12:26:26.356 [main error] scan config 15 message: ERR: read timeout


Ich befürchte, dass es zu einer leichten Überspannung gekommen und irgend ein Bauteil gestorben ist.
Ich habe auch die grobe Justierung des Poti's noch mal durchgeführt, Raspi, Dienst etc. neu gestartet

Code Auswählen Erweitern


ebusctl
localhost: find
broadcast datetime = no data stored
broadcast error = no data stored
broadcast id = no data stored
broadcast netloss = no data stored
broadcast netresetcfg = no data stored
broadcast netresetstate = no data stored
broadcast signoflife = no data stored
broadcast id = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.15  = no data stored


Die Tx Diode flackert ständig. Das in die Heizung "eingehängte" CalorMatic 430 Regler, der ja auch am eBus hängt, funktioniert glücklicherweise noch.
Bei der Justierung kommen neben Hexwerten des Reglers die <aa sauber an.

Was könnte es sein?
Vielen Dank und beste Grüße

Jürgen

[Reinhart]

das ist wirklich Pech!

Viel kann das nicht sein, ich tippe auf Z-Diode oder Sendetransistor. Hast du ein Multimeter mit dem du Dioden prüfen kannst dann geht das ganz einfach. Eventuell könntest du noch den 78L05 prüfen ob er die 5 V noch liefert, der steuert nämlich den Sendetransistor über den Optokoppler an.

LG

[Prof. Dr. Peter Henning]

Wahrscheinlich müsste man zur Absicherung gegen so etwas eine Schutzschaltung am Eingang vorsehen.

LG

pah

[Orpheus]

Hallo Reinhart,
hab jetzt mal etwas gemessen, werde aber nicht ganz schlau daraus.
Am eBus habe ich 24 V (senden) angelegt. Gemessen (gegen die Masse des 78L05):
U1 Pin 1: 1,12 V
U1 Pin 2: 0 V (was mich wundert, die Diode des Optokopplers müsste doch durchsteuern?)
Z1 Sperrrichtung: 20 V
Z1 Durchlass: 12 V
U3 Pin 5: 5 V
U3 Pin 4: 0 V

Jetzt mal alles stromfrei, den USB Adapter weg, Dioden Messungen und Widerstandsmessung des Multimeters, die Diodenmessung sollte bei Messung in Sperrrichtung 0V anzeigen (eine 1N4002 zur Gegenprobe)   
                            Durchlassrichtung     Sperrrichtung
                            Ohm      Volt          Ohm   Volt            
1N4002                  1,5 M    0,600        5 M   0 V     ok
Die vier 1N4148       1,5 M    0,630      15 M   1,9 V   m.E. zu hoch, müsste 0 V sein
Z1                         5,0 M    0,700       22 M  1,9 V   zu hoch

Die unterschiedlichen Widerstandswerte in Durchlass und Sperrrichtung dürften groß genug sein, so dass nichts auf einen Defekt hindeutet.
Aber ich kann mir nicht erklären, wie die Spannung in Sperrrichtung kommt. Es können doch nicht alle Dioden kaputt sein. Über den BD645 kann der Strom auch nicht "geroutet" werden, an der Basis liegt keine Spannung an, also dürfte der auch nicht durchschalten? (lang lang ist es her ..)
Den BD645 weiß ich nicht, wie ich den messen kann, außer ausbauen und im Multimeter testen.

Hast Du noch einen Tipp?

Danke

Gruß Jürgen

PS.: So langsam weiß ich wieder, wie ein Transistor funktioniert. 

[Reinhart]

Du solltest bitte nicht am eBus Eingang 24 V direkt anlegen und den Transistor zum durchschalten bringen, nur über einen Vorwiderstand von etwa 220 Ohm 5 Watt. Sonst fließt dir ein sehr hoher C-E Strom am Transistor wenn dieser angesteuert wird. Der Strom wird dann nur durch die Zenerdiode begrenzt was die sicher nicht aushält ( der Transistor aber vermutlich schon ) . Der eBus speist ja die 24V auch über einen Vorwiderstand ein, sonst könnte kein Gerät an ihn was senden. Wenn ein Gerät sendet dann erkennt er den Spannungsabfall und so werden intern dann die Low und High erzeugt.

Senden ist ganz einfach, wenn der Eingang des Nand U2-3 Pin8+9  Low ist, dann wird Pin10 High und steuert den Optokoppler U3 an. Dort wird Pin4 High und steuert die Basis des Darlington Transistors an, der schaltet durch und die Zenerdiode läßt die Spannung am Collector um die Zenerspannung der Diode (7,5V) gegenüber dem eBus abfallen. Der Transistor macht eigentlich beim senden nichts anderes als den eBus über die Z-Diode kurz zu schließen und dieses erhöhte Stromaufkommen wird dann vom Master als H/L detektiert.

Wenn du nun 24 V mit einem Netzgerät direkt anlegst (ohne Vorwiderstand) und den T1 durchsteuerst, wird der Strom vermutlich die Z-Diode zerstören weil das Netzteil stabil bleibt und die 24V halten will, also nicht gut!
Bei guten Labornetzteilen kann man allerdings den Strom begrenzen, sodaß dieses vorzeitig auslöst.

Bei der Zenerdiode kann man aber nicht unbedingt durch ohmsches Messen einen Fehler feststellen wenn diese nur Halb-Defekt ist und den Fehler nur in Betrieb zeigt. Bei der Diodenmessung ist eigentlich nur der Spannungsabfall ( typischerweise 0.7V) von Interesse nicht der Widerstand. Einmal in Durchlass Richtung ( 0,7 V Spannungsabfall, Kennlininenknick bei etwa 0,55V )  und einmal in Sperrrichtung, dann sieht man die korrekte Funktion. Gleiches gilt für den Transistor, einmal B-E und B-C messen dann in Sperrrichtung ( also Messstrippen umpolen ) .  Da bei dir aber der Fehler in der Senderichtung ist, wird die Z-Diode defekt sein.

Zur Erinnerung, Germaniumdioden wie du sie in der HF Technik einsetzt haben einen wesentlich geringeren Spannungsabfall ( 0,2 V ) !

LG

[Prof. Dr. Peter Henning]

Nur abgesehen davon, dass man heute statt Germaniumdioden besser Schottky-Dioden verwendet: Wenn 24 V an den eBus angelegt werden, bitte mit dem Handy filmen. Kann ein echter Hit werden.

LG

pah

[Reinhart]

Hallo pah!

Ich bin mir sicher Orpheus hat die 24V an den Eingang der Platine statt des eBus angehängt und nicht an den produktiven eBus!
Ansonsten wäre wohl so einiges abgeraucht.

Ja, Schottky Dioden im HF Bereich sind in der heutigen Zeit klar weil Germanium als Rohstoff ohnehin knapp ist, aber es früher leider die Technik noch nicht so gab. Ich bin noch aus einer Zeit als es im Handel fast nur Germaniumtransistoren gab, die waren in einem schwarz lackierten Glaskörper untergebracht (OC xxx ) . Aber als Amateurfunker der alten Schule hatte er wohl eher mit Germanium Dioden zu tun und mir ging es eigentlich um die Erklärung des Spannungsabfalls an den verschiedenen Werkstoffen der Übergangsschichten.

LG