eBus Schaltung V2 in Betrieb nehmen

[Reinhart]

I'm using The ebus adaptor with the new OpenHab2 ebus binding, with much more success than with esera ethernet coupler.
After some time, I remark that the boiler stopped being regulated, and just start to heat very strongly, and the VRC470 screen complained about lost ebus communication.
This is the primary Problem and you must find it! Please post a RawLogfile (--lograwdata=Bytes) for the first 2 minutes when the ebusd is started.

On the eBus adaptor, I can see the red LED continously blinking, one or two time per second, yellow led is lit and green LED seems to blink as usual, but less visible than the RED, so I'm not so sure about this.
this is ok! Red ist sending, green ist receive and yellow ist 5V power!

On the ebusd-esp web page, I can see than the connection is not active anymore.
On OpenHab side, the binding is disconnected, and logs does not show specific error message, just that communication stopped with the adaptor.
One of my guess is the ebusd could be stuck in a loop, spaming the ebus bus and preventing the VRC470 to effectively control the boiler. As soon as I disconnect the adaptor from the ebus, boiler come back to standard behavior, as well as VRC470.
please test what happens if you remove the power led?

Since the connection is lost with the openHAB binding, the origin of the spam shouldn't be the binding itself.
I just had it a third time, with very limited traffic from the openHab binding, (only 2 data was requested at a pace of one request every 600 seconds).
Then again, the red led was blinking contunously, VRC470 lost communication, and the ebusd-esp TCP session was disconnected.
But as soon as I connected directly to the ebusd-esp TCP port using RealTerm, everything went back to normal, and traffic was properlly displayed within Real Term.
Before we go into this topic in more detail, do you have the opportunity to test everything once with the Uart?
It would now be important to know if the primary functions work.

LG
Reinhart

[Reinhart]

Da es hier vereinzelt zu Unklarheiten kommt was die Kommunikations Ports zum Wemos und zu FHEM betrifft, hier ein kleine Skizze die Klarheit schaffen sollte wer wo was mit wem. Die Quintessenz, es gibt 2 Ports und die braucht man auch! Wer allerdings -p 8888 weglässt, dann wird 8888 als Default genommen, deshalb glauben einige es gibt nur ein Port!

LG

[TheChrisP]

Hi Reinhart,

thanks a lot for your help

I'm using The ebus adaptor with the new OpenHab2 ebus binding
This is the primary Problem and you must find it! Please post a RawLogfile (--lograwdata=Bytes) for the first 2 minutes when the ebusd is started.

In fact my situation is a bit different, as I'm using OpenHab and not FHEM. I am fully aware that this is a FHEM forum and discussing about other automation may be awkward, and my point is absolutly not to make value judgement between FHEM and OpenHab so I do not want to push too much this area, but technically OpenHab substitute to FHEM + ebusd, and use espd-esp directly as a low latency ser2net server.

Anyway I will try to use ebusd instead to see if I can reproduce the issue, and to generate a RawLogfile.

On the eBus adaptor, I can see the red LED continously blinking, one or two time per second, yellow led is lit and green LED seems to blink as usual, but less visible than the RED, so I'm not so sure about this.
this is ok! Red ist sending, green ist receive and yellow ist 5V power!

I do not agree here, as once the TCP connection is lost between the ebusd-esp and the client is lost (which is the ser2net connection), the ebus adaptor should not have any data to send to the ebus, excepted a limited amount of data that can remain in a send buffer.

please test what happens if you remove the power led?

I will try that at some point, but I have to unsolder it 

Before we go into this topic in more detail, do you have the opportunity to test everything once with the Uart?
It would now be important to know if the primary functions work.

I do not know yet how to implement that. (As my ebusd instance is running on a VM, I have to figure another way).

But globaly the adaptor is working as intended, the first time I had the issue, it happened after 12 hours of continuous data collection and request on the boiler and the VRC.
What I will prepare as well is a derivation in the wiring to plug my osciloscope next time I see the issue.
It can take some time, as it behave like a random issue.

[Reinhart]

you have many components that I do not know with this board. A big problem with Wlan is the latency, which must not be too big (<15msec)! Have you ever tested another power adapter for the Wemos?

LG

[lewej]

Hallo Zusammen,

ich habe eine Basisplatine da hängt der wemos mit ebus dran, oben drauf ist die Erweiterungsplatine mit espeasy drauf. Da ist ein NTC und der BMP280 angeschlossen. Der BMP hat

Code Auswählen Erweitern

Environment - BME280
GPIO-4
GPIO-5


Jetzt habe ich noch einen OLED dran welche GPIO muss ich setzen, damit dieser angeht?

Gruß
lewej

[Reinhart]

genau dieselben GPIO weil auch das Oled hängt am I2C, nur die Adresse ist eine andere (0x3c) .
Mach einfach einen I2C Scan und das Oled muss gefunden werden.

LG
Reinhart

[TheChrisP]

you have many components that I do not know with this board. A big problem with Wlan is the latency, which must not be too big (<15msec)!

I'm aware that ebus is latency sensitive, and I think this is ok on this side, but how could latency be measured ?

