Entwicklung einer 1wire-zu-WLAN-Bridge

Begonnen von hexenmeister, 18 Dezember 2015, 01:03:45

Vorheriges Thema - Nächstes Thema

PeMue

#180
Zitat von: hexenmeister am 25 Juni 2016, 14:42:54
Ich warte aber noch etwas, evtl. mag jemand noch drüber zu schauen ;)
Dann versuche ich mal mein Glück  ;D

Was ich meine, verstanden zu haben:
- Spannungsversorgung in drei Stufen (entweder IC1 oder IC2 oder direkt 5 V)
- 1-wire entweder per Busmaster oder direkt am ESP Pin (mit allen möglichen Schikanen: Abschluss, Filter, "strong pullup")
- Spannungsversorgung 1-wire entweder mit 5 V oder 3,3 V (der Regler dafür sitzt vermutlich auf dem WeMosD1mini)
- DS18B20 ist mit auf der Platine
- OPT ist vermutlich ein Taster, der von der Firmware eingelesen werden kann

Meine Fragen:
- Wofür ist der zweite VCC bei 1W-OUT, ich dachte eher (nach der Erklärung von André, hier müsste ein zweiter 1-W Anschluß da sein)? Und wenn, müssten dann noch mehr Anschlüsse für 1-wire da sein ...
- Besteht die Möglichkeit, neben VIN1 auf der Unterseite noch eine microUSB Typ B zu platzieren (Codename: die schlecht lötbare)?
- Das Bauteil ZD1 verstehe ich nicht (warum die "solder jumper" unter dem Bauteil?); vermutlich schon im Bauteil definiert, zum überbrücken, falls keine ZD1 bestückt ist ...
- Ich vermute mal, die notwendigen pullups/pulldowns für den ESP bzw. der Programmiertaster ist schon auf dem WeMosD1mini mit drauf.

Schönheitskorrekturen:
- Die Ground Symbole im Schaltplan würde ich generell nach unten zeichnen  ;)

Noch offen:
Den "Roman" auf der Platinenrückseite würde ich gerne noch korrekturlesen  ;D -> erl.
Die Platinenbeschriftung hätte ich auf das Layer bNames gemacht, der Effekt bleibt derselbe  ;D

Firmware:
- Kann die Platine mit Busmaster (Firmware: ESP transparent bridge) über die normalen fhem Module betrieben werden?
- Wie ist das, wenn der 1-wire Bus direkt am ESP dranhängt; ich vermute, da gibt es noch nichts, oder?

Ansonsten: Sehr übersichtliches Layout, habe auch beim Rendern bei OSHPark nichts kritisches gefunden. DRC habe ich allerdings nicht durchgeführt ...

Und: wenn machbar, würde ich eine Platine als für Software Entwicklung ordern (habe aber gerade noch vier andere Platinen da, die ich testen muss, also hat das keine Eile).

Gruß Peter

Edit1:
... und hier noch der geänderte "Roman" (Satzzeichen bzw. dt. Umlaute einheitlich, Spannung statt Strom  ;), aber eigentlich nichts Dramatisches):
Spannungsversorgung:
=>5V: SJ1 geschlossen, IC1, IC2 (C3, C4)
unbestueckt
=>7-12V:  SJ1 offen,
IC2 bestueckt (AMS1117 5.0),
C3, C4 bestueckt, IC1 unbestueckt
=>13-24V: SJ1 offen, IC2 unbestueckt,
IC1 bestueckt (7805), C3, C4 bestueckt

Bus Konfiguration:
generell:
- SJ3 regelt die Spannngsversorgung
des Busses (gilt nicht für parasitaer
versorgte Devices).
- ZD1 (ESD protection) kann
ueberbrueckt werden.
- R17 und C1 bilden einen
optionalen Filter.

