Läuft: Heizung mit eBus-Schnittstelle

[john30]

also eigentlich ist JSON gar nicht schlecht und schon gar nicht umständlich. Ich möchte ja auch nicht mit fhem daran.
Laut edusd Doku liefert der Daemon über die http-Schnittstelle die JSON-Datei:

der HTTP Port im ebusd ist noch eher als experimentell zu bezeichnen. Bisher bin ich nur dazu gekommen, damit meine WP und zwei Heizkreise zu visualisieren, die dynamische Färbung der verbundenen Rohre ist im jetzigen Stand irgendwann wieder verloren gegangen. Ich komme leider nicht dazu, das Interface zu vervollständigen.

[istler]

Hallo John,

danke für die Rückmeldung. Eigentlich war ich nur an den JSON-Output interessiert. ABER der Visualisierung finde ich auch sehr spannend! 
Was mir auf gefallen ist beim ebusd 2.0:
Einige Variablen sind jetzt vollständig mit Namen versehen, z.B.:

Code Auswählen Erweitern

"broadcast": {

    "datetime":

{

    "lastup": ​1456588814,
    "zz": "fe",
    "fields":

{

    "outsidetemp":

{

    "value": ​4.938

},
"time":
{

    "value": "17:00:00"

},
"date":

            {
                "value": "27.02.2016"
            }
        },
        "passive": true,
        "write": false
    }

},
Da sind in der JSON-Struktur nun keine Zahlen mehr in den Fields-Bezeichnern vorhanden sondern die Namen, deshalb läuft dein HTML bzw. JS-Script ins leere. In der Zeile wo du nun die Werte abholst um sie zu aktualisieren und die "parts" überprüfst (ab Zeile 253 in der index.html):

Code Auswählen Erweitern