Have you ever tested another power adapter for the Wemos?

LG

Mmmmh, actually the power adapter is a good point and a pertinent area for investigation.

For now the Wemos is still powered by a USB3 computer port, through an USB3 hub. I guess this port is limited at 500 mA (only one port is rated to 2.1A and I'm using it to charge my mobile phone).

I've read some report stating that during Wifi operation, Wemos D1 can consume up to 800 mA, and it need to power the ebus adaptor as well, which should add some mA as well, and I'm not using the 2d Wemos yet ...

Tricky part is how to validate this assumption. Having the issue just happen less often is not good for me, I just do not want that to happen at all so that I can trust it to be plugged without any supervision.

In the opposite way, should I find a way to trigger the issue ? By using weaker power supply ?

[lewej]

Hallo Zusammen,

ich habe ein Problem mit meinen Readings, die aus mqtt gelesen werden. Der ebusd liefert alle Readings im JSON format.

Ich habe folgendes angelegt:

Code Auswählen Erweitern

define ej3 expandJSON (Sonoff.*|ebusdsolar.*|ebusdgeotherm.*:.*:.{.*.*{.*.*}})

Code Auswählen Erweitern

define ebus_auromatic_Coll1Sensor MQTT_DEVICE
attr ebus_auromatic_Coll1Sensor IODev myBroker
attr ebus_auromatic_Coll1Sensor event-on-change-reading .*
attr ebus_auromatic_Coll1Sensor icon icoTempHeizung
attr ebus_auromatic_Coll1Sensor room Heizung
attr ebus_auromatic_Coll1Sensor stateFormat {sprintf("Kollektortemp: %.1f, ReadingsVal($name,"value",0))}
attr ebus_auromatic_Coll1Sensor subscribeReading_Coll1Sensor ebusdsolar/sdr_p/Coll1Sensor
Diese werden dann aber so angelegt:

Code Auswählen Erweitern

Coll1Sensor

{ "temp": {"value": 13.62}, "sensor": {"value": "ok"}}



Ich möchte das aber so haben, wie Reinhart das gemacht hat:

[Reinhart]

wie meinst du das jetzt?
press_value und sensor_value werden ja schon als Reading angelegt, also funktioniert dein expandJson Modul.

LG

[lewej]

wie meinst du das jetzt?
press_value und sensor_value werden ja schon als Reading angelegt, also funktioniert dein expandJson Modul.

LG

Das ist ein Screen von dir, vielleicht etwas irre führend von mir. Bei mir sieht es so aus:

[Reinhart]

expandJson filtert nicht weil dieser Device nicht enthalten ist!

Code Auswählen Erweitern

define ej3 expandJSON (Sonoff.*|ebusdsolar.*|ebusdgeotherm.*:.*:.{.*.*{.*.*}})
das ist dein Filter

Code Auswählen Erweitern

define ej3 expandJSON (Sonoff.*|ebus.*:.*:.{.*.*{.*.*}})
versuche es doch einfach so, dann werde alle beginnend mit "ebus" herangezogen.

LG

[lewej]

expandJson filtert nicht weil dieser Device nicht enthalten ist!

Code Auswählen Erweitern

define ej3 expandJSON (Sonoff.*|ebusdsolar.*|ebusdgeotherm.*:.*:.{.*.*{.*.*}})
das ist dein Filter

Code Auswählen Erweitern

define ej3 expandJSON (Sonoff.*|ebus.*:.*:.{.*.*{.*.*}})
versuche es doch einfach so, dann werde alle beginnend mit "ebus" herangezogen.

LG

Leider funktioniert es nicht, es bleibt beim alten.

[Reinhart]

vergleiche einmal ein List ej3

Code Auswählen Erweitern

Internals:
   DEF        (Sonoff.*|ebus.*:.*:.{.*.*{.*.*}})
   NAME       ej3
   NOTIFYDEV  ebus.*,Sonoff.*
   NR         2486
   NTFY_ORDER 50-ej3
   STATE      2018-02-04 18:25:16
   TYPE       expandJSON
   s_regexp   (Sonoff.*|ebus.*:.*:.{.*.*{.*.*}})
   t_regexp   .*
   version    1.10
   READINGS:
     2018-02-04 10:48:25   state           active
   helper:
Attributes:
   room       System
   verbose    2

wenns wirklich nicht mehr filtert, dann starte doch einmal FHEM durch. Wenn du keinen Sonoff hast, dann lasse die erste Regexp weg.

Code Auswählen Erweitern

(.*:.*:.{.*.*{.*.*}})
wenn du es so machst, wird alles durchgelassen unabhängig vom Devicenamen, kannst ja mal testen damit und dann zukzessive wieder Filter dazu bauen.

LG

[lewej]

Hi,

Also ich hab mein Fehler gefunden, nach einem reboot wurden die readings richtig angelegt.

[Reinhart]

Hi,

Also ich hab mein Fehler gefunden, nach einem reboot wurden die readings richtig angelegt.

Super wenn's geht!

1. Support Gesetz: ein Reboot tut immer gut!

LG