=>ohne Busmaster:
- Pullup R1 bestueckt
(i.d.R. zwischen 1k und 2k2).
- i2c-LevelShifter
(R13, R14, Q2, Q3, R15, R16)
ist optional (wird ggf. benoetigt, wenn
5V-I2C-Bus anderweitig verwendet wird).
- BusMaster-Chip (IC3)
StrongPullup-Schaltung (Q1, R18) unbestueckt
==> 3.3V-Bus: SJ2 geschlossen,
1w-LevelShifter (R21, R22, Q4) unbestueckt
==> 5V-Bus: SJ2 offen, 1w-LevelShifter bestueckt

=>mit Busmaster:
SJ2 offen, 1w-LevelShifter unbestueckt,
i2c-LevelShifter bestueckt,
StrongPullup optional


Edit2:
Ich revidiere meine Meinung zum Layer bNames, das aktuell gewählte bPlace ist besser.
Begründung: Falls man die Platinene in den Nutzen setzen will, braucht man sich um diese Beschriftung nicht kümmern. Bei meiner Optolink Platine bzw. beim der USBseriell Platine fehlen diese Beschriftungen (Version bzw. Beschriftung der Pins) nämlich genau aus diesem Grund >:( >:( >:()
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

hexenmeister

Vielen Dank für eine ausführliche Prüfung :)

Zitat von: PeMue am 25 Juni 2016, 18:25:21
Was ich meine, verstanden zu haben:
- Spannungsversorgung in drei Stufen (entweder IC1 oder IC2 oder direkt 5 V)
genau
Zitat
- 1-wire entweder per Busmaster oder direkt am ESP Pin (mit allen möglichen Schikanen: Abschluss, Filter, "strong pullup")
ja, "stron pullup" geht natürlich nur mit dem Busmaster-Chip
Zitat
- Spannungsversorgung 1-wire entweder mit 5 V oder 3,3 V (der Regler dafür sitzt vermutlich auf dem WeMosD1mini)
WeMos hat einen und der ist auch auf ein Pin ausgeführt
Zitat
- DS18B20 ist mit auf der Platine
- OPT ist vermutlich ein Taster, der von der Firmware eingelesen werden kann
Genau wie die LED. Für beides habe ich noch keine konkrete Verwendung.
Zitat
Meine Fragen:
- Wofür ist der zweite VCC bei 1W-OUT, ich dachte eher (nach der Erklärung von André, hier müsste ein zweiter 1-W Anschluß da sein)? Und wenn, müssten dann noch mehr Anschlüsse für 1-wire da sein ...
Eine Rückführung des Bussen zurück zum Master ist nicht notig, ist ja kein Ring ;D
Der Grund ist einfach: ich habe viele 2-poligen ScrewTerminals in 3,5mm Raster und keine 3-poligen. Ich wollte beides nutzen können. Eigentlich würde da einfach ein 'Loch' reichen, ich wollte dem aber eine (halbwegs) sinnvolle Aufgabe geben ;D
Zitat
- Besteht die Möglichkeit, neben VIN1 auf der Unterseite noch eine microUSB Typ B zu platzieren (Codename: die schlecht lötbare)?
Wäre zwar einfache Sache, ist aber nicht nötig, da ein WeMos eine solche schon mitbringt. Dadurch kann dieser sowohl programmiert, als auch mit der Spannung versorgt werden. Einen USB-Chip und sogar eine Autoreset-Schaltung hat er bereits.
Zitat
- Das Bauteil ZD1 verstehe ich nicht (warum die "solder jumper" unter dem Bauteil?); vermutlich schon im Bauteil definiert, zum überbrücken, falls keine ZD1 bestückt ist ...
Das ist ein ESP-protection-Chip. Da nicht immer wirklich nötig, habe ich in das Bauteil die Lötjumper integriert.
Zitat
- Ich vermute mal, die notwendigen pullups/pulldowns für den ESP bzw. der Programmiertaster ist schon auf dem WeMosD1mini mit drauf.
jep :)
Zitat
Schönheitskorrekturen:
- Die Ground Symbole im Schaltplan würde ich generell nach unten zeichnen  ;)