var buildText = function(parts, fields) {
var ret = '';
if (parts) {
parts = parts.split(' ');
for (var i=0; i<parts.length; i++) {
if (ret.length>0) ret += ',&nbsp;';
if (isNaN(parts[i])) {
if (parts[i]=='\\n')
ret += "<br>";
else
ret += parts[i];
} else if (fields && fields.hasOwnProperty(parts[i])){
var field = fields[parts[i]];
ret += field.hasOwnProperty('value')&&field.value!=null?field.value:'?';
if (field.unit) {
ret += '&nbsp;'+field.unit;
}
} else {
ret += '?';
}
}
} else if (fields) {
for (var i=0; i<fields.length; i++) {
if (ret.length>0) ret += ',&nbsp;';
var field = fields[i];
ret += field.hasOwnProperty('value')&&field.value!=null?field.value:'?';
if (field && field.unit) {
ret += '&nbsp;'+field.unit;
}
}
} else {
ret += '?';
}
return ret;
Nun wird statt der Zahlen die eigentlichen Feld-Namen angezeigt....
Evtl. klappt ja deswegen einigen Sachen nicht mehr z. B. DCF-Empfänger / Außenfühler.

Gruß
Maik

[Prof. Dr. Peter Henning]

Hallo John,

ich kämpfe mit einem komplett neuen Ansatz zum Holen der Werte aus ebusd. Habe aber ein Problem bei telnet-Verbindungen, die FHEM aufmacht.

Eine manuelle telnet-Verbindung und Absetzen des Kommandos "read FlowTemp" geht problemlos.
Ebenso das Auslesen mit ebusct und dem Kommando "read FlowTemp". Also wird der Bus prinzipiell ordentlich gelesen und geschrieben.

Wenn ich aber aus dem perl-Programm mit telnet auf den betreffenden Port gehe, bekomme ich regelmäßig ein

2016-02-28 17:16:26.269 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-02-28 17:16:28.296 [bus debug] ERR: read timeout during receive command ACK, switching to skip

Hast Du irgendeinen Vorschlag, den ich noch ausprobieren kann ?

LG

pah

[john30]

Wenn ich aber aus dem perl-Programm mit telnet auf den betreffenden Port gehe, bekomme ich regelmäßig ein
Hast Du irgendeinen Vorschlag, den ich noch ausprobieren kann ?

Hm, das klingt so, als würdest Du den Empfänger überlasten. Es sei denn er versteht die Anfrage grundsätzlich nicht.
Bist Du sicher, dass das manuell initiierte Kommando genau dem über Perl initiierten entspricht?

[Prof. Dr. Peter Henning]

Es sieht tatsächlich so aus, als ob über die perl-telnet-Verbindung irgendetwas gefressen wird.

Ich habe es jetzt noch einmal mit der Angabe des Circuit versucht. Zuerst manuell:

ebusctl read -c bai00 FlowTemp
50.38;ok

gibt das richtige Resultat. Über ECMD/ECMDDevice hingegen:

2016.02.29 13:11:59 5: ECMDDevice: Analyze command >{"read -c bai00 FlowTemp\n\000read -c bai00 FillPressure"}<
2016.02.29 13:11:59 5: EBUS: command split into 2 parts.
2016.02.29 13:11:59 5: EBUS: sending command "read -c bai00 FlowTemp\n"
2016.02.29 13:11:59 5: SW: 72656164202d6320626169303020466c6f7754656d700a
2016.02.29 13:11:59 1: EBUS: unexpected answer "usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]]\n  or:  read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx\n Read value(s) or hex message.\n  -f          force reading from the bus (same as '-m 0')\n  -m SECONDS  only return cached value if age is less than SECONDS [300]\n  -c CIRCUIT  limit to messages of CIRCUIT\n  -d ZZ       override destination address ZZ\n  -p PRIO     set the message poll priority (1-9)\n  -v          be verbose (include circuit, name, field names, units, and comments)\n  -n          use numeric value of value=name pairs\n  -i VALUE    read additional message parameters from VALUE\n  NAME        the NAME of the message to send\n  FIELD       only retrieve the field named FIELD\n  N           only retrieve the N'th field named FIELD (0-based)\n  -h          send hex read message (or answer from cache):\n    ZZ        destination address\n    PB SB     primary/secondary command byte\n    NN        number of following data bytes\n    Dx        the data byte(s) to send\n\n" received (wrote "read -c bai00 FlowTemp\n", expected .*\n*)
2016.02.29 13:11:59 5: EBUS: received answer "usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]]\n  or:  read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx\n Read value(s) or hex message.\n  -f          force reading from the bus (same as '-m 0')\n  -m SECONDS  only return cached value if age is less than SECONDS [300]\n  -c CIRCUIT  limit to messages of CIRCUIT\n  -d ZZ       override destination address ZZ\n  -p PRIO     set the message poll priority (1-9)\n  -v          be verbose (include circuit, name, field names, units, and comments)\n  -n          use numeric value of value=name pairs\n  -i VALUE    read additional message parameters from VALUE\n  NAME        the NAME of the message to send\n  FIELD       only retrieve the field named FIELD\n  N           only retrieve the N'th field named FIELD (0-based)\n  -h          send hex read message (or answer from cache):\n    ZZ        destination address\n    PB SB     primary/secondary command byte\n    NN        number of following data bytes\n    Dx        the data byte(s) to send\n\n"
2016.02.29 13:11:59 5: EBUS: sending command "read -c bai00 FillPressure"
2016.02.29 13:11:59 5: SW: 72656164202d632062616930302046696c6c5072657373757265
2016.02.29 13:12:04 2: EBUS: first attempt to read timed out, trying to close and open the device.
2016.02.29 13:12:04 3: Opening EBUS device 192.168.0.195:8888
2016.02.29 13:12:04 3: EBUS device opened
2016.02.29 13:12:04 5: SW: 72656164202d632062616930302046696c6c5072657373757265
2016.02.29 13:12:09 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2016.02.29 13:12:09 1: EBUS: no answer received (wrote "read -c bai00 FillPressure", expected .*\n*)
2016.02.29 13:12:09 5: EBUS: received answer ""
2016.02.29 13:12:09 5: Postprocessing "usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]]\n  or:  read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx\n Read value(s) or hex message.\n  -f          force reading from the bus (same as '-m 0')\n  -m SECONDS  only return cached value if age is less than SECONDS [300]\n  -c CIRCUIT  limit to messages of CIRCUIT\n  -d ZZ       override destination address ZZ\n  -p PRIO     set the message poll priority (1-9)\n  -v          be verbose (include circuit, name, field names, units, and comments)\n  -n          use numeric value of value=name pairs\n  -i VALUE    read additional message parameters from VALUE\n  NAME        the NAME of the message to send\n  FIELD       only retrieve the field named FIELD\n  N           only retrieve the N'th field named FIELD (0-based)\n  -h          send hex read message (or answer from cache):\n    ZZ        destination address\n    PB SB     primary/secondary command byte\n    NN        number of following data bytes\n    Dx        the data byte(s) to send\n\n" with perl command { Vaillant_HC_stateboiler_postproc("HK.Hz",$_) }.
2016.02.29 13:12:09 1: PERL WARNING: Argument "usage:" isn't numeric in sprintf at /opt/fhem/FHEM/99_myUtils.pm line 107.
2016.02.29 13:12:09 1: PERL WARNING: Argument "[-m" isn't numeric in sprintf at /opt/fhem/FHEM/99_myUtils.pm line 108.
2016.02.29 13:12:09 5: Postprocessed value is "VL.T  0.00 °C, p  0.00 bar".

LG

pah

[jkriegl]

Es werden 2 reads aufgerufen. Beim 2. fehlt scheinbar ein \n am Ende.
Bei mir funktioniert:
get T.PrECount cmd {"read -f -c bai PrEnergyCountHc1\n\000read -f -c bai PrEnergyCountHwc1\n"}

[Prof. Dr. Peter Henning]

Es werden 2 reads aufgerufen. Beim 2. fehlt scheinbar ein \n am Ende.
Bei mir funktioniert:
get T.PrECount cmd {"read -f -c bai PrEnergyCountHc1\n\000read -f -c bai PrEnergyCountHwc1\n"}

Ich nehme das mal witzig - schon mal nachgesehen, wer diesem Thread initiiert und die Ankopplung mit ECMD realisiert hat ?

Im Übrigen ist die Antwort auch  nicht richtig.

LG

pah

[Reinhart]

@pah

ich habe gerade versucht so eine durch Seperator getrennte Abfrage durchzuführen und das funktioniert bei mir soweit ohne Fehlermeldung.
Allerdings kann ich mit deinen exakten Parametern nicht testen.

Verwendest du eine modifizierte bai00.csv in deinen Configs? Den in der 08.bai.x von John gibt es ja keinen "FillPressure", John hat den nun "Waterpressure" getauft und mit dem habe ich es getestet.

Code Auswählen Erweitern

EBUS: no answer received (wrote "read -c bai00 FillPressure", expected .*\n*)
für mich sieht das in deiner Abfrage so aus als wäre der "FillPressure" tatsächlich nicht vorhanden, kann mich aber auch täuschen, denn wenn ich Fillpressure einsetze dann bekomme ich etwas andere Fehlermeldungen.

LG

[Prof. Dr. Peter Henning]

Natürlich benutze ich einen anderen Satz von CSV-Dateien - von Hand  getunt bezüglich der Bezeichnungen. Daran liegt es aber nicht, wie man an der korrekten Abfrage (auch von FillPressure, und auch von kombinierten Kommandos) im direkten telnet sieht.

Auch nicht daran, dass dies ein zweiter Raspberry ist, der mit einem zweiten EBUS-Interface mit unterschiedlicher Adresse auf denselben eBus wie mein Hauptinterface lauscht.

Sondern der Fehler steckt irgendwo im Zusammenspiel von einer zweiten FHEM -Installation mit neuem Perl mit dem neuen Jessie-Betriebssystem als Client und dem Raspberry Pi mit neuem Jessie-Betriebssystem und EBUS-Interface als Server.

LG

pah

Edit: Habe es gelöst. War ein Problem der Timeouts auf einem wesentlich schnelleren Rechner. Danke für die Anteilnahme

[hasenhirn]

Hallo und guten Abend,

ich habe mich durch FHEM so weit durchgekämpft dass das Ganze läuft und schon mal so ungefähr aussieht wie ich es gerne hätte 
Einen Screenshot meiner FHEM-Oberfläche habe ich mal angehängt.
Auf der linken Seite soll die Beschreibung ( das habe ich hin bekommen ) und auf der rechten Seite möchte ich nur die Temperatur / den Wert stehen haben und das bekomme ich nicht hin. Die Variable wird immer mit angezeigt 
Dass nur noch eine Kommastelle und "°C" nach der Temperatur angezeigt wird habe ich schon hinbekommen 
Ich habe schon viel gegooglet und gelesen komme aber nicht dahinter wie ich das hin bekomme oder ob es eventuell überhaupt nicht geht.
Für einen Tipp oder die Info dass es nicht geht wäre ich dankbar.

LG

Thomas

Code Auswählen Erweitern

#!/usr/bin/perl
# Aussentemperatur
get AT cmd {"r -f outsidetemp temp\n"}
get AT expect ".*\n*"
get AT postproc {sprintf("%.1f °C",$_) }
#
# vorlauftemperatur
get VT cmd {"r -f HcFlowTemp temp\n"}
get VT expect "\d+\.\d+\n\n"
get VT postproc { sprintf("%.1f °C",$_) }
#
# Ruecklauftemperatur
get RT cmd {"r -f HcReturnTemp temp\n"}
get RT expect "\d+\.\d+\n\n"
get RT postproc { sprintf("%.1f °C",$_) }
#
# Speichertemperatur_oben
get SO cmd {"r -f StorageTempTop\n"}
get SO expect "\d+\n\n"
get SO postproc { sprintf("%.1f °C",$_) }
#

[cs-online]

Hi Thomas,

ich hab auch immer mit den expects und postprocs gekämpft, aber ich habe das (sicher nicht ganz stilgerecht, aber funktionierend) mit substr(_$,Anfang,Anzahl Zeichen) hinbekommen...

Aber bestimmt hat hier jemand eine Idee, wie das stilgerecht geht,

Grüße

Christian

[Prof. Dr. Peter Henning]

Es ist viel zu kompliziert, das in der *.cfg Datei zu warten.

Der Trick besteht also darin, im postproc nur eine Perl-Routine zu rufen, die den Ergebnisstring mit split komplett zerlegt und dann auf einzelne readings verteilt.

Ein älteres Beispiel von mir dazu findet sich in contrib/EBUS, bzw. hier: https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/EBUS/Vaillant_routines.pl.

In meiner aktuell laufenden Installation habe ich das deutlich weiter entwickelt, es dauert aber noch etwas, bis ich das allgemein zur Verfügung stelle.

LG

pah

[amunra]

Auf der linken Seite soll die Beschreibung ( das habe ich hin bekommen ) und auf der rechten Seite möchte ich nur die Temperatur / den Wert stehen haben und das bekomme ich nicht hin. Die Variable wird immer mit angezeigt 

Du kannst mit stateFormat arbeiten.
Beispiel für Aussentemperatur (einfach in FHEMWEB-command eingeben):

Code Auswählen Erweitern

attr AT stateFormat {sprintf("%.1f °C", ReadingsVal($name,"AT",0))}
Viele Grüße
Arthur

[hasenhirn]

Danke für eure Antworten 
Wenn ich heute Abend nach Hause komme werde ich es mal ausprobieren.

Gruß

Thomas

[Reinhart]

da du ja schon die Zahl formatiert hast, einfach stateformat auf das Reading "Aussentemp", dann wird dieses Reading in "state" gesetzt.
Amunra hat es dir mit Formatierung gepostet, dann kannst die Formatierung in der bai00.cfg weglassen, es gibt immer viele Wege die zum Ziel führen.

Code Auswählen Erweitern

#AussenTemp.
define Aussentemp ECMDDevice bai00.class
attr Aussentemp IODev EBUS
attr Aussentemp group Vaillant
attr Aussentemp icon temp_outside
attr Aussentemp room Vaillant
attr Aussentemp stateFormat Aussentemp
hier ein Beispiel mit der Aussentemperatur

LG