eBus Schaltung V2 in Betrieb nehmen

Begonnen von Reinhart, 15 November 2017, 17:41:33

Vorheriges Thema - Nächstes Thema

Reinhart

so einfach ist das aber nicht die Leds einfach weg zu lassen, denn die Schaltung ist genau auf die Low Current Leds ausgelegt un dwurde von Galileo so berechnet. Es ist grade soviel Spielraum, das die Farben untereinander getauscht werden können, denn auch die haben unterschiedliche Werte.

Ich habe das bei meinen Testplatinen immer so gelöst, das ich die Led Anschlüsse mit einer Flachzange etwas quetschte und dann in die Buchsenleiste steckte wenn ich die Erweiterungsplatine nicht benötigt und abgezogen habe.

CP2102 und Erweiterungsplatine kannst den CP2102 an die Stiftleiste mit einem Flachbandkabel anschließen, dann hast Platz.

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

Prince

@john30
Vielen Dank für die ständige Weiterentwicklung der Software. Neugierig wie ich bin, habe ich den Wemos mit der neuen Firmware geflasht. Der Accesspoint wird aufgespannt und mir wird auch eine IP zugeteilt. Das WebIf ist allerdings nicht erreichbar.
Auf der seriellen Seite habe ich dann mal nachgesehen und dort bekomme ich eine Exception (28). Geflasht wurde unter Linux mit dem esptool. Unter Windows mit dem NodeMCU-Flasher zeigt sich das gleiche Bild. Der Flashspeicher wurde jeweils vorm Flashen gelöscht.
Getestet wurde der Wemos "nackt", also ohne ebus-Platine.
Kannst du dir das erklären?

john30

Zitat von: Prince am 14 Oktober 2018, 00:24:11
Auf der seriellen Seite habe ich dann mal nachgesehen und dort bekomme ich eine Exception (28). Geflasht wurde unter Linux mit dem esptool. Unter Windows mit dem NodeMCU-Flasher zeigt sich das gleiche Bild. Der Flashspeicher wurde jeweils vorm Flashen gelöscht.
Kannst du dir das erklären?
nein, sowas hab ich bis dato noch nicht gesehen. welche genaue variante vom wemos ist es denn, also ein original oder ein derivat, wieviel speicher und welche versionsnummer?
author of ebusd

Prince

Hi John,

der Wemos stammt aus der Sammelbestellung von Reinhart (die Beschriftung stammt von ihm). Er lief vorher mit der ebus-Firmware vom Dezember. Die Speichergröße beträgt 4MB. Zum schnellen Testen habe ich das Bin-File "Wifi-Repeater" erfolgreich geflasht und zum Laufen gebracht. Einen weiteren Wemos habe ich einfach mal bestellt und werde diesen testen. Das File (MD5sum 711c3047cfc4a7fa95acad39acfad517) ist das Richtige?

<Offtopic>
Im Heise-Forum wurden D1mini-Derivate diskutiert, die einen Stromverbrauch im DeepSleep von >8mA statt ~100µA haben. Es scheint dort also starke Unterschiede zu geben. Gerade bei batteriebetriebenen Projekten kann man gut auf den Bauch fallen.
</Offtopic>

Gruß

dkreutz

Bei mir gibt es auch ein Problem mit der ebusd-esp vom 23. September 2018 - WLAN Accespoint "EBUS" erscheint, es ist aber keine Verbindung möglich.
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

Reinhart

Hallo Prince!

Ich glaube nicht, das der Wemos was hat. Ich kann mich erinnern etwas ähnliches auch einmal gehabt zu haben, da war aber die Binary defekt.
Was passiert denn wenn du die alte Version die oben war wieder flasht, funktioniert die dann wieder oder zeigt die dann den selben Fehler?

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

Prince

Hallo Reinhart  :),

das Flashen der alten Version vom 30.12.2017 (md5sum 72ac51151fd8f33fc34d2500181e3cf0) verlief positiv.  Damit läuft der Wemos. Ich kann mir auch nur schwer vorstellen, dass es am Wemos liegt.
Im Haushalt läuft ein weiterer Wemos, den ich aus dem großen Auktionshaus bezog. Dieser ist mir durch die Beschriftung der Bauteile besonders aufgefallen. Den möchte ich aber gerade ungern umflashen, da er mit Tasmota 4Relais steuert.

Gruß

Sven77

Kann mir bitte nochmal jemand unter die Arme greifen?!

Es geht um "eBus Schaltung V2.1 ohne DC-DC-Wandler in Betrieb nehmen" (Basis ohne Erweiterung)...

Habe heute alles aufgebaut und zunächst ging gar nichts. Als UART möchte ich einen Wemos nutzen und lese hier, dass bei V2.1 zusätzlich die 5V vom Wemos verkabelt werden müssen. Witzigerweise steht dann nicht mehr ansatzweise, wo die hinsollen - aber es kommt ja eigentlich nur JP5 in Frage.
Vorab: ich habe das (noch) nicht gemacht, denn ich habe ja keinen DC-DC-Wandler, den ich versorgen muss.
Stattdessen habe ich SJ1 verbunden und seitdem leuchtet wenigstens die gelbe PWR-LED. Der Wemos sagt aber weiterhin "eBUS signal: no signal" und (was mich auch wundert), obwohl ich eine ebusd-Instanz zum Test schonmal verbunden habe auch "ebusd connected: no".
Ebusd selbst meckert aber nicht, empfängt aber auch nichts.

Also: wann braucht man die 5V vom Wemos, nur bei Verwendung des DC-DC-Wandlers?
Und wozu ist SJ1 auf der Basisplatine V2.1?