Noch offen:
Den "Roman" auf der Platinenrückseite würde ich gerne noch korrekturlesen  ;D -> erl.
Die Platinenbeschriftung hätte ich auf das Layer bNames gemacht, der Effekt bleibt derselbe  ;D

Firmware:
- Kann die Platine mit Busmaster (Firmware: ESP transparent bridge) über die normalen fhem Module betrieben werden?
theoretisch ja, praktisch dürfte es Probleme mit Timing geben.
Zitat
- Wie ist das, wenn der 1-wire Bus direkt am ESP dranhängt; ich vermute, da gibt es noch nichts, oder?
Doch, sowohl EasyESP, als auch Firmware von pf@anne können das.
Zitat
Ansonsten: Sehr übersichtliches Layout, habe auch beim Rendern bei OSHPark nichts kritisches gefunden. DRC habe ich allerdings nicht durchgeführt ...
Danke ;) DRC spuckt einiges an 'overlap', aber die Meldungen sind ok.
Zitat
Und: wenn machbar, würde ich eine Platine als für Software Entwicklung ordern (habe aber gerade noch vier andere Platinen da, die ich testen muss, also hat das keine Eile).
Ich habe für Dich 1-2 Stück bereits fest eingeplant ;)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

PeMue

Hallo Alexander,

habe noch folgenden Punkt: Kann der WeMosD1mini Spannungsregler die "Rückwärtsspannung" von IC1 bzw. IC2 ab?
Das müsste dieser hier sein:
http://www.richtek.com/assets/product_file/RT9013/DS9013-10.pdf
Habe leider im Datenblatt nichts dazu gefunden.

Zitat von: hexenmeister am 26 Juni 2016, 22:05:17
Doch, sowohl EasyESP, als auch Firmware von pf@nne können das.
Auf der ESP Seite habe ich schon einiges für 1-wire gefunden. Aber wie kommen die Daten von EasyESP bzw. pf@nnes Firmware in fhem? Gibt es da schon ein Modul dafür?

Viele Grüße

Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

hexenmeister

Zitat von: PeMue am 27 Juni 2016, 08:07:00
Kann der WeMosD1mini Spannungsregler die "Rückwärtsspannung" von IC1 bzw. IC2 ab?
Das wird er gar nicht. Das Schema ist so aufgebaut, dass die Eingangsspannung auf 5V gebracht wird, der Regler auf WeMos regelt diese nochmal auf 3,3V runter. Rckwerts wäre, wenn man das ganze mit 3,3V betreiben würde.

Zitat
Auf der ESP Seite habe ich schon einiges für 1-wire gefunden. Aber wie kommen die Daten von EasyESP bzw. pf@nnes Firmware in fhem? Gibt es da schon ein Modul dafür?
Die Anbindung geht per MQTT. Ist einfach und universell :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

justme1968

die 'normalen' 1-wire module sehr nah am 1-wire bus. und werden out of the box erst mal nicht gehen. aber locutus hat bei seiner 1-wire zu wlan bridge eine firmware die das scheinbar kann. ich glaube auch das ist nicht unbedingt sinnvoll ist.

zumindest für meinen anwendungsfall möchte ich einfach nur die readings in fhem haben. mit so wenig overhead und zusatz komponenten wie möglich und so viel intelligenz wie möglich auf dem esp. ich habe irgendwie auch eine unbegründete abneigung gegen mqtt :) (und auch gerade keine zeit und lust es mir genauer anzusehen).

deshalb habe ich vor eine firmware auf basis von hcs jeelink bridge zu bauen die in richtung fhem das kvp protokoll/modul verwendet. die idee ist z.b. die erkannten 1-wire devices über das web interface auf dem esp zu gruppieren und zu benennen. auf fhem seite soll dann alles weitere automatisch gehen.

d.h. über kurz oder lang wird es 2 oder sogar 3 möglichkeiten geben wie man die daten in richtung fhem bekommt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

PeMue

Zitat von: hexenmeister am 27 Juni 2016, 14:50:36
Das wird er gar nicht. Das Schema ist so aufgebaut, dass die Eingangsspannung auf 5V gebracht wird, der Regler auf WeMos regelt diese nochmal auf 3,3V runter. Rückwärts wäre, wenn man das ganze mit 3,3V betreiben würde.
8) 8) 8)  >:( >:( >:( vorher denken und dann schreiben >:( >:( >:( 8) 8) 8)

Da fehlt jetzt ein ganz großer DANKE Button! ;D

Zitat von: justme1968 am 27 Juni 2016, 15:38:06
deshalb habe ich vor eine firmware auf basis von hcs jeelink bridge zu bauen die in richtung fhem das kvp protokoll/modul verwendet. die idee ist z.b. die erkannten 1-wire devices über das web interface auf dem esp zu gruppieren und zu benennen. auf fhem seite soll dann alles weitere automatisch gehen.
Da wäre ich extrem dran interessiert, das würde ich nämlich dann in meinen Optolink WLAN Adapter einbauen ...

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Pf@nne

Moin,

kurz zur Ankopplung der Messdaten......

MQTT ist, mal abgesehen vom Broker der z.B. auf einem Raspberry laufen muss, fast overheadlos.
Mit einer Zeile ist das Reading des MQTT-subscribe in FHEM eingebunden, tut fast garnicht weh.....

Es ist aber auch möglich, dass die ESP-Bridge direkt in eine dbLOG-MySQL-Datenbank schreibt, dann könnten die Readings zum Plotten direkt aus der Datenbank geholt werden.
Die Brifge und FHEM hätten dann genau wie bei MQTT nichtmal eine direkte Verbindung.

Die alpha-Version meiner FW hat im Grunde schon alles drin:


  • Konfiguration der Zugangsdaten über WEB-Interface
  • Anzeige der Sensoren über WEB-Interface
  • MQTT
  • MySQL (in Arbeit)

Zitat von: justme1968 am 27 Juni 2016, 15:38:06
die 'normalen' 1-wire module sehr nah am 1-wire bus. und werden out of the box erst mal nicht gehen. aber locutus hat bei seiner 1-wire zu wlan bridge eine firmware die das scheinbar kann. ich glaube auch das ist nicht unbedingt sinnvoll ist.

Wo siehst du da Probleme?
Ich habe seit über einem Jahr 15 DS18B20 (1m Zuleitung) im Stern an einem GPIO mit 3V3 an meinem Raspberry am laufen.

Gruß
Pf@nne
FHEM auf: DS415+ (Master), Raspberry Pi 2

justme1968

#187
es ging mir nicht um die physikalische nähe sondern ums protokoll.

OWServer/OWDevice setzen owfs auf und sind aktuell noch blockierend. die module von pha nutzen entweder OWServer oder greifen direkt auf einen busmaster zu. beides verträgt sich erst mal nicht mit dem esp. statt die FHEM module so zu erweitern mache ich lieber den esp so eigenständig wie möglich und lasse ihn nur noch readings richtung FHEM pushen.

für meinen anwendungsfall wird auch die konfiguration welcher sensor zu welchem device gehört und welches reading er erzeugt auf dem esp erfolgen. also z.b. sensor x und sensor y sind vorlauf und rücklauf im esszimmer, sensor 1-4 sind zwei kreise mit jeweils Vorlauf und rücklauf im esszimmer, ...

in FHEM gibt es dann automatisch ein device fbh esszimmer mit zwei readings und ein device fbh wohnzimmer mit vier readings.

auf esp soll das dann in einem zweiten schritt um die autonome steuerung der heizkreise ausgebaut werden.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Pf@nne

Zitat von: justme1968 am 27 Juni 2016, 17:27:28
es ging mir nicht um die physikalische nähe sondern ums protokoll.

OWServer/OWDevice setzen owfs auf und sind aktuell noch blockierend. die module von pha nutzen entweder OWServer oder greifen direkt auf einen busmaster zu. beides verträgt sich erst mal nicht mit dem esp. statt die FHEM module so zu erweitern mache ich lieber den esp so eigenständig wie möglich und lasse ihn nur noch readings richtung FHEM pushen.

für meinen anwendungsfall wird auch die konfiguration welcher sensor zu welchem device gehört und welches reading er erzeugt auf dem esp erfolgen. also z.b. sensor x und sensor y sind vorlauf und rücklauf im esszimmer, sensor 1-4 sind zwei kreise mit jeweils Vorlauf und rücklauf im esszimmer, ...

in FHEM gibt es dann automatisch ein device fbh esszimmer mit zwei readings und ein device fbh wohnzimmer mit vier readings.

auf esp soll das dann in einem zweiten schritt um die autonome steuerung der heizkreise ausgebaut werden.

gruss
  andre

Ach so..... da bin ich jetzt mal von ausgegangen, dass der ESP nicht 1-Wire emuliert, das wäre ja auch von hinten durch die Brust ins Auge..... :o

Zitatund lasse ihn nur noch readings richtung FHEM pushen.
Da wäre MQTT doch die richtige Wahl.... womit wolltest du denn in FHEM einkoppeln?
Die Zuweisung der 1-Wire-Devices mache ich mit einem JSON-File der im SPIFFS abgelegt wird.

Gruß
Pf@nne


FHEM auf: DS415+ (Master), Raspberry Pi 2

justme1968

auf FHEM seite werde ich das KeyValueProtokoll modul verwenden. mqtt ist mir einfach unsympathisch.

die konfiguration soll über die web oberfläche gehen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

PeMue

Zitat von: justme1968 am 27 Juni 2016, 20:40:25
auf FHEM seite werde ich das KeyValueProtokoll modul verwenden.
Gibt es da irgendwo (außer im Modul selber) eine Doku? Ich war auch schon am Überlegen, ob ich die Temperaturen nicht ins LaCrosse Format wandle und dann das LaCrosse Modul verwende ...

Danke + Gruß

Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

justme1968

es gibt aktuell nur die doku im modul, die entstehungsgeschichte  im thread und zwei thread mit einer kurzen erläuterung.

du musst nicht ins lacrosse dormat wandeln.

du sendest einfach

OK VALUES <type> <id> <reading>=<wert>,...

das mit dem dictionary ist nur eine feinheit damit die nachrichten kürzer werden.

type und id kannst du dir ausdenken.

alle readings für ein eindeutiges type,id paar landen im selben device das per autocreate angelegt wird.

du kannst über diese eine verbindung beliebigen viele types, ids senden und pro zeile beliebig viele readings.

wenn man das prinzip raus hat ist es super einfach und flexibel.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

PeMue

Zitat von: justme1968 am 27 Juni 2016, 21:05:41
es gibt aktuell nur die doku im modul, die entstehungsgeschichte  im thread und zwei thread mit einer kurzen erläuterung.
Ok, das müssten dann diese sein:
https://forum.fhem.de/index.php/topic,51131.msg427692.html#msg427692
https://forum.fhem.de/index.php/topic,50825.msg424646.html#msg424646 und
https://forum.fhem.de/index.php/topic,45545.msg373296.html#msg373296

Scheint ja wirklich einfach zu sein. Vielleicht kann ich bei HCS Arduino Code klauen  ;D

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

hexenmeister

Nach Peter's Prüfung, denke ich, ich kann mal eine kleine Charge (10 Stück) testweise bestellen.
Ich selbst brauche 2-3, jetzt die Frage an Peter, Marco, Miro und Andre: wollt ihr zum Testen und Entwickeln je 1-2 Leerplatinen haben? @Andre: Ich bräuchte ggf. deine Adresse. Eilt aben nicht, die Produktion/Lieferung dauert eh Wochen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

justme1968

ja. die threads sind es.

sein esp lacrosse gateway ist besser zum klauen :)

er hat mir schon ein grundgerüst mit config web seiten, ota update môglichkeit und kvp gemacht.

das wird sie grundlage für die 1 wire version und sollte auch für andere Anwendungen einfach zu erweitern sein.

gruss
  andre

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968