Vielen Dank vorab,
Sven
VG, Sven

pc1246

Moin Sven
Oben im Messplan steht etwas von den 5V! Brauchst du nicht wegen des nicht vorhandenen DC-DC Wandlers!
Und SJ1 ist dazu da, wenn ich den Schaltplan richtig lese, dass Du, bei nicht vorhandenem DC-DC Wandler, die Gleichspannung des e-Bus zur Versorgung der Platine nutzt.
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

john30

Zitat von: pc1246 am 18 Oktober 2018, 07:14:00
Oben im Messplan steht etwas von den 5V! Brauchst du nicht wegen des nicht vorhandenen DC-DC Wandlers!
Und SJ1 ist dazu da, wenn ich den Schaltplan richtig lese, dass Du, bei nicht vorhandenem DC-DC Wandler, die Gleichspannung des e-Bus zur Versorgung der Platine nutzt.
ganz genau! :)
D.h. SJ1 muss gebrückt werden, damit die eBUS Seite Stromversorgung aus dem eBUS bezieht.
author of ebusd

john30

Zitat von: Prince am 14 Oktober 2018, 21:12:18
das Flashen der alten Version vom 30.12.2017 (md5sum 72ac51151fd8f33fc34d2500181e3cf0) verlief positiv.  Damit läuft der Wemos. Ich kann mir auch nur schwer vorstellen, dass es am Wemos liegt.
ich habe leider (noch) keine Erklärung für dieses Phänomen, meine Wemos D1 mini sämtlicher Gattungen (inzwischen 4 verschiedene Varianten) lassen sich völlig schmerzfrei mit dem letzten Binary flashen und laufen dann wie gewünscht... Jemand ne Idee?
Allerdings kommt im letzten Binary auch der letzte Stand von Arduino Core zum Einsatz, vielleicht liegt es daran und man muss die Basis flashen ala https://wiki.wemos.cc/tutorials:get_started:revert_to_at_firmware
author of ebusd

Sven77

Zitat von: john30 am 18 Oktober 2018, 08:40:57
ganz genau! :)
D.h. SJ1 muss gebrückt werden, damit die eBUS Seite Stromversorgung aus dem eBUS bezieht.
Okay, dann lag ich damit ja zumindest richtig.
Dann muss ich wohl nochmal den Messplan durchgehen und alles prüfen.

Bleibt aber noch immer die Frage, warum das HTTP-GUI "ebusd connected: no" zeigt.
Im Changelog zu ebus-esp build 20171210 steht "changed default mode to TCP", ich habe als Device nur "-d <ip>:9999", also ohne Protokollprefix "[udp|tcp|enh|enhudp|enhtcp]:" übergeben was lt. Quellcode ebenfalls auf TCP defaulten sollte.
Nun bin ich nicht sicher, ob man die neueste ebus-esp-Firmware mit dem Prefix "enh:" nutzen MUSS?!

Ich ändere das nochmal explizit auf "-d tcp:<ip>:9999" bzw. dann gleich mit dem Branch "enhanced_device" auf "-d enhtcp:<ip-address>:9999" und melde mich mit dem Ergebnis...
VG, Sven

john30

Zitat von: Sven77 am 18 Oktober 2018, 09:58:05
Bleibt aber noch immer die Frage, warum das HTTP-GUI "ebusd connected: no" zeigt.
Im Changelog zu ebus-esp build 20171210 steht "changed default mode to TCP", ich habe als Device nur "-d <ip>:9999", also ohne Protokollprefix "[udp|tcp|enh|enhudp|enhtcp]:" übergeben was lt. Quellcode ebenfalls auf TCP defaulten sollte.
Nun bin ich nicht sicher, ob man die neueste ebus-esp-Firmware mit dem Prefix "enh:" nutzen MUSS?!

Ich ändere das nochmal explizit auf "-d tcp:<ip>:9999" bzw. dann gleich mit dem Branch "enhanced_device" auf "-d enhtcp:<ip-address>:9999" und melde mich mit dem Ergebnis...
die beiden Settings müssen natürlich zusammenpassen, also wenn ebusd auf enhanced oder TCP oder was auch immer eingestellt ist, muss das in ebusd-esp auch entsprechend eingestellt werden, sonst können die zwei nicht miteinander :)
author of ebusd

Sven77

Gut, gut - irgendwo war der Wurm drin...
Habe jetzt nochmal alles geprüft, ESP umgestellt auf "enhanced" (ein enhudp gibt es offenbar gar nicht, brauche ich aber vorerst auch nicht).

Nun verbindet sich ebusd mit dem ESP und ich lese nun "ebusd connected: yes" und "eBUS signal: acquired", toll.
Doch schon habe ich das nächste Problem: ebusd schreibt nun zwar viele Nachrichten, die über den Bus laufen - aber in jeder zweiten Zeile "[bus error] arbitration start error".

@John: Frage am Rande: ist das hier der richtige Ort für diese Diskussion?
Ich denke es geht eher um die neue enhanced_device Implementierung... sollen wir lieber per Mail weiter schreiben oder an anderer Stelle?
VG, Sven

john30

Zitat von: Sven77 am 18 Oktober 2018, 21:57:46
Doch schon habe ich das nächste Problem: ebusd schreibt nun zwar viele Nachrichten, die über den Bus laufen - aber in jeder zweiten Zeile "[bus error] arbitration start error".

@John: Frage am Rande: ist das hier der richtige Ort für diese Diskussion?
Ich denke es geht eher um die neue enhanced_device Implementierung... sollen wir lieber per Mail weiter schreiben oder an anderer Stelle?
hier ein neuer Thread um das zu bündeln
author of ebusd