FHEM Forum

Hallo Forum,
ich hab ein neues 1-Wire Interface gebaut, mit dem ein 1-Wire-Bus direkt ans Ethernet angekoppelt wird. Und zwar mit Hilfe dieses Moduls hier:

http://shop.kristech.pl/p/32/258/kt-eth-uart-1-.html

Das Teil stellt zwei UART-Ports zur Verfügung, an die man je einen DS2480 direkt anschließen kann. Auf der FHEM-Seite wird zeitgleich mit FHEM das Programm socat gestartet, das eine Telnet-Verbindung zu dem Kristech-Teil aufbaut und FHEM als virtuellen seriellen Port  zur Verfügung stellt:

socat PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.0.96:23

Das OWX-Modul als Backend greift auf diesen seriellen Port zu und funktioniert wie gewohnt.

Warum und wo soll dieses einsetzbar sein ? Ziel ist zunächst, 1-Wire in größerer Entfernung via Ethernet anzusprechen. Da gibt es eine Lücke:

- Der CUNO hat sich als ziemlich wenig tauglich erwiesen, komplexere 1-Wire Systeme aus der Entfernung zu bedienen.
- Einen Raspberry Pi mit OWFS und irgendeinem Interface kann man zwar mit OWServer ansprechen. Das läuft stabil (bei mir auch), ist aber wegen des Einstiegs in die RPi-Welt nicht jedermannes Sache.

Das Kristech-Modul verbraucht sehr wenig elektrische Leistung (weniger als 1 Watt) und ist sehr viel kleiner als ein RPi.

Eine detaillierte Anleitung werde ich demnächst posten.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 18 Januar 2014, 21:00:45Ziel ist zunächst, 1-Wire in größerer Entfernung via Ethernet anzusprechen. Da gibt es eine Lücke:

Schicke Idee, aber die genannte Lücke ist schon lange durch den Arduino mit Ethernet über OWX mit FRM geschlossen ;-)
Aber lass Dich deswegen nicht bremsen, Vielfalt schadet ja nicht :-)

Gruß,

Norbert

Ach, Du mit Deinem Arduino ...

So lange es die Dinger nicht fertig geflasht zu kaufen gibt, ist da eine Lücke. Aber lass Dich in Deinem Enthusiasmus nicht bremsen  ;D

LG

pah

Mir gefällt die Idee eines kompakten Ethernet-Buskopplers, das hatte ich mir vom CUNO beim Kauf erhofft.
Die Lücke besteht also durchaus nach wie vor. :) Das ganze transparent als UART-Port durchzuleiten wäre prima.
Ein wirkliches Novum wäre es, wenn man über einen PoE IC (nach 802.11af) den Bus speisen könnte. Das würde einige Probleme mit Sternverkabelungen lösen.

Ein Arduino mit angeflanschten Bus-Adaptern ist da auch nur bedingt geeignet, eben aus dem von pah genannten Grund: "ist aber wegen des Einstiegs in die Arduino [RPi]-Welt nicht jedermannes Sache."
Ein fertiges Board wäre da also schon viel schöner.

Mein "Traum"-Ethernet-Buskoppler sieht so aus:
- PoE fähig nach 802.11af (oder Stromversorgung per normalem Netzteil)
- vollständig SMD, also möglichst kleiner Footprint
- Jumperbarer RC-Filter (ggf. per Software, 2. Version ;), dann evtl. verschiedene RC-Kombinationen)
- Schraubklemmen und RJ45 für 1-Wire
- Nur ein DS2480
- evtl. ein DS18B20 onboard, rein zur "Ja-die-Kommunikation-funktioniert"-Bestätigung
- Per OWX ansprechbar
- vorgeflasht, FW-Update per Ethernet wünschenswert
- natürlich niedriger Stromverbrauch
- Bohrungen für Befestigung, z.B. für einen Hutschienenclip.
- Als Sahnehäubchen wäre es schön, wenn das ganze sich in ein Keystone-Panel klicken ließe, mit 1-Wire Schraubklemmen auf der Rückseite und Ethernet vorne. Dazu müsste die Platine aber wirklich klein und länglich werden.

Für größere Projekte wäre eine Mehr-Port Version natürlich genial, vorausgesetzt es lassen sich noch mehr UARTs am Microcontroller einrichten. Dann gleich mit 4 (oder mehr) DS2480 und separaten Anschlüssen. Dann eher nicht mehr als Keystone, dafür dann mit galvanisch getrennter Stromversorgung für die einzelnen Busreihen. Wie weit man da mit den spezifizierten 15,4 Watt von PoE kommt, weiß ich jetzt nicht einzuschätzen.

Für Sicherheit muss man als Betreiber des Moduls dann eben per VLAN sorgen, denn ich glaube eine Verschlüsselung einzubauen wäre übertriebener Aufwand.

So, das ist jetzt evtl. alles etwas viel verlangt, aber das musste einfach mal raus, vll. schnappt ja jemand eine Idee auf. Ich wäre froh, sowas kaufen zu können. :)

Beste Grüße,
Stefan

Seeeeeehr gut, da würde ich glatt meine Raspberrys ersetzen. Leider haben die KrisTechs heftige Versandkosten nach Deutschland, was ein "mal so testen" etwas verhindert. Da wäre fast eine Sammelbestellung angebracht.
@pah: läuft das problemlos und stabil?

Zitat von: spectra am 19 Januar 2014, 12:47:20Ein Arduino mit angeflanschten Bus-Adaptern[...]wegen des Einstiegs in die Arduino [RPi]-Welt nicht jedermannes Sache. Ein fertiges Board wäre da also schon viel schöner.

Zitat von: Prof. Dr. Peter Henning am 19 Januar 2014, 05:36:40
So lange es die Dinger nicht fertig geflasht zu kaufen gibt, ist da eine Lücke.

Meint Ihr tatsächlich, dass fertig mit EthernetFirmata geflashte Arduinos mit 1-Wire-Anschluss absetzbar wären?

@ntruchsess:

Ich denke, ja - das sollte man aber nicht auf meinem Denken beruhen lassen, sondern auf einer Umfrage basieren.

@spectra:

Nix RJ45. Die sind viel zu voluminös - auf dem Raum bringe ich mindestens zwei 3,5 mm Klinkenbuchsen unter.
Nix DS1820 on board - sondern einen DS2401. Die Temperaturmessung auf dem Board kann man wegen der Abwärme des Adapters sowieso vergessen

@UweH:

Ja, seit 1 Woche ohne Probleme. Ist aber noch kein fester Aufbau, sondern sitzt auf einem Steckbrett. Kommt noch in ein Hutschienengehäuse.

Betreffend das Teil von Kristech:

• es gibt eine Managementsoftware dafür
• Modul ist konfigurierbar per eingebautem Mikro-Webserver
• Firmware ist per Ethernet update-fähig
• es werden mehrere verschiedene Protokolle gefahren, anscheinend ist auch eine Verschlüsselung möglich
• Ports etc. sind konfigurierbar
• es gibt eine eingebaute Mikro-Firewall - wahrscheinlich als Paketfilter

- also ganz komfortabel. Mein Polnisch ist aber nicht gut genug, um alle Details bisher schon zu durchblicken. Die interessanteste Option scheint mir im Moment die einer Verschlüsselung zu sein - damit kann man auch aus dem eigenen Haus herausgehen.

Auch die Ankopplung von OWX mit socat ist nur eine Zwischenlösung, man kann problemlos eine Erweiterung des seriellen Backends bauen, die direkt auf den Socket schreibt.

LG

pah

Frage: wäre nicht auch ein WIZ107SR http://www.wiznet.co.kr/sub_modules/en/product/Product_Detail.asp?cate1=5&cate2=8&cate3=0&pid=1092 (http://www.wiznet.co.kr/sub_modules/en/product/Product_Detail.asp?cate1=5&cate2=8&cate3=0&pid=1092) dafür einsetzbar?
Den gibts bei etlichen Distris....

l.g. erwin

Na ja, auf den ersten Blick: So halb.

Prinzipiell sollte das gehen, das Modul verlangt aber eine Spannungsversorgung von 3,3 V, die man noch separat aus den 5V generieren müsste. Und die Programmierung scheint nicht so komfortabel zu sein, wie bei Kristech (dort geht es über einen eingebauten Mikro-Webserver). Außerdem müsste man ausprobieren, ob das mit socat auch zusammenarbeitet.

Ich habe dafür im Moment keine Zeit, also: Go ahead.

Hier die erste (noch sehr rudimentäre) Dokumentation

http://www.fhemwiki.de/wiki/1W-ETH

LG

pah

Hallo pah,

ich konnte es natürlich nicht lassen... ;-)
Testaufbau steht, Zugriff und Firmwareupdate ok, aber das definieren des virtuellen Ports hakt. Dieser Befehl: socat PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.xxx.xx:23bewirkt offenbar gar nichts (ja, socat ist installiert), als Antwort auf die Definition sagt mir FHEM: OWX: Can't open serial device /dev/vmodem0: Permission denied Verständlich, da in /dev kein vmodem0 existiert. Gibt's da noch einen Zwischenschritt, den ich nicht ausgeführt habe?

Danke

Edit: Wenn ich Deinen Text richtig interpretiere, ist das hier

ZitatAuf der FHEM-Seite wird zeitgleich mit FHEM das Programm socat gestartet

der Knackpunkt, der mich bremst..

Ahh,

Device permissions....
Kommt daher, dass FHEM nicht als root ausgeführt wird. Ich überlege mir ein eordentliche Lösung. Zwischenlösung: Bitte mit ls -l /dev/vmodem0 abfragen, auf welchen pts das zeigt:

z.B. ist die ausgabe lrwxrwxrwx 1 root root 10 Jan 26 08:15 /dev/vmodem0 -> /dev/pts/4

Dann bitte mit chmod 666 /dev/pts/4 den Port zum Schreiben freigeben.

LG

pah

cool, so einen ethernetadapter hatte ich mal bei meiner letzten kristech bestellung mit geordert. der liegt jetzt bei mir zum testen bereit...
Da ich demnächste eine PlatinenSammelbestellung mache, überlege ich gerade aus pah´s Schaltplan eine Huckepackplatine fürs 1wire zu erstellen ;) und davon auch ein paar zu ordern....
Interessenten??

Edit: pah: muss in deine Schaltung noch eine Längenkompensation mit rein?? Gibts in der Schaltung noch Optimierungspotential? Einmal bestellt ist keine Änderung mehr möglich :(

@pah: Diese Meldung kommt von ls:ls:Zugriff auf /dev/vmodem0 nicht möglich: Datei oder Verzeichnis nicht gefundenEs gibt in meinem /dev kein vmodem0. Wie kann man das definieren/anlegen/klauen oder was auch immer? Ich habe in den dürftigen Infos im Netz leider nicht das Passende gefunden (oder hab's nicht verstanden bzw das Falsche gesucht...)

@Tobias: Du kannst Dir dafür mal meinen Testaufbau ansehen, ich habe den Schaltplan von pah mal etwas aufgebohrt, das ist aber ganz sicher noch nicht der letzte Stand. Den Rest müssen die Tests ergeben.
Die Platine kannst Du ignorieren, das ist nur mein derzeitiger Test. Da ich 12V auf einer Leitung mitführe, habe ich ein 12V-Schaltnetzteil als Versorgung und auf dem Testaufbau einen DC/DC-Wandler für die 5V (das sind übrigens solche Teile:http://www.ebay.de/itm/DC-DC-Converter-Einstellbare-Leistung-Abwartsmodul-Buck-LM2596-S-1-23V-30V-HE-/400614066483?pt=LH_DefaultDomain_77&hash=item5d46758933 (http://www.ebay.de/itm/DC-DC-Converter-Einstellbare-Leistung-Abwartsmodul-Buck-LM2596-S-1-23V-30V-HE-/400614066483?pt=LH_DefaultDomain_77&hash=item5d46758933), wegen der regelbaren Ausgangsspannung sehr universell einsetzbar...).

Das Interface hat übrigens einen kleinen Nachteil, es ist 35mm breit und damit 2mm zu breit für 2-fach Hutschienengehäuse. Schade, somit muss man viel Platz im größeren Gehäuse verschenken.

Interessent für Platine bin ich auch - denn das Teil läuft bestens. Bei mir sehen die Sachen nach der Entwicklung immer ein wenig, nun, sagen wir, rustikal aus.

Betreffend die Schaltung: Man kann noch einen Pullup-Widerstand und ein RC-Glied mit auf die Platine nehmen. Und sich überlegen, vielleicht nur einen DS2480 anzubauen - in einem nur 25mm breiten Hutschienengehäude geht das gerade so unterzubringen, wenn man das Kristech-Modul hochkant stellt, siehe Foto.

Betreffend die Device permissions:

Ich habe in mein FHEM-Startscript die folgenden vier Zeilen eingebaut:

  socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.0.96:23 &
  sleep 2
  pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
  chmod 666 $pty

LG

pah

@UweH:

1. Ist das Interface per ping erreichbar ?
2. Ist das Kristech-Teil als Webserver zu finden (Achtung, Jumper öffnen, siehe Foto oben) ?
3. Ist socat installiert, und läuft es ? Wenn ja, welche Befehlszeile?

Betreffend die Breite, wie gesagt, ich habe es in 25 mm Hutschienengehäuse untegberacht, incl. 2 Klinkenbuchsen für meine nicht-stationären 1-Wire devices ...

LG

pah

ich habe es auch schon in ein HUT gesetzt. passt wie gesagt nur hochkant rein.
Dazu muss aber auf der untenliegenden Platine eine Buchsenleistenverlängerung mit rein damit der ETH Port bis oben hin passt....
@UweH: habmal gleich 2 geordert.... bislang habe ich ein Arduino-USB-Netzteil fürs Breadboard benutzt (kostet auch nur 2,50Euro aus China)

Zitat1. Ist das Interface per ping erreichbar ?

Ja

Zitat2. Ist das Kristech-Teil als Webserver zu finden (Achtung, Jumper öffnen, siehe Foro oben) ?

Ja, das funktioniert alles, auch die Firmware hab ich auf die englische Version gezogen.

Zitat3. Ist socat installiert, und läuft es ? Wenn ja, welche Befehlszeile?

socat ist installiert, was meinst Du mit welche Befehlszeile?

ZitatIch habe in mein FHEM-Startscript die folgenden vier Zeilen eingebaut:

  socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.0.96:23 &
  sleep 2
  pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
  chmod 666 $pty

In init.d/fhem oder fhem.pl?

ZitatBetreffend die Schaltung: Man kann noch einen Pullup-Widerstand und ein RC-Glied mit auf die Platine nehmen.

Ich habe meinen Testschaltplan mit angehangen.

ZitatBetreffend die Breite, wie gesagt, ich habe es in 25 mm Hutschienengehäuse untegberacht, incl. 2 Klinkenbuchsen für meine nicht-stationären 1-Wire devices ...

Senkrechten Einbau wollte ich eigentlich vermeiden... Es gibt bei Bernic http://www.bernic.dk/catalogue/item/76-series-350-mm-2-module-enclosure (http://www.bernic.dk/catalogue/item/76-series-350-mm-2-module-enclosure) ein 3-fach-Gehäuse, der verkauft über Conrad, aber leider nicht das 52mm-Gehäuse. Verrückt.

Na, da haben wir den Fehler doch. Natürlich muss socat auch gestartet werden - eben mit der Zeile im /etc/init.d/fhem

socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.0.96:23 &

VOR dem Start von FHEM. Dieses Programm sorgt nur für eine Verbindung des TCP-Socket mit der virtuellen seriellen Schnittstelle /dev/vmodem0. Diese wird aber nur als Smylink angelegt, darunter liegt ein virtueller TTY-Port (ist bei Unix so üblich).

  sleep 2
  pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
  chmod 666 $pty

sorgt dafür, dass FHEM auf das darunter liegende PTY auch schreiben darf.

Sicherheitshalber in den Teil, der FHEM stoppt, auch noch einen Stop von socat einbauen:

  pid=`ps -eo fname,pid | grep socat | grep -oE '[^ ]+$'`
  kill -9 $pid 

LG

pah

uwe, warum willst du senkrechten einbau vermeiden? Siehst du Probleme??

Na ja, die Netzwerkstecker müssen vor dem Einführen um 90 Grad gedreht werden. Und da das in zwei Richtungen möglich ist, wird durch den senkrechten Einbau eine zusätzliche Fehlerquelle geschaffen.

LG

pah

@pah: Das war's, jetzt läuft's. Danke :)
Jetzt müsste das Teil nur noch auf der 1-Wire-Seite das angeschlossene Device finden, aber daran arbeite ich noch.

Der senkrechte Einbau ist vielleicht nicht unbedingt eine Fehlerquelle, aber die Verbindung zur Basisplatine wäre elektrisch und mechanisch einfacher und sicherer.

Einfacher ja - aber sicherer nicht. Wie man an meinem Foto sieht, gibt es zwei Zusatzboards (in dem Fall Experimentierplatten mit Lochraster), die sich alle gegenseitig stützen. Mechanisch sehr stabil.

LG

pah

Hallo pah,

was bedeutet diese Meldung im Log:
2014.01.26 15:10:48 3: OWX: Reset failure on bus Test_ETH

Mit get Test_ETH devices bekomme ich dieses:
OWX: 1-Wire devices found on bus Test_ETH
aber das angeschlossene Device wird nicht gefunden.

Die Definition des Interface sieht so aus:

bzgl senkrechtem Einbau hatte ich mir das so vorgestellt:
(http://www.eservice-online.de/out/pictures/master/product/1/buskopplerethernet-1_p1.jpg)

Damit geht die Tür des Verteilerschrankes nicht mehr zu. Dann eher so wie bei pah. Anschlüsse bei Hutschieneneinbauten immer nach oben oder unten.

@UweH: Sieht so aus, als ob er den 2480 nicht findet.

Was steht denn nach dem "define" im Log, bzw. was ist die Startmeldung von OWX ?

LG

pah

Zitat von: UweH am 26 Januar 2014, 16:15:57
Damit geht die Tür des Verteilerschrankes nicht mehr zu. Dann eher so wie bei pah. Anschlüsse bei Hutschieneneinbauten immer nach oben oder unten.

Es gibt aber auch Netzwerkkabel mit abgewinkelten Stecker...
Ich überleg mir aber auch mal ob man den Stecker  im Hutschienengehäuse nach unten herausführen kann...

So sieht's beim Start aus:

2014.01.26 16:49:47 3: Opening Test_ETH device /dev/vmodem0
2014.01.26 16:49:47 3: Setting Test_ETH baudrate to 9600
2014.01.26 16:49:47 3: Test_ETH device opened
2014.01.26 16:49:47 1: OWX: Serial device /dev/vmodem0 defined
2014.01.26 16:49:49 1: OWX: 1-Wire bus Test_ETH: interface master DS2480 detected for the first time
Den 2480 scheint er also zu finden.
Als Anwort auf get Test_ETH devices bekomme ich wieder
2014.01.26 16:52:12 1: OWX: Search CRC failed
2014.01.26 16:52:12 1: OWX: 1-Wire devices found on bus Test_ETH ()

Auf der Konsole bekomme ich mehrmals hintereinander beim Start dieses zu sehen:
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 698.

Sicher, dass die Devices richtig angeschlossen sind ? Wenn er die richtige Antwort vom DS2480 bekommt (und das sagr OWX ja ...), geht irgendetwas auf dem Bus schief.

LG

pah

@pah: Ich steh jetzt echt ein bisschen auf dem Schlauch...sowas hab ich bei noch keinem Interface gehabt. Da ist definitiv alles richtig angeschlossen...
Kannst Du mir bitte mal Deine komplette Startdatei zeigen? Ich glaube, das beenden von socat funktioniert nicht korrekt. Bei shutdown restart wird vmodem0 nicht geöffnet, erst wenn ich fhem auf der Konsole stoppe und starte ist es wieder da.
Aber das bringt mich nicht zum Kern der Sache.
Diese Einstellungen sind ok, oder?

Übrigens bekomme ich während der Suche nach Devices gefühlte 10.000x folgende Meldung auf der Konsole:
Use of uninitialized value $m in addition (+) at ./FHEM/00_OWX.pm line 1454.
Use of uninitialized value $string_part in concatenation (.) or string at ./FHEM/00_OWX.pm line 1456.

Was hakt denn da?

Edit: Nach dem Löschen der fhem.save und einem Neustart ist dieses Verhalten wieder wech...  :o

Nochmal edit: Nachdem ich nun ALLES, was irgendwie nach OWX aussah, von diesem Raspi geworfen hatte, nochmal die fhem.save gelöscht und einen Neustart durchgeführt hatte, klappt es jetzt. ::)

1. Die Einstellungen am Kristech-Ding sind ok.

2. socat soll bei shutdown restart auch nicht beendet werden.

3 Startskript hängt dran.

Nochmal: Wenn OWX den DS2480 erkennt, bekommt es schon eine richtig komplizierte Antwort von ihm. Ich vermute immer noch, das irgendetwas mit dem Bus nicht stimmt.

LG

pah

Zitat2. socat soll bei shutdown restart auch nicht beendet werden.

Aber vmodem0 ist nach einem shutdown restart nicht mehr erreichbar. Ist aber wahrscheinlich zum gegenwärtigen Zeitpunkt der Entwicklung auch irrelevant. Wichtig ist, dass es überhaupt erst mal funktioniert. :)

Hi Uwe,
kannst du mir eine bedrahtete Ersatzkombination für den DS9503 geben?

Zitatkannst du mir eine bedrahtete Ersatzkombination für den DS9503 geben?

Müsste ich bei Gelegenheit ich tiefer wühlen. Der Aufbau des DS9503 geht zwar aus dem Datenblatt hervor, aber die speziellen Werte der Diode nicht wirklich. Vor allem die ersten beiden Abschnitte des Datenblattes sind interessant. Auf Grund dessen dürfte eine Ersatzschaltung vielleicht nicht ganz so einfach sein.

Zitat von: UweH am 27 Januar 2014, 17:52:24
Müsste ich bei Gelegenheit ich tiefer wühlen. Der Aufbau des DS9503 geht zwar aus dem Datenblatt hervor, aber die speziellen Werte der Diode nicht wirklich. Vor allem die ersten beiden Abschnitte des Datenblattes sind interessant. Auf Grund dessen dürfte eine Ersatzschaltung vielleicht nicht ganz so einfach sein.

Nochzumal ich einen DS9503 nicht in der Target3001 Bauteilliste finde :(

Deswegen habe ich ihn selber angelegt. Kopier ihn aus meiner Datei raus.

habs mal eine HUT2C Platine erstellt. Und mit bedrahteten Bauteilen. SMD ist sind nur noch die DSxxxx Bauteile.
Die K2X07 kann sich noch geringfügig verschieben. Die gewinkelte Buchsenleiste sollte heute bei mir eintreffen, dann kann ich es genau ausmessen.
Könnt Ihr mal bitte auf das Layout draufschauen??

Finde auf Anhieb keinen Fehler.

@UweH: Läuft es jetzt ?

LG

pah

@pah: Ja, siehe hier:

Zitat
Nochmal edit: Nachdem ich nun ALLES, was irgendwie nach OWX aussah, von diesem Raspi geworfen hatte, nochmal die fhem.save gelöscht und einen Neustart durchgeführt hatte, klappt es jetzt. ::)

Ich werde mal versuchen, dieses Verhalten zu replizieren, bzw. ist es vielleicht so, dass OWX nicht gleichzeitig mit dem virtuellen seriellen Port und einem USB-Interface gleichzeitig umgehen kann? Der Ethernet-Adapter hat jedenfalls funktioniert, nachdem ich ein parallel laufendes 1-wire-Netz gekillt hatte, welches ich über ein USB-Interface angeschlossen hatte...

@Tobias: Ich würde an Deiner Stelle noch warten, bis verlässliche Tests in Bezug auf die Stabilität des 1-Wire-Netzes vorliegen. Vielleicht müssen auch hier noch Kompensationsschaltungen ran oder PullUps oder...oder...
Wird sich alles in den nächsten Tagen zeigen, bzw. die Frage an pah, wie umfangreich ist Dein angeschlossenes 1-Wire-Netzwerk?

Keine Angst... Die Bestellung peile ich erst nächste Woche an...
Allerdings würde dafür stimmen eine Längenkompensationsschaltung und einen Pullup einzubauen...
Mich selbst stört es nicht, ich betreibe alles was nach 1wire ausschaut mit einem/mehreren 1wire Hubs die mir auch gleich 12V bereitstellen

Btw: Mit OWServer sollte das eigentlich auch funktionieren, korrekt?

Meine Anmerkungen hast Du per Mail.

ZitatBtw: Mit OWServer sollte das eigentlich auch funktionieren, korrekt?

Hab ich mal probiert, klappte nicht. Da wird pah wohl was zu sagen können.

An meinem einzelnen Raspberry sind drei USB-Adapter für 1-Wire sowie ein vierter für eine serielle Schnittstelle zu meiner Fotovoltaikanlage. Der vierte 1-Wire Bus war bisher über einen anderen Raspberry angeschlossen, auf dem OWFS lief - und ich habe ihn vom ersten Raspberry aus mit Owserver und meinen Frontendmodulen bedient.

Diesen zweiten Raspberry habe ich jetzt durch das neue Interface ersetzt - an meinem ersten Raspberry also 3x 1-Wire über USB und einmal über den neuen 1W-IF-ETH. Astrein stabil, keine Probleme.

LG

pah

pah: muss nicht zwingend ein Pullup mit rein?? Oder hat der DS2480B schon intern einen?
Kann eine Kompensationsschaltung für lange Strecken (~50m) negativ bei kurzen Strecken wirken? Sollte Sie dann auch gleich mit rein?
Es wäre trotzdem schön wenn du dir ein paar Minuten Zeit nehmen würdest und meinen Schaltplan (*.T3001) prüfen könntest.
UweH ist so nett und hilft mit beim Routen und der Anordnung...
Ich möchte die nächsten Tage/nächste Woche eine Samemlbestellung (DS2408 LED-Platine/DS2450 Umweltsensor) aufgeben und möchte gerne dieses Layout damit ebenfalls gleich mit abwickeln

Laut Datenblatt besorgt der DS2480 den "active pullup" selbst, das sollte also _nicht_ generell nötig sein. Ist auch z.B. im von Maxim vertriebenen DS9097U nicht drin. Ich habe bei Leitungslängen bis zu 20 m noch nie einen zusätzlichen Pullup benötigt.

Ebenfalls laut Datenblatt ist der Filter immer optional, hingegen wird die Schutzdiode immer empfohlen.

Mein Tipp also: Auf der Platine die Kontakte für den 62-Ohm-Widerstand des Filters etwas weiter führen, so dass sie ggf. durch einen Tupfer Lötzinn überbrückt werden können.

Ich melde mich hiermit für folgende Platinen an: 1x 1W-IF-ETH, 2 x DS2408, 4 x den "Umweltsensor".

LG

pah

Nachtrag: Ich habe T3001 nicht installiert, und bis zum 8. Februar auch keine Muße, das zu tun: Bin jetzt 2 Tage auf Akkreditierung, und hab ein der nächsten Woche die LEARNTEC zu leiten. Also im Moemnt leider keine weitergehende Überprüfung möglich.

LG

pah

UweH: habe deine Tips hoffentlich gut genug befolgt. Ich dinde die Stützkondensatoren sind nah genug am IC??
Die K2X07 passt jetzt auch vom Abstand. Genau 7mm vom Rand entfernt - dann müsste RJ45 genau mittig oben herausschauen.
Hier eine neue Version...

Du willst das Interface jetzt senkrecht auf Deine Platine stöpseln, sehe ich das richtig? Dazu müsste das Interface eine 90°-Stiftleiste haben.
Andere Variante: RJ45 nach unten raus. Dazu eine Hilfsplatine rechts oder links auf die Basisplatine senkrecht drauf und K1 sitzt auf dieser Hilfsplatine. Damit kannst Du auch die Schraublöcher im Interface benutzen.
Aber wie auch immer, auf der Platine sind noch ein paar Eier. Liste kommt per pm.

Ja, senkrecht nach oben. Habe dazu eine Buchsenleiste 8,5mm auf der PLatine, darauf eine 90Grad Buchsenleiste mit extra langen Pins. Damit passt es ganz genau bis oben das RJ45 3mm oben herausragt. Zusätzlich kann man die ETH Platine an der Seite  mit 4,8mm Platinenbefestigungen (Selbstklebend) besfestigen. Damit sollte die PLatine bombenfest sitzen.
Wer im Schaltschrank wenig Platz hat, es gibt abgewinkelte RJ45 Stecker...

Edit: UweH: Danke für die Änderung...  ist jetzt die Version 1.1 ;)

diese hier sehen baugleich aus... allerdings laut Aufschrift hat dieser 3 Serielle ausgänge
http://www.aliexpress.com/item/UART-ETH-E001-Cortex-M3-kernel-TCP-UDP-LWIP-protocol-UART-and-Ethernet-converter-connector-communication/1634696324.html

Dieser hier hat einen Seriellen Ausgang:
http://www.aliexpress.com/item/USR-TCP232-High-speed-Low-power-Stable-Ethernet-to-UART-convertor-connector-Module-Kit-with-Ethernet/1548854730.html

Ich werde mir einen Satz Bauteile (DS2480, DS9303, DS2401) für die Platine bestellen. Noch wer interesse?? Kann ich dann mit der Platine zusammen versenden an Interessenten ;)

klingt Gut Tobias, Kostenpunkt für die Komponenten?

Gruß
Jens

Zitat von: eldrik am 31 Januar 2014, 18:32:06
klingt Gut Tobias, Kostenpunkt für die Komponenten?

2x DS2401+
2x DS2480B+
2x DS9503P+
->  15,80 €

- Stiftleiste + gewinkelte Buchsenleiste mit langen Pins 7Polig
- 2x 100nF
- 2x 62k
-> 3€

Versand: 2,50€

Bei den Platinen gehe ich von 2€/Stück aus

Hallo Tobias,
Klingt super, dann bitte für mich zwei mal den Polenadapter + Platine + Bauteile wenn möglich. Dann brauche ich mich mit dem Arduino nano über RJ45 nicht mehr rumschlagen.

Bitte denkt dran das alles noch BetaStadium ist. Bei pah läuft es zwar schon gut stabil und bei Uwe warscheinlich auch... jedenfalls kommen keine Mails mehr hier an ;)
Ich weiß nicht ob es so gut ist den Thread hier als Bestellhotline zu missbrauchen ;)
Wenn möglich bitte per PM.
Den Polenadapter mach ich auch nur/erst wenn mindestens 10 zusammenkommen.

Läuft in der Tat stabil, ich freue mich jeden Tag darüber, dass ich einen RPi mit OWFS dafür herausgeworfen habe.

Ich habe noch vor, in das OWX Backendmodul etwas einzubauen, das ggf. das externe socat-Programm neu startet (sollte über die ReadyFn gehen). Dauert aber, weil ich im Moment etwas unter Wasser bin.

LG

pah

Zitat
Bei pah läuft es zwar schon gut stabil und bei Uwe warscheinlich auch... jedenfalls kommen keine Mails mehr hier an ;)

Stimmt...keine Mails -> alles gut ;-)

Zitat von: Prof. Dr. Peter Henning am 31 Januar 2014, 19:39:55
Ich habe noch vor, in das OWX Backendmodul etwas einzubauen, das ggf. das externe socat-Programm neu startet (sollte über die ReadyFn gehen). Dauert aber, weil ich im Moment etwas unter Wasser bin.

Ich persönlich würde einen externen Deamon mit watchdog bevorzugen weil ich bei mir die Kombination OWServer/OWxxx-Module fahre.

Nun ja, jedem das seine

LG

pah

Hallo,

habe mich sehr interessiert in die Diskussion eingelesen. Bin selbst noch ziemlich neu auf diesem Gebiet und suche mir gerade die notwendigen Teile zusammen. Dieser neue Adapter scheint ja sehr praktisch mit der zusätzlichen Erweiterungsplatine perfekt.

Kann man sich an die Sammelbestellung noch dranhängen? - Gibt es ggf. auch den polnische Adapter bzw. eine chinesische Alternative per Sammelbstellung? Das Porto aus Polen ist ja im Verhältnis ziemlich happig.

Gruß

Georg

Du kannst dich da noch reinhängen... Sammelbestellung zum Polenadapter möchte ich erst ab 10stück machen.
Ich habe mir heute eine chinesisches Fabrikat bestellt (knapp 24Euro), angeblich mit 3 möglichen UART-Ausgängen. Kommt in ca. 1,5monaten. Dann kann ich es testen

Das Porto von Kristech ist deshalb so hoch, weil sie aus Polen per UPS versenden. Das kostet aber wiederum für 10 Adapter genausoviel - nämlich 18 Euro.

LG

pah

Habe jetzt 9 Stück zusammen.
Jeder überlegt nochmal ob er einen benötigt und dann bestell ich...
Schließlich macht die Platine ohne den ETH-Adapter wenig Sinn....

Hallo Tobias,
Du hast sicher recht, ohne den ETH Adapter macht das nicht soviel Sinn. Bei Deiner Bestellung aus China, welches Modell hast Du denn genommen? Weiter oben sind ja schon diese zwei genannt.


http://www.aliexpress.com/item/UART-ETH-E001-Cortex-M3-kernel-TCP-UDP-LWIP-protocol-UART-and-Ethernet-converter-connector-communication/1634696324.html

http://www.aliexpress.com/item/USR-TCP232-High-speed-Low-power-Stable-Ethernet-to-UART-convertor-connector-Module-Kit-with-Ethernet/1548854730.html


Ist es einer von diesen?  Das erste Modell scheint ja baugleich zu sein. Da würde Deine Platine dann ja auch passen. Ich spiele mit dem Gedanken auch einen zu bestellen und bis dahin zum Testen einen DS9490R bei Fuchs zu bestellen.

Gruß

Georg

ist der erste Link. Zumindest ist der Connector nicht identisch belegt.
Du kannst natürlich auch gerne testen. Sobald ich die Platinen habe teste ich mit dem Polenadapter. Wenn die Chinavariante angekommen ist teste ich mit dieser und erweitere die Platine dementsprechend. Insbesondere um einen dritten 1wire-Kanal

Ok - vielen Dank! Ich werde mir den aus China auch bestellen. Bin also aus der Sammelbestellung (Platinen für den Kristech Adapter) erstmal raus. Wenn Du welche für diesen China Adapter machst wäre ich wieder dabei.

Nochmals Danke und Gruß

Georg

Zitat von: doit1910 am 04 Februar 2014, 12:29:44
Ok - vielen Dank! Ich werde mir den aus China auch bestellen. Bin also aus der Sammelbestellung (Platinen für den Kristech Adapter) erstmal raus. Wenn Du welche für diesen China Adapter machst wäre ich wieder dabei.

Dich hatte ich auch noch nicht vorgemerkt...
Aber Platinen für das ChinaTeil kann noch ne ganze Weile dauern.... Voraussetzung ist natürlich das er genauso reagiert wie der von Kristech

Hallo nochmal,

ich habe die China Variante bei ebay sogar für nur ca. 21 EUR gefunden...

http://www.ebay.com/itm/261385712912

Gruß

Georg

Zitat von: Tobias am 04 Februar 2014, 13:05:39
Aber Platinen für das ChinaTeil kann noch ne ganze Weile dauern.... Voraussetzung ist natürlich das er genauso reagiert wie der von Kristech

Ist schon klar, danke.

ich bin ein Fan des Mäusekinos im Schaltschrank und würde gerne eine 1wire Aktivitäts-LED einbauen.
Ich denke  mal das ich nicht einfach eine LED mit Vorwiderstsnd zwischen 1wireData und GND legen kann, sonst würde sie ja gleich 2 bzw 20ma aus dem Bus ziehen.
Ich denke da eher an eine Treiberstufe mittels Transistor um die Last auf die 5V Schiene zu legen.
Kann da wer helfen??
Mein eservice-online Buskoppler sowie der neue 1wire Repeater hat soetwas nämlich...

Hallo pah,

ich bekomme seit einem Restart folgende Meldung auf der Konsole, sobald der Aufruf "define ... OWX /dev/vmodem0" in der fhem.cfg abgearbeitet wird:
Use of uninitialized value $string_part in concatenation (.) or string at ./FHEM/00_OWX.pm line 1456, <$fh> line 47.
Use of uninitialized value $m in addition (+) at ./FHEM/00_OWX.pm line 1454, <$fh> line 47.
Use of uninitialized value $string_part in concatenation (.) or string at ./FHEM/00_OWX.pm line 1456, <$fh> line 47.


Dabei spielt es keine Rolle, ob ein Device angeschlossen ist. Diese Meldung läuft gefühlte 10.000 x und FHEM reagiert nicht.
Starte ich OWX mit angeschlossenem USB-Busmaster, läuft alles.
Was passiert da?

Zitat von: Tobias am 04 Februar 2014, 19:01:24
ich bin ein Fan des Mäusekinos im Schaltschrank und würde gerne eine 1wire Aktivitäts-LED einbauen.
Ich denke  mal das ich nicht einfach eine LED mit Vorwiderstsnd zwischen 1wireData und GND legen kann, sonst würde sie ja gleich 2 bzw 20ma aus dem Bus ziehen.
Ich denke da eher an eine Treiberstufe mittels Transistor um die Last auf die 5V Schiene zu legen.
Kann da wer helfen??
Mein eservice-online Buskoppler sowie der neue 1wire Repeater hat soetwas nämlich...

Schau mal im Datenblatt des FTDI FT232RL ... da sollten LED Ausgänge für RxD und TxD vorhanden sein.

VG
Ralf

Zitat von: dougie am 07 Februar 2014, 09:33:47
Schau mal im Datenblatt des FTDI FT232RL ... da sollten LED Ausgänge für RxD und TxD vorhanden sein.

Hmmm, sollte das so einfach sein? Da geht die LED auch nur einfach gegen VCC...
Sobald ich die erste Charge der Platinen habe teste ich das mal und bau das in Version 1.3 ein...

Hallo ,

bin neu hier, hört sich interessant an, würde auch einen Adapter nehmen, wenn noch möglich?

Gruß
Peter

Hallo,

Was halrtet Ihr von dieser Variante hier?

http://www.aliexpress.com/store/product/Free-Shipping-serial-TTL-RS232-to-802-11-b-g-n-converter-Embedded-WiFi-Module/908764_659755905.html

Gruß Andreas

Sieht gut aus ...

Nehme ich sofort. Wenn noch jemand mitmacht, gibt es 5$ Erstebestellerrabatt.

LG

pah

hab ich auch gesehen, auch eine andere Variante mit WIFI, aber bzgl Stabilität halte ich von WIFI nichts... für diese Anwendungen würde ich immer eine kabelgebundene Variante (LAN) bevorzugen.
Deswegen hab ichs auch nicht verlinkt bzw bestellt

Pardon, aber das ist sicher nicht richtig. Nicht "Wifi" gibt die Sicherheit - sondern die darüber gefahrenen Protokolle. Und die sind weit besser, als alle sonstigen Protokolle (wie z.B. BidCos).

Ich habe mir das Teil jedenfalls mal bestellt und werde es testen.

LG

pah

Hallo pah
Ich bin gespannt auf die testergebnisse.
Meine bedenkwn sind nur bzgl der connectivitat. Funktion ein automatischer reconnect?? Wlan kann auch mal kurzzeitig ausfallen. Das muss alles noch getestet werden. Diese Probleme sind bei LAN nicht so ausgeprägt

Hi pah,
womit stellst du die 3.3V für das wlan-Teil bereit? Mit einem "LM 2574 N3,3" ? Hat den Vorteil das dieser Input von 5V bis 40V
annimmt... Sobald du einen (Basis-)Schaltungsplan hast kannst du ihn hier einstellen??

Das Modul von Kristech kann sowohl mit 3,3 V, als auch mit 5V versorgt werden.

Schaltplan steht längst im Netz unter http://www.fhemwiki.de/wiki/1W-IF-ETH

LG

pah

Zitatwomit stellst du die 3.3V für das wlan-Teil bereit?

Du kannst diverse LM...-Varianten und Schaltregler benutzen...such mal bei Reichelt nach "Schaltregler" oder bei ebay nach "DC-DC Konverter". Die DC-DC Konverter gibt's komplett von unterschiedlichen Händlern, die Ausgangsspannung ist einstellbar. Die Schaltregler brauchen noch ein bisschen Peripherie, siehe Anhang (Auszug aus einem Schaltplan, +Batt wäre die Eingangsspannung).

Hi pah. Den Schaltplan kenne ich. Ich meine natürlich den Plan mit dem China wlan teil.
Uwe. Danke :)

Lieferung erst in 2 Wochen ...

LG

pah

So...dieses Teil hier: http://www.aliexpress.com/item/UART-ETH-E001-Cortex-M3-kernel-TCP-UDP-LWIP-protocol-UART-and-Ethernet-converter-connector-communication/1634696324.html (http://www.aliexpress.com/item/UART-ETH-E001-Cortex-M3-kernel-TCP-UDP-LWIP-protocol-UART-and-Ethernet-converter-connector-communication/1634696324.html), kommt übrigens letztlich von hier: http://www.wvshare.com/product/UART-ETH-E001.htm (http://www.wvshare.com/product/UART-ETH-E001.htm) und läuft seit einer Stunde fehlerfrei.
Der Gerätt  benahm sich zwar bei der Konfiguration etwas störrisch (DHCP scheint er irgendwie nicht zu mögen, eine feste IP hat er geschluckt...), aber dann ging es. Halb so teuer wie der Kristech (mit den Versandkosten) und ein paar Millimeter schmaler, so dass er in ein 2fach-Hutschienengehäuse passt.

Edit: Und ich weiß jetzt, wie das mit dem Reset auf Werkseinstellung funktioniert  ;) (falls es mal jemand wissen will...)

Mal sehen, wenn ich Sonntag wieder daheim bin werde ich mir auch eins bestellen. WLAN-Modul ist noch irgendwo zwischen China und hier unterwegs.

LG

pah

Da dürfte das WLAN-Modul dann aber schon angekommen sein... Ich hatte das UART ETH E001 am 31.01. bestellt und Freitag war's da. Das es auch schneller geht, beweist ein Platinenhersteller aus Shanghai, dessen Sendungen eine Laufzeit von 2 Tagen haben.

Ich sehe das immer mit einem lachenden und einem weinenden Auge, wenn die Hersteller aus China sich so in den europäischen Markt schieben....

Ich habe vor 2 Wochen eine Diskussion mit der EU-Kommissarin für Digitale Agenda Neelie Kroes geführt. Sie beklagte, dass wir Europäer die Hardware in Asien kaufen und die Software in den USA. Wir haben in bestimmten Bereichen aber die Chance, als Europa hier Boden gut zu machen.

LG

pah

Na zumindest Threema hat Boden gut gemacht...aber das ist ein anderes Thema...

Da nun der Kristech zwei serielle Ports und der ETH E001 gleich drei davon hat, möchte ich die natürlich auch ansprechen können.
Einfach im Startscript eine weitere socat-Instanz starten?

Derzeit ist das mit socat die einzige Möglichkeit. Ich denke darüber nach, dass direkt über einen Socket zu machen.

LG

pah

So funktioniert's aber erst mal. Eine zweite Instanz mit /dev/vmodem1 und es läuft. Was mir am Rande aufgefallen ist und was ich noch verifizieren muss...ich glaube, FHEM steigt aus, wenn die Netzwerkverbindung zum Interface weg ist.

Also definitiv...Netzwerkverbindung zum Interface kappen und FHEM schmiert sofort ab und erholt sich auch nicht bei wieder bestehender Verbindung.

Bei mir nicht - gibt nur Fehler aus. Welche Version von 00_OWX.pm ?

LG

pah

4348

Die Platinen sind jetzt da. Bin gerade dabei die einzelnen Platinen zu trennen, danach werde ich mal eine erste Testplatine aufbauen.

@UweH: Das ist aber nicht die aktuell veröffentlichte Version ...

LG

pah

Die Version bekommt man beim Update, auch wenn ich gezielt nur die OWX update. Wo gibt's die aktuellere Version?

Hm, im SVN steht m.E. eine aktuellere Version. Und zwar schon seit 9 Monaten.

Das chinesische Wifi-Teil ist da und werkelt vor sich hin. Morgen kommt ein DS2480 dran, dann wird sich zeigen, ob das klappt.

LG

pah

Zitatim SVN steht m.E. eine aktuellere Version. Und zwar schon seit 9 Monaten.

Da hab ich zuerst gesucht...:

Hm, das erfordert längeres Nachgraben - denn ich benutze natürlich eine gegenüber der Publizierten leicht veränderte Version. 

LG

pah

So, ich habe die ersten Schritte mit dem chinesischen WIFI-Modul

http://www.ebay.de/itm/380663884742?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649

getan. Die Doku ist zwar in schlechtem (chinesischem) Englisch verfasst, aber mit etwas Erfahrung und Fingerspitzengefühl habe ich das Ding jetzt im Netz. Der DS2480 Busmaster wird auch erkannt, allerdings muss ich noch etwas experimentieren, weil das Modul mit 3,3 V läuft.

Positiv: Das läuft mit allen möglichen Sicherheitsoptionen, kann auch selbst als Accesspoint definiert werden etc.

LG

pah

Hallo
sehe ich das richtig das man dann 1Wire Sensoren per Wifi anbinden kann.
Das hätte den Vorteil das man kein Kabel in den Heizungskeller ziehen müsste
dort dann die Wifi Box plazieren und mit einem 1wire Kabel weiter verteilen?

Würde das dann auch mit der Fritzbox funktionieren?
habe das Problem, das die nur 2 usb Ports hat und die sind nun voll.

Alternative wäre das mit dem Netzwerkkabel, auch da gibt es ja hier im Thread einen Lösungsvorschlag
.
Wenn mal Anfänger gesucht werden zum testen ...
um mal zu testen was Anfänger auf die Reihe kriegen...

Den FHEM duino hab ich ja auch hinbekommen, leider war die Reichweite schlecht.

Zitat von: Franz Tenbrock am 27 Februar 2014, 14:41:14
Hallo
sehe ich das richtig das man dann 1Wire Sensoren per Wifi anbinden kann.
Das hätte den Vorteil das man kein Kabel in den Heizungskeller ziehen müsste
dort dann die Wifi Box plazieren und mit einem 1wire Kabel weiter verteilen?

Korrekt...

Zitat von: Franz Tenbrock am 27 Februar 2014, 14:41:14
Würde das dann auch mit der Fritzbox funktionieren?
habe das Problem, das die nur 2 usb Ports hat und die sind nun voll.

Dann häng doch einfach einen USB Hub (vorzugsweise mit Spannungsversorgung) an die FritzBox...

sobald pah genur getestet hat gibt die nächste PlatinenVersion für das ChinaTeil. Sowohl die WIFI- als auch die LAN-Variante.

Die aktuelle PlatinenVErsion ist für die Kristeck LAN-Variante

Zitat von: Tobias am 27 Februar 2014, 14:53:52
sobald pah genur getestet hat gibt die nächste PlatinenVersion für das ChinaTeil. Sowohl die WIFI- als auch die LAN-Variante.

Die aktuelle PlatinenVErsion ist für die Kristeck LAN-Variante

Wie währe es denn das WiFi oder LAN Teil mit nem Umweltsensor zu verheiraten?

Also ein kleines "Tisch-Gehäuse" in dem dann folgende sachen Schlummern:
- WiFi/LAN to UART
- 2X DS2480 (1X für "Externe" Sensoren auf Klemme + 1X für "Interne" Sensoren)
- Temperatur (DS18B20)
- Luftfeuchtigkeit (HIH über DS2450)
- Helligkeit (Über DS2450)
- ...

Fänd das recht scharmant da ich bei mir Beispielsweise zwar in Jedem Raum LAN Kabel bzw. WiFi hab jedoch keine Möglichkeit ein Kabel für Sensoren zu legen...

Gestern ist das Chinateil gekommen, habe dann wegen dringend überfälliger Klausurkorrekturen nur wenig daran ausprobieren können. Heute etwas mehr Zeit investiert, und siehe da: Läuft auf Anhieb, ein echtes Schmuckstück...

Das erste Bild (etwas unscharf, aber das sei egal...) zeigt den etwas hastigen Aufbau, bestehend aus dem Chinateil, einem DS2480B und einem DS1820 zum Testen.

Von links kommen GND, 5V und 3,3V (leider verlangt das Teil nach 3,3V...)

Aus diesem Grund wird auch die Leitung für empfangene Daten (RxD) über einen Spannungsteiler 5,6 k/10k geführt - ich wollte lieber nicht ausprobieren, ob der RxD Eingang auch 5V verträgt. Der TxD-Ausgang wird direkt an den DS2480 geleitet (blaues Kabel).

Im zweiten bis fünften Bild ist die Konfiguration des Chinateils zu sehen. Ich habe es mit einer festen IP versehen, und in meinem WPA2-verschlüsselten Netz angemeldet, direkter Datentransfer ohne Kinkerlitzchen. Das Teil ist echt witzig, weil es ausgeliefert wird mit der Konfiguration als Access Point und chinesischer Oberfläche (Bild 2). Das lässt sich aber sofort beheben, so ein Glück...

Man muss sich dann mit dem eigenen Laptop bei diesem AP anmelden und die Konfiguration erst einmal auf Client umschießen (siehe 3. Bild), darf aber nicht vergessen, das auch ordentlich zu konfigurieren (4. Bild). Ich habe jedenfalls dreimal einen Reset auf die Factory Settings machen müssen, weil ich meine eigene Handschrift nicht lesen kann (Berufskrankheit...). Nach einem Neustart findet man dann den Client als Webserver im Netz (5. Bild).

Dann wie gehabt mit

socat -s PTY,link=/dev/owxwifi,raw,echo=0,waitslave TCP4:192.168.0.97:23

auf dem FHEM-Rechner bekannt machen, und mit

define OWXWIFI OWX /dev/owxwifi

in FHEM einbinden.

Astreine Lösung, bis auf einen Schönheitsfehler: Die 3,3V-Versorgung. Wahrscheinlich muss man so etwas verwenden: http://www.conrad.biz/ce/de/product/676218/1-W-DCDC-Wandler-Serie-RO-Recom-International-RO-0533S-In-5-VDC-Out-33-VDC-300-mA-1-W.

Eine Primitivlösung mit Zenerdiode halte ich für ungeeignet, weil das Ding immerhin ca. 200 mA verbrät - vielleicht hat jemand noch einen intelligenteren Wandler im Auge.

Laut der etwas wirren Doku lässt sich das Chinateil auch so konfigurieren, dass AP und WLAN Client parallel arbeiten.

Auch schön: Ethernet ist auf den Anschlussstecker geführt, es benötigt also nur eine RJ45-Buchse mit eingebautem Transformator, um es auch am Kabel zu betreiben. Weniger gut: Der Anschlusstecker hat 2mm Rastermaß - also habe ich einfach vier Drähte an das Teil angelötet, sieht man gut im ersten Bild.

Auch gut: Das Chinateil hat auch ein etwas intelligenteres Protokoll eingebaut, mit dem man ausfallsicher über WLAN kommunizieren kann. Könnte man ebenfall snutzen.

Schließlich würde ich gerne noch auf das eher dumme socat verzichten und die Teile direkt über einen TCP Socket ansprechen. Die Zeit habe ich derzeit aber nicht. Vielleicht baue ich einen Workaround, der bei Nichtverfügbarkeit des Interfaces eine Hilfsroutine aufruft, die per System-Call einen Neustart von socat macht.

Summa Summarum: Scharfes Teil. Ermöglicht die Ausweitung meines 1-Wire Netzes.

LG

pah

mal so interessehalber: wie verhält sich denn das socat (und damit das darauf zugreifende owx) wenn man die Gegenstelle kommentarlos vom Netz nimmt, resettet und wieder anklemmt?

Hallo Pah. Schau mal bitte in den Post Nr.82. D ist ein 3.3v schaltregler

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

@ntruchsess: socat läuft weiter - kann aber sein, dass irgendwann ein timeout kommt.
Bei OWX hängt es wohl davon ab, ob das gerade während eines Buszugriffs passiert. Muss man halt mal testen.

@Tobias: Äh - Post Nr. 82 in welchem Thread ?

LG

pah

@pah: Tobias meinte die 81 in diesen Thread, aber das war nur ein exemplarisches Beispiel, mit wie wenig Bauelementen ein Schaltregler auskommt, so dass man ihn direkt in die Schaltung integrieren könnte.

@Tobias: Allerdings ist das Layouten eines Schaltreglers eine Spezialität für sich. Da kann schon die "geografische" Lage eines Bauelementes über Sieg oder Niederlage entscheiden. Nicht umsonst veröffentlichen viele Schaltregler-Hersteller auch gleich Layout-Vorschläge im Datenblatt.
Insofern ist der Vorschlag von pah mit dem Fertigbauteil von Conrad die beste Variante.

@ntruchsess: Wie pah schon geschrieben hat, mit seiner OWX-Version funktioniert es. Mit der Version 4348, die ich mit dem LAN-Teil verwende, steigt FHEM sofort aus, wenn die Netzwerkverbindung zum LAN-Interface gekappt wird.

ntruchsess und ich basteln seit längerem an den OWX-Modulen herum.

Er hat dafür eine Version erstellt, die  auf die eigentlichen Devices asynchron zugreift und nicht auf die Rückgabe des relativ langsamen 1-Wire Bus wartet. Was am Anfang sehr einfach aussah, hat sich aber inzwischen zu einer sehr komplexen Sache entwickelt - mit eigenem Framework, das zumindest ich nicht ganz durchblicke.

Ich habe dafür das "alte" Backendmodul 00_OWX.pm stabilisiert und modernisiert, und die ganzen Frontendmodule (bis auf 21_OWLCD.pm) soweit umgestrickt, dass sie auch mit dem asynchronen Zweig laufen können.  Bei mir ist dieses "modernisierte" OWX im Einsatz, stabil seit Monaten.

Ich will keinen neuen Branch erzeugen, hänge also mal diese ausdrücklich experimentellen Versionen hier an.

LG

pah

Hm, auch diese OWX-Version läuft problemlos bis zu dem Moment, in dem ich dem LAN/1Wire-Interface den Stecker ziehe...es gibt zwar Unterschiede im Verhalten (Frontend ist weiterhin zu sehen, bisher war auch das komplett weg), aber FHEM ist auch nach erneuter Netzwerkverbindung mit dem Interface tot...

Das kann nicht sein. Schau Dir mal mit tail -f <logfile> in einer Shell das Logfile an. Es kann sein, dass FHEM versucht, das Interface zu reconnecten (bis zu 100x). Mit anderen Worten: Nicht tot, aber spielt nur noch an sich selbst herum. Eine Weile warten, dann kommt das wieder.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 27 Februar 2014, 17:03:49
Auch schön: Ethernet ist auf den Anschlussstecker geführt, es benötigt also nur eine RJ45-Buchse mit eingebautem Transformator, um es auch am Kabel zu betreiben. Weniger gut: Der Anschlusstecker hat 2mm Rastermaß - also habe ich einfach vier Drähte an das Teil angelötet, sieht man gut im ersten Bild.

Laut ChinaWebseite und einer Referenzschaltung ist als Transformator ein "hn1674og" Baustein verwendet. Leider lässt sich der so nicht finden. Hast du da etwas recherchieren können?
(http://i00.i.aliimg.com/img/pb/387/085/521/521085387_438.jpg)

Bzgl Spannungswandler finde ich, wenn schon RECOM, dann diesen hier besser: R-783.3-0.5 (http://de.mouser.com/ProductDetail/RECOM-Power/R-7833-05/?qs=sGAEpiMZZMt6Q9lZSPl3RQeydCnDOsgAiKvjcxTCmkY%3d)
Dann kann man das Teil mit 12V oder 5V betreiben...

Ethernet Trafo + RJ45 Buchse : http://www.mikrocontroller.net/topic/41735

Interessant dieser MagJack... auf http://www.csd-electronics.de/ gibts irgendwie 3 VErsionen aber ich seh keinen Unterschied, außer im Preis....

ZitatDas kann nicht sein. Schau Dir mal mit tail -f <logfile> in einer Shell das Logfile an. Es kann sein, dass FHEM versucht, das Interface zu reconnecten (bis zu 100x)

Ist aber offenbar doch so. Netzwerkstecker vom Interface raus, FHEM startet nach ein paar Sekunden mit reconnect zum zweiten Port, nach ein paar Sekunden Stecker wieder rein, FHEM versucht 5 min lang, die Verbindung wieder aufzubauen, bekommt dann auch keine Verbindung mehr zum ersten Port (trotz bestehender Netzwerkverbindung) und schmiert danach komplett ab.

.
.
.
2014.03.01 13:30:41 3: OWX_SER::Reset_2480 failure on bus Test_ETH_2
2014.03.01 13:30:45 1: Trying second reset
2014.03.01 13:30:47 3: OWX_SER::Reset_2480 failure on bus Test_ETH_2
2014.03.01 13:30:52 1: Trying second reset
2014.03.01 13:30:54 3: OWX_SER::Reset_2480 failure on bus Test_ETH
2014.03.01 13:30:56 1: Trying second reset
2014.03.01 13:30:58 3: OWX_SER::Reset_2480 failure on bus Test_ETH_2
2014.03.01 13:31:00 1: Trying second reset
2014.03.01 13:31:02 3: OWX_SER::Reset_2480 failure on bus Test_ETH
2014.03.01 13:31:02 1: OWX_SER::Search reset failed
2014.03.01 13:31:04 1: Trying second reset
2014.03.01 13:31:06 3: OWX_SER::Reset_2480 failure on bus Test_ETH
2014.03.01 13:31:12 1: Trying second reset
2014.03.01 13:31:14 3: OWX_SER::Reset_2480 failure on bus Test_ETH

Zum Thema Schaltregler, DC/DC-Konverter hab ich noch was Hübsches: http://www.conrad.biz/ce/de/product/158144/ (http://www.conrad.biz/ce/de/product/158144/)

@UweH: Na, dann lass den Netzwerkstecker doch einfach drin  8).

Spaß beiseite: Den Grund für den Totalabsturz habe ich bisher nicht gefunden

Ich denke, dass die Ecistenz dieser Netzwerkverbindungen durch einen externen Watchdog überprüft werden muss. Für den socat-Prozess habe ich das schon geschafft: Ein Skript in /etc/watchdog.d wird periodisch mit dem Parameter "test" aufgerufen. Liefert es keine 0 zurück (weil socat tot ist), startet der Watchdog-Dämon dasselbe Skript mit dem Parameter "repair".

Mal sehen, was ich sonst noch mit dem externen Watchdog anstellen kann. Allerdings geht meine freie Zeit dem Ende zu - in ein paar Tagen muss ich wieder voll in den Stress.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 01 März 2014, 19:07:10
@UweH: Na, dann lass den Netzwerkstecker doch einfach drin  8).

So ähnlich hat das meine Frau vorhin auch formuliert... ok, ich fass das Ding nicht mehr an  ::)

Zitat... voll in den Stress.

Igitt, Stress ist nicht gut für Körper und Geist. Hast Du nicht einen Assi, der das machen kann? So bleibt mehr Zeit für FHEM...

ein paar Fotos vom Testaufbau.
Es würde alles 100% perfekt machen wenn der ETH-Anschluss 3mm oberhalb des Gehäuses herausgucken würde. Aber nein: es fehlen ca 10mm. Also muss zwischen Hutschienen-Trägerplatine und Kristech-Adapter noch eine kleine Lochrasterplatine mit 2 Stiftleistenbuchsen rein..

 @UweH:

Also, FHEM stürzt dann, wenn 4x ein Search Reset Failure durch OWX_SER gemeldet wurde - weiter bin ich noch nicht. Ich habe aber ein nettes kleines Watchdog-Script, das steht im Verzeichnis  /etc/watchdog.d unter dem Namen owxwifi und enthält


#!/bin/sh
# description: watchdog helper file for owxwifi 

#echo "Called as owxwifi $1"
case "$1" in
'test')
        #--- Test for socat
        cnt=`ps -ef | grep "socat -s" | grep -v grep | wc -l`
        if [ "$cnt" -eq "0" ] ; then
                echo "owxwifi: socat not running, return 1 at "`date`
                exit 1
        else
                #echo "socat running, return 0"
                exit 0
        fi
        ;;
"repair")
        #-- Restarting socat
        echo "owxwifi: starting socat at "`date`
        socat -s PTY,link=/dev/owxwifi,raw,echo=0,waitslave TCP4:192.168.0.97:23 &
        sleep 2
        pty=`ls -l /dev/owxwifi | grep -oE '[^ ]+$'`
        chmod 666 $pty
        RETVAL=$?
        #echo "retval from setting permissions is $RETVAL"
        fhem=`ps -ef | grep "perl fhem.pl" | grep -v grep | wc -l`
        if [ "$fhem" -eq "0" ] ; then
                echo "owxwifi: starting fhem at "`date`
                /etc/init.d/fhem start
        else
                echo "owxwifi: fhem still running"
        fi
        exit 0
        ;;
*)
        exit 0
        ;;
esac


Mein Watchdog-Dämon läuft mit der Konfiguration


ping                    = 192.168.0.254
ping-count              = 5
interface               = wlan0
max-load-1              = 24
min-memory              = 1024
test-timeout            = 10
watchdog-device         = /dev/watchdog
interval                = 15
realtime                = yes
priority                = 1


Sorgt bei einem Verbindungsabbruch mit FHEM-Absturz zu einem Reboot mit autmatischem Reconnect. Dazu habe ich in eine Testversion von 00_OWX.pm noch eingebaut, dass es beim Hochfahren von FHEM bis zu 15 Sekunden auf das Device wartet - eben, um dem Watchdog-Dämon Gelegenheit zu geben, socat zu starten.

Funktioniert astrein - bisher wurde jeder Abbruch der WIFI-Verbindung aufgefangen.

LG

pah

Moin !

Wem es reicht nur einen 1w Bus anzusteuern (und nicht gleich zwei oder drei auf einmal), dem kann ich
folgenden Converter empfehlen:

http://www.ebay.de/itm/281140882484?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649

Kostet nur rund 12€ und funktioniert wunderbar. Er hat zwar kein Webinterface für die Konfiguration, wohl
aber ein (Kleinweich) Konfigurationsprogramm um die Config über Netz oder auch seriell einzustellen.

Die Privilegien für die PTS Devices sollten sich eigentlich über die /etc/default/devpts einstellen lassen.
Allerdings gibt es gemäß Bugliste in Debian ein Problem, so dass dies ignoriert wird  :( Entsprechend
bleibt wohl wirklich derzeit nur der Workaround über ein nachträgliches chmod ...

Gruß, Marc

Zitat von: Prof. Dr. Peter Henning am 02 März 2014, 12:35:19
Ich habe aber ein nettes kleines Watchdog-Script...

Danke, werde ich testen  :)

hab ich irgendetwas übersehen?
Der DS2480 wird erkannt, aber keine Devices.....

2014.03.03 20:03:26 3: Opening owx device /dev/vmodem0
2014.03.03 20:03:26 3: Setting owx baudrate to 9600
2014.03.03 20:03:26 3: owx device opened
2014.03.03 20:03:26 1: OWX: Serial device /dev/vmodem0 defined
2014.03.03 20:03:26 1: OWX: 1-Wire bus owx: interface master DS2480 detected for the first time
2014.03.03 20:03:26 1: Including ./log/fhem.save
2014.03.03 20:03:27 0: Server started with 62 defined entities (version $Id: fhem.pl 4769 2014-01-29 08:14:58Z rudolfkoenig $, os linux, user root, pid 30632)
2014.03.03 20:03:37 1: OWX: Search CRC failed
2014.03.03 20:03:37 1: OWX: 1-Wire devices found on bus owx ()


Zitat von: Tobias am 03 März 2014, 20:09:12
hab ich irgendetwas übersehen?

Ja, eine kalte Lötstelle  ;)

hmm, habe beide Ports probiert, Lötstellen kontrolliert. Keine Besserung. Habe das dumme Gefühl das am Layout etwas nicht passt.
Pah, hast du deine Platine schon aufgebaut? Funktioniert es bei dir?

Edit: Ich habe mal endlich ein Schaltungsbeispiel gefunden, ganz hinten im Datenblatt des DS2490.
Uwe, es sieht so aus als das du in deinem DS9503 Gehäuse Pin6 auf 1wireIn und Pin1 1WireOut gesetzt hast. In dem Beispiel vom DS2490 ist es aber anders herum.

Nein, ich habe im Moment keine Zeit, die Platinen zu bestücken.

Der Wechsel 1W out/in sollte beim DS 9503 nichts ausmachen.

LG

pah

Zitat von: Tobias am 04 März 2014, 09:23:19
Uwe, es sieht so aus als das du in deinem DS9503 Gehäuse Pin6 auf 1wireIn und Pin1 1WireOut gesetzt hast. In dem Beispiel vom DS2490 ist es aber anders herum.

Für mich ist in jedem Fall das Datenblatt des DS9503 entscheidend...und bei mir funktioniert's damit. Ich bin aber damals auf ein ähnliches Problem gestoßen und habe deswegen in eine funktionierende Schaltung reingeguckt, um die Pinbelegung zu verifizieren.
Was passiert denn, wenn Du den DS9503 rausnimmst und die Pads überbrückst?
Schick mir mal Deine Target-Datei, mir schwant da was...

@Tobias: Ein kurzer Blick ins Datenblatt des D9503 offeriert uns diese Schaltung :

Sag ich doch - und die Widerstände sind alle gleich groß, das Ding also symmetrisch verwendbar. Fehler muss woanders liegen.

LG

pah

Hi,
ich habe gestern die Pads eines DS9503 überbrückt, aber irgendwie hab ich das Teil nicht zum fliegen bekommen. Er hat nichtmal den DS2480 erkannt, weder den einen noch den anderen. Da es aber den Tag davor noch funktioniert hat muss es noch woanders dran liegen...
Hier mal die TargetDatei:

Ist der Kristech-Adapter richtig konfiguriert ?

LG

pah

Zitat von: Prof. Dr. Peter Henning am 05 März 2014, 07:12:12
Ist der Kristech-Adapter richtig konfiguriert ?

War meine erste Vermutung: habe 2 Einstellungen geändert die abweichend aus dem Wiki waren:
- auf 9600 Baud geändert
- auf RAW geändert

Leider keine Besserung

@Tobias: Vergleich mal Deine R1 und R2 mit meinen...  ::)

Das ist mir auf der Platine auch schon aufgefallen - dort steht 62K. Ich hatte allerdings nicht angenomen, dass jemand die Platine nach dem Aufdruck bestückt, statt nach dem veröffentlichten Schaltplan.

Also um die kryptische Bemerkung von UweH aufzulösen: Tobias, dort gehören 62 OHM hin - und nicht 62 KILOOHM.

LG

pah

verdammt.....  den Schaltplan auf der Wikiseite müsste noch durch eine Version 2 (mit DS9503) ergänzt werden...

Hallo Uwe,
kannst du mal bitte das von dir in Target3001 erstellte Bauteil DS9503 in eine CXF Datei exportieren und mir per pm schicken?

Hi,

ich habe jetzt die Platine und Komponenten von Tobias erhalten, da die 62kohm nicht die korrekten sind, sind die 62ohm zwingend zu bestücken? Funktionieren auch 100ohm?

Danke und Gruß
Jens

Also erst einmal: 100 Ohm sind hier kein Ersatz für 62 Ohm. Die Kombination von 62 Ohm/470 pF hat eine ganz bestimmte Zeitkonstante, wenn man die fast verdoppelt, werden die Signalflanken möglicherweise zu flach.

Allerdings, nur die Ruhe: Das RC-Tiefpassglied bestehend aus Widerstand 62 Ohm und 470 pF ist ausdrücklich OPTIONAL (und von Maxim nur dann empfohlen, wenn es OHNE nicht geht ...).

Ich habe bei mir im Haus groß Netzwerke, die störungsfrei OHNE arbeiten - das kommt sehr auf die Umgebung an.

Mein Tipp also: Erst einmal die 470 pF als Kondensator weglassen und den 62 Ohm-Widerstand durch eine Drahtbrücke ersetzen.

@Tobias: Das bedeutet auch, dass es Dir nicht geholfen hätte, wenn im Schaltplan der DS9503 drin wäre - denn diese Schutzdiode ist unabhängig von dem RC-Glied. Ich lasse übrigens auch oft (aus purer Faulheit...) die DS9503 Schutzdiode weg.

LG pah

Danke dir für die Erklärung. Gruss

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Hallo Tobias,
vielen Dank, heute alles gut angekommen. Meine 2 Eigenbauten laufen bisher auch ohne RC Glied und Schutzdiode. Aber wenn Du es schon mal so schön vorgesehen hast, die Apotheke mit dem blauen C verkauft direkt vor Ort gern paar 62 Ohm Widerstände. Gut das Du an der Stelle auf SMD verzichtet hast.

Klasse PAH, danke für die Erklärung, nun werden auch am ersten kristech beide ds2480 mit angehängten Geräten gefunden :)

Gruß
Jens

Verkauft jemand ein solches fertig gelötet für jemand,  der nicht löten kann?

Gesendet von meinem Xperia Pro mit Tapatalk

hat vl. noch jemand einen Tipp wie ich socat unter OS X 10.9 zum fliegen bekomme?

Ich habe mir einmal die neueste Version kompiliert und kann den Befehl

sudo socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:10.0.81.22:23

absetzen, erhalte jedoch nur folgendes Device

crw-rw-rw-  1 administrator  tty          16,   1 Mar  7 23:21 /dev/ttys001

/dev/vmodem wird mir nicht angezeigt und ich kann es somit nicht in fhem für OWX verwenden.

Auf meinem Rapsberry funktioniert die einzelnen Schritte ohne Probleme :/

Über Denkanstöße würde ich mich freuen.

Gruß
Jens

OS X ist Spielzeug, lernen wir daraus. Echte Männer nutzen Linux  8)

Offenbar kann die selbst compilierte Version keine Links anlegen (und ich habe auch keine Ahnung, ob das unter dem OS X-Dateisystem überhaupt geht). Macht aber gar nichts - selbstverständlich könnte OWX auch mit dem physikalischen Device /dev/ttys001 umgehen. Achtung: Dafür müssen noch die Schreibrechte gesetzt werden.

LG

pah

Scheinbar ist es noch ein anders gelagertes Problem unter OS X:

macmini:~ administrator$  sudo socat -d -d -d -s pty,link=/dev/vmodem0,raw,echo=0,wait-slave TCP4:10.0.81.22:23
Password:
2014/03/08 08:38:28 socat[13326] I socat by Gerhard Rieger - see www.dest-unreach.org
2014/03/08 08:38:28 socat[13326] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2014/03/08 08:38:28 socat[13326] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2014/03/08 08:38:28 socat[13326] I setting option "symbolic-link" to "/dev/vmodem0"
2014/03/08 08:38:28 socat[13326] I setting option "raw"
2014/03/08 08:38:28 socat[13326] I setting option "echo" to 0
2014/03/08 08:38:28 socat[13326] I setting option "pty-wait-slave" to 1
2014/03/08 08:38:28 socat[13326] I openpty({3}, {4}, {"/dev/ttys003"},,) -> 0
2014/03/08 08:38:28 socat[13326] N PTY is /dev/ttys003
2014/03/08 08:38:28 socat[13326] I close(4)
2014/03/08 08:38:28 socat[13326] N opening connection to LEN=16 AF=2 10.0.81.22:23
2014/03/08 08:38:28 socat[13326] I starting connect loop
2014/03/08 08:38:28 socat[13326] I socket(2, 1, 6) -> 4
2014/03/08 08:38:28 socat[13326] N successfully connected from local address LEN=16 AF=2 10.0.81.60:50869
2014/03/08 08:38:28 socat[13326] I resolved and opened all sock addresses
2014/03/08 08:38:28 socat[13326] N starting data transfer loop with FDs [3,3] and [4,4]
2014/03/08 08:38:28 socat[13326] N socket 1 (fd 3) is at EOF
2014/03/08 08:38:28 socat[13326] I shutdown(4, 1)
2014/03/08 08:38:28 socat[13326] N socket 1 (fd 3) is at EOF
2014/03/08 08:38:28 socat[13326] I shutdown(4, 1)
2014/03/08 08:38:28 socat[13326] I shutdown(4, 1): Socket is not connected
2014/03/08 08:38:28 socat[13326] N socket 2 (fd 4) is at EOF
2014/03/08 08:38:28 socat[13326] I close(3)
2014/03/08 08:38:28 socat[13326] I shutdown(4, 2)
2014/03/08 08:38:28 socat[13326] I shutdown(4, 2): Socket is not connected
2014/03/08 08:38:28 socat[13326] N exiting with status 0

socat bricht die Verbindung am Ende ab, nehme ich die option waitslave raus bricht socat nicht ab und der Link wird auch zusammen mit dem neuen ttys angelegt aber ist nicht nutzbar :/

Zumindest habe ich es auf dem Raspberry geschafft einen Kristech Port0 für OWX nutzbar zu machen und Port1 für OWServer :)

socat meldet ein EOF an einer der beiden Seiten und macht die Verbindung zu.

LG

pah

da muss man erst 4 Stunden holzhacken gehen, um dann nach 15 Minuten das gewünschte Ergebnis zu erzielen ;)

Ich möchte daher jetzt meine bisherigen Erfahrungen mit der Platine und der Einrichtung unter Mac OS X 10.9 teilen.

Zur Platine:
Ich verfüge nicht über eine SMD Ausrüstung, dennoch ließen sich die SMD Bauteile gut mit meinem 30Watt Lötkolben und 0,8mm Elektronik Lötdraht, bestücken, mangels 62Ohm Widerstand habe ich das vorgesehene Netzwerk erst einmal nicht bestückt und den Platz des Widerstandes überbrückt.

Ich habe festgestellt, dass die von Tobias mitgelieferte gewinkelte Stiftleiste, scheinbar manchmal keinen vollen Kontakt beim Modul erzeugt, weshalb bei mir ab und an kein DS2480 gefunden wurde, was natürlich Verwirrung stiftet :P ich habe daher das Kristech Modul direkt auf die gerade Stiftleiste gesteckt und werde mir noch eine Lösung für einen besseren Kontakt überlegen.

Zu Mac OS X:
Ich habe mir die letzte Version von socat unter

http://www.dest-unreach.org/socat/

heruntergeladen und nach folgender Anleitung kompiliert

http://www.xappsoftware.com/wordpress/2013/10/10/how-to-run-socat-on-mac-os-x/

Bei der Umsetzung des von PAH beschriebenen Befehls scheint socat unter OS X scheinbar einen anderen Weg gehen zu wollen, das weglassen von waitslave brachte hier den gewünschten Erfolg, hier sei noch erwähnt, dass alle die bisher nicht  sudo cpan Device::SerialPort, für ihre Installation, unter OS X benötigt haben, sollten dies nun nachholen, um OWX auch zum laufen zu bekommen (das war mit der Grund warum das erste, in diesem Thread, erwähnte weglassen von waitslave nicht gleich den wirklichen Erfolg vermuten ließ).

Ich verbinde auf meinem Mac nun die Kristech Ports mit dem folgenden Befehl beim FHEM start

sudo /usr/bin/socat -s PTY,link=/dev/vmodem0,raw,echo=0 TCP4:10.0.81.22:23 &
sudo /usr/bin/socat -s PTY,link=/dev/vmodem1,raw,echo=0 TCP4:10.0.81.22:26 &
sleep 1
sudo  chmod 666 /dev/vmodem*

Das Beenden erfolgt über den folgenden Befehl

sudo kill $(ps aux | grep '[s]ocat' | awk '{print $2}')

OWX und OWServer:

Beide lassen sich mit socat nutzen, so dass ich derzeit zu Testzwecken einen Port mit OWX und div. 1Wire Geräten laufen lasse und den zweiten Port mit OWServer, bei OWServer sehe ich derzeit den Vorteil, dass in der jetzigen Version bereits der Verbindungsverlust zum Adapter FHEM nicht in die ewigen Jagdgründe schicken sollte, zumindest war dies bei meinem vergangenen Aufbau, mit einem Raspberry (ohne Kristech), der Fall, diese Tests stehen aber noch aus!

Gruß
Jens

Hi !

Generell funktioniert mein Setup (derzeit nur auf dem Breadboard) recht gut und stabil. Allerdings
schlägt der erste Reset des DS2480B mal sporadisch, mal häufiger fehl.

Trying second reset

Query_2480 liefert in diesen Fällen 0 statt 192. Hatte jemand schon einmal ein ähnliches Problem ?
Der zweite Reset funktioniert dann im Regelfall.

Ich nutze das von pah in diesem Thread bereitgestellte OWX Modul.

Gruß, Marc

vermutlich muss man mit sowas leben, da das Timing zwischen dem OWX und dem DS2480 wegen der Netzwerkanbindung nicht mehr stabil ist. OWX hat ja keinen Einfluss darauf, wann die Netzwerkpackete tatsächlich rausgehen (und ankommen). Leider kann man dem DS2480 nicht einfach die komplette Bytefolge (reset + Geräteauswahl + Kommando) in einem Rutsch schicken, der ist darauf angewiesen, dass der Sender die Kommandos jeweils zur richtigen Zeit schickt.

Seit gestern sind alle bestellten Platinen raus (bis auf A.Bauer). Ihr solltet also Eure Teile spätestens heute in der Hand halten können.
Für alle die beim Löten Probleme haben, auf der Zeichnung unten seht Ihr wo die jeweiligen Pin1 liegen ;)

Für alle anderen: ich habe hier noch Platinen. Wer welche haben möchte: PM an mich.

Hi,

folgendes ist mir bisher bei der Verwendung des Interfaces (RC-Glied ist auch vorhanden) mit OWX und OWServer aufgefallen,

OWServer:

bei Verwendung von socat in Verbindung mit OWServer (nonblocking aus) wird fhem quasi ausgebremst, es entstehen waits von bis zu 30 Sek. (gemessen mit Perfmon), mit aktiven nonblocking belaufen sich die waits immer noch auf bis zu 20 sek. ich habe an diesem Bus derzeit folgende Sensoren hängen
4 x DS1820B mit 60 sek Abfrageintervall
3 x DS2413 mit 300 sek Abfrageinterval
2x DS2408 mit 1 sek Abfrageintervall
2x DS2450 mit 120 sek Abfrageintervall
1x DS2423 (Dougiecounter) Abfrageintervall 300 sek

Ich weiß nicht ob es an dem FHEM Modul oder vl. bereits an der Basis, dem OS OWServer liegt, kann ich irgendetwas zu beisteuern, um dies näher beleuchten zu können?

Mit dem bisherigen Konstrukt (Bus + Abfrageintervall + OWServer) in Verbindung mit einem Raspberry und der 1Wire Huckepackplatine von Uwe per I2C Interface habe ich diese Probleme nicht.

OWX:

Bei Verwendung von socat in Verbindung mit OWX scheint es diese Probleme nicht zu geben (Version die über FHEM ausgeliefert wird), FHEM reagiert normal und die Sensoren werden auch soweit zuverlässig abgefragt (speziell die 1 Sek Intervalle).

Ich müsste mein jetziges Setup komplett auf OWX umbauen, um zu schauen ob das Gesamtkonstrukt (at, notifys, Reaktionszeiten etc.) stabil läuft, das wird noch eine Weile dauern.

Gruß
Jens

wenn du OWServer verwenden möchtest wäre es als erstes wichtig genau zu schauen wo die verzögerung her kommt.

OWServer arbeitet prinzipiell synchron und blockierend. auch mit nonblocking. damit wird nur verhindert das fhem komplett stehen bleibt wenn die owfs abfrage blockiert. OWServer wirklich asynchron zu machen habe ich zwar immer noch vor aber das ist eine ziemlich umstellung weil OWDevice nicht darauf vorberietet ist das die antworten asynchron kommen.

aber zurück zu deinen verzögerungen: in der aktuellen version ist das eigentlich können mit nonblocking keine 20 sekunden auf einen schlag mehr zusammenkommen. das select wartet 4 sekunden und der internal timer der den geforkten prozess killt  6 sekunden. d.h. nach 4 sekunden kommt jedes read ohne ergebnis zurück und den 6 sekunden siehst du im log das etwas gekillt wurde. wenn das nicht so ist stimmt noch irgend etwas anderes nicht. wenn wirklich das reine lesen 20 sekunden dauert würde OWDevice im nonblocking fall keine werte mehr bekommen und du hast im log 'OWServer: read timeout for child ...'. meldungen.

in OWDevice gibt es in OWDevice_ReadValue ein paar auskommentierte zeilen (drei mal 'my ...' und ein mal 'Debug ...' um genau zu loggen wie lange im read gewartet wurde. dort siehst du dann auch ob tatsächlich ein wert gelesen wurde.

das betrifft alles die eigentliche abfrage einzelner readings zur laufzeit. während dem start und der initialisierung kann es durchaus noch zu längeren wartezeiten kommen.

steht in NR_READ_FAILED oder LAST_READ_FAILED etwas (natürlich nur im nonblocking fall) ?

hast du mal direkt mit owhttp geschaut wie lange es dort dauert einzelne werte auszulesen?

siehst du im log mehr wenn du für das OWServer device verbose auf 5 setzt ?

ich hab (noch) kein solches interface und kann leider nicht selber schauen was es ist. aber wenn du versuchst für mich etwas zu debuggen versuche ich gerne etwas rauszufinden.

gruss
  andre

wenn ich wieder zu Hause bin werde ich die entsprechenden Zeilen auskommentieren und kann dir das Log dann gerne zukommen lassen.

Den anderen Anregungen werde ich auch nachgehen.

Danke und Gruß
Jens

Hallo Tobias !

Zitat von: Tobias am 04 Februar 2014, 13:05:39
Aber Platinen für das ChinaTeil kann noch ne ganze Weile dauern.... Voraussetzung ist natürlich das er genauso reagiert wie der von Kristech

Wenn Du wirklich noch eine Platinenvariante für das ChinaTeil (LAN) planen solltest, fände ich es super, wenn auf der Platine noch ein DC/DC Wandler  vorgesehen werden könnte, damit man das ganze auch direkt mit höheren Spannungen als 5V  versorgen kann. Könnte man ja - wenn nicht benötigt - überbrücken. Ich habe z.B. nur 12V im Schaltschrank, und das schöne aufgeräumte Modul dann noch mit einer zusätzlichen Lochrasterplatine zu verschandeln, wäre suboptimal. Ich habe bisher sehr gute Erfahrungen mit LC78 Serie von GAPTEC gemacht.

Gruß, Marc 

Werde es mir merken. Ich benutze hier Tracepower den TGS 1-2450. Geht von 7-36V

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Ich habe jetzt einen sehr schönen Wandler 5V -> 3,3 V mit dabei, die Sache läuft wunderbar stabil. Plan poste ich demnächst.

LG

pah

@pah: Wie lange hat bei Dir das rebooten des WiFi-Moduls nach dem Ändern der Einstellungen gedauert? Der rödelt hier schon eine gefühlte Ewigkeit...  >:(

10 Sekunden.

LG

pah

Dann mache ich was falsch. Ich krieg das Teil nicht zu fassen. Entweder konfiguriere ich ihn falsch (aber nach Deinen Bildern und denen der Anleitung "eigentlich" nicht) oder ich bin zu dämlich, das Ding im WLAN zu finden (wahrscheinlicher...).

Hallo,
bin neu hier und brauche Hilfe bei der Installation von der Platine von Tobias (Kristech)

Hab jetzt schon wieder eine Nacht hinter mir und bekomme es nicht zum laufen. Fhem hängt sich immer auf, das log kommt bis hier hin.
Das vmodem1 ist dann auch auf der RPI - Konsole weg. Eigentlich macht er alles richtig, erkennt noch die zwei Temp - Fühler dann ende. Hoffe es kann jemand helfen...danke

2014.03.21 23:27:12 1: Including fhem.cfg
2014.03.21 23:27:14 1: OWX: Serial device /dev/vmodem1 defined
2014.03.21 23:27:16 1: OWX: 1-Wire bus Modem1: interface master DS2480 detected for the first time
2014.03.21 23:27:20 1: Including ./log/fhem.save
2014.03.21 23:27:20 1: usb create starting
2014.03.21 23:27:48 1: usb create end
2014.03.21 23:27:55 0: Server started with 38 defined entities (version $Id: fhem.pl 5197 2014-03-10 21:07:30Z rudolfkoenig $
2014.03.21 23:27:59 1: OWX: 1-Wire devices found on bus Modem1 (OWX_28_03E8C3040000,OWX_28_E3F03F050000,OWX_01_DE16C6160000)

Nachtrag.. nach einem erneuten Start (reboot RPI) folgender Log
2014.03.21 23:49:16 1: Including fhem.cfg
2014.03.21 23:49:18 1: OWX: Serial device /dev/vmodem1 defined
2014.03.21 23:49:22 1: OWX: 1-Wire bus Modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.21 23:49:47 1: OWX: 1-Wire bus Modem1: interface not found, answer was 0x16 0x44 0x5a 0x00

das geht immer so , mal erkennt fhem mehr mal weniger !!!

Hi Peter,

Bilder vom Aufbau?

Verwendest du die 90 Grad gewinkelte Stiftleiste von Tobias?

Hast du eine stabile Netzwerkverbindung zwischen Kristech und dem Rpi?

Greetz
Eldrik

Hi Eldrik,
ja ich habe die Version 90 Grad, wobei ich noch ohne den Winkel direkt aufgesteckt habe, also gute Verbindung. Das Netzwerk ist stabil und konnte ohne Probleme installiert werden, feste IP, 9600 usw., alles in Ordnung ...(denke ich).
Die Platine habe ich mit und ohne RC - Glied versucht zum laufen zu bringen, ohne Erfolg. Habe auch schon verschiedene Stromquellen 5 Volt , 6 Volt versucht und hier schon Unterschiede bemerkt, was das Log betrifft ,  könnte es daran evtl. liegen ?, Zur Zeit habe ich den USB angezapft 5 Volt, bzw. wenn er angeschlossen ist habe ich noch 4,8 Volt  für die Platine ? keine Ahnung ob das eine Fehlerquelle sein kann. Habe mir dann auch noch die von pah eigenen OWX heruntergeladen leider auch kein Erfolg.

dann kann man die Winkelleiste schon einmal ausschließen wenn du das Modul derzeit noch direkt aufgesteckt hast, wichtig ist auf jeden Fall eine stabile Stromversorgung, ob dies bei dir bereits ausschlaggebend ist kann ich leider nicht beurteilen, sorry.

Greetz
Eldrik

Hallo,
ja das mit der Stromversorgung kann ich eben auch nicht beurteilen. Aber ich habe eine Regelmäßigkeit feststellen können. Immer nach Stromlos der Modulplatine geht das Log bis zu diesem Punkt, und würgt dann FHEM ab, gleichzeitig ist auch vmodem1 weg. FHEM erkennt also noch die Fühler ! Kann es sein dass Schreibrechte für OWX benötigt werden und nicht da sind ?

2014.03.21 23:27:12 1: Including fhem.cfg
2014.03.21 23:27:14 1: OWX: Serial device /dev/vmodem1 defined
2014.03.21 23:27:16 1: OWX: 1-Wire bus Modem1: interface master DS2480 detected for the first time
2014.03.21 23:27:20 1: Including ./log/fhem.save
2014.03.21 23:27:20 1: usb create starting
2014.03.21 23:27:48 1: usb create end
2014.03.21 23:27:55 0: Server started with 38 defined entities (version $Id: fhem.pl 5197 2014-03-10 21:07:30Z rudolfkoenig $
2014.03.21 23:27:59 1: OWX: 1-Wire devices found on bus Modem1  OWX_28_03E8C3040000,OWX_28_E3F03F050000,OWX_01_DE16C6160000)

Hier noch das Setup von Start  FHEM
case "$1" in
'start')

socat -s PTY,link=/dev/vmodem1,raw,echo=0,waitslave TCP4:192.168.1.120:26 &
sleep 2
pty=`ls -l /dev/vmodem1 | grep -oE '[^ ]+$'`

chmod 666 $pty

Vielleicht ist ja hier der Fehler versteckt, Schreibrecht ?

Gruß und danke schon mal für Deine Hilfte

Nein, das ist mit Sicherheit nicht der Grund, und wir sind auch nicht beim lustigen Ursachenraten.

Aus der Tatsache, dass OWX den DS2480 erkennt und die Devices findet, ist zu folgern dass die ganze Sache im Prinzip richtig konfiguriert ist - allerdings dann etwas zusammenbricht. Entweder Netzwerkverbindung, oder Spannungsversorgung.

Bitte mal Folgendes versuchen:

1. RPi starten, aber FHEM noch nicht.

2. Auf die Adresse des Kristech-Adapters einen Ping setzen, und mitlaufen lassen (in einem separaten Konsolenfenster)

3. Jetzt FHEM (und damit auch socat) starten. Während OWX den DS2480 erkennt und danach den 1-Wire-Bus abfragt, sollten (vielleicht) ein paar Verzögerungen in den Ping-Echos zu sehen sein. Sobald die Devices gefunden wurden, bitte in FHEM ein "get Modem1 devices" absetzen, und danach "get OWX_28_03E8C3040000 temperature".

Und beobachten, was mit den Pings passiert.

LG

pah

Ich habe folgendes gemacht
1. Auf SD ein kpl. neues System RPI und FHEM installiert, kein  Interface dran.
2. Ping gestartet  zwischen 0,56 und 0,66 ms  stabil,  egal was FHEM gemacht hat.
3. Die Virtuellen Modem gestartet Ping immer gleich
3. Fhem  gestartet und die die Modem per Device eingebunden, nach dem sichern werden die Modems unter OWX erkannt.
4. Zwei Fühler werden unter OWTHERM dargestellt, leider nur bei einen Fühler die Temperatur, welche leider nicht mehr aktualisiert wird.
5. Der Befehl get Modem1 devices wird ohne Fehler aufgeführt, die beiden Devices und das Modem werden erkannt und gelistet.
6. Beim  Befehl  "get OWX_28_03E8C3040000 temperature" bricht FHEM zusammen, ein Neustart auf der RPI Konsole klappt zwar, aber es werde Fehler Zeilen ausgegeben mit Verweis 00_OWX Modul,  per WEB startet FHEM nicht mehr, nur ein reboot startet Fhem wieder. 
7. OWX wird nicht mehr erkannt, ich müsste das Device der virtuellen MODEM rausnehmen, fhem neustarten, die Device Modem wieder setzen und sichern, dann würden SIe wieder unter OWX erkannt werden, leider die Probleme mit dem Fühler.

Hat noch jemand eine Idee, ansonsten werde ich das Teil auf Eis legen und mit anderen Interfaces arbeiten, habe leider zu wenig Fachwissen um dieses ETH am stabilen laufen zu halten.

Gruß und Danke noch mal für Eure Hilfe

Welche Fehler mit Hinwei sauf OWX werden ausgegeben ?

Was bedeutet "per WEB startet FHEM nicht mehr"  - ein Start über das Web ist nirgendwo vorgesehen ?

Was bedeutet "OWX wird nicht mehr erkannt"  - das Modul wird doch wohl gefunden ?

Auch ist mir nicht klar, was mit "Device Modem wieder setzen" gemeint sein soll. Wie wird denn socat gestartet ?

LG

pah

zu Was bedeutet "per WEB startet FHEM nicht mehr"  - ein Start über das Web ist nirgendwo vorgesehen ?
Wenn "FHEM STATUS" unter putty aufgerufen wird kommt "fhem running und die Fehlerzeilen", aber die URL kann nicht mehr angezeigt werden bei mir 192.168.1.3:8083

zu Was bedeutet "OWX wird nicht mehr erkannt"  - das Modul wird doch wohl gefunden ?
Durch einen Reboot vom RPI starten socat ordentlich, die vmodem0 und vmodem1 werden angezeigt( ls -l /dev/vmodem1),

pi@raspberrypi ~ $ sudo ls -l /dev/vmodem1
lrwxrwxrwx 1 root root 10 Mar 25 07:17 /dev/vmodem1 -> /dev/pts/3
pi@raspberrypi ~ $ sudo ls -l /dev/vmodem0
lrwxrwxrwx 1 root root 10 Mar 25 07:17 /dev/vmodem0 -> /dev/pts/4


trotzdem kann die URL 192.168.1.3:8083 nicht angezeigt werden, der Grund ist der Device Eintrag in der fhem.cfg   Device Modem1 OWX /dev/vmodem0, erst nach löschen dieser Zeile und reboot RPI  wird die URL /fhem wieder angezeigt.

zu socat Start
socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.1.120:23 &
socat -s PTY,link=/dev/vmodem1,raw,echo=0,waitslave TCP4:192.168.1.120:26 &

sleep 2
pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
pty1=`ls -l /dev/vmodem1 | grep -oE '[^ ]+$'`

chmod 666 $pty
chmod 666 $pty1

Hier ein aktueller Ablauf

log
2014.03.25 20:15:25 1: Including fhem.cfg
2014.03.25 20:15:27 3: telnetPort: port 7072 opened
2014.03.25 20:15:28 3: WEB: port 8083 opened
2014.03.25 20:15:28 3: WEBphone: port 8084 opened
2014.03.25 20:15:28 3: WEBtablet: port 8085 opened
2014.03.25 20:15:29 2: eventTypes: loaded 25 events from ./log/eventTypes.txt
2014.03.25 20:15:30 3: Opening modem0 device /dev/vmodem0
2014.03.25 20:15:30 3: Setting modem0 baudrate to 9600
2014.03.25 20:15:30 3: modem0 device opened
2014.03.25 20:15:30 1: OWX: Serial device /dev/vmodem0 defined
2014.03.25 20:15:30 3: Opening modem1 device /dev/vmodem1
2014.03.25 20:15:30 3: Setting modem1 baudrate to 9600
2014.03.25 20:15:30 3: modem1 device opened
2014.03.25 20:15:30 1: OWX: Serial device /dev/vmodem1 defined
2014.03.25 20:15:30 1: configfile: 0
0
2014.03.25 20:15:30 1: Including ./log/fhem.save
2014.03.25 20:15:30 1: statefile: Please define OWX_01_6C75C6160000 first
Please define OWX_01_DE16C6160000 first
2014.03.25 20:15:31 1: OWX: 1-Wire bus modem0: interface master DS2480 detected for the first time
2014.03.25 20:15:31 1: OWX: 1-Wire bus modem1: interface master DS2480 detected for the first time
2014.03.25 20:15:31 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.03.25 20:15:31 0: Server started with 10 defined entities (version $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $, os linux, user fhem, pid 2014)
2014.03.25 20:16:02 3: OWID: Device OWX_01_6C75C6160000 defined.
2014.03.25 20:16:02 1: OWX: 1-Wire devices found on bus modem0 (OWX_01_6C75C6160000)
2014.03.25 20:16:04 3: OWID: Device OWX_01_DE16C6160000 defined.
2014.03.25 20:16:04 1: OWX: 1-Wire devices found on bus modem1 (OWX_01_DE16C6160000)

jetzt schließe ich die Fühler an und gebe get modem1 devices folgende Ausgabe und alles ok
OWX: 1-Wire devices found on bus modem1
01.DE16C6160000      unknown    OWX_01_DE16C6160000
28.03E8C3040000      DS18B20    OWX_28_03E8C3040000
28.E3F03F050000      DS18B20    OWX_28_E3F03F050000

klickt man jetzt irgend einen Butten stürzt fhem ab
Ups! Google Chrome konnte keine Verbindung zu 192.168.1.13:8083 herstellen.

Log danach
2014.03.25 20:15:31 0: Server started with 10 defined entities (version $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $, os linux, user fhem, pid 2014)
2014.03.25 20:16:02 3: OWID: Device OWX_01_6C75C6160000 defined.
2014.03.25 20:16:02 1: OWX: 1-Wire devices found on bus modem0 (OWX_01_6C75C6160000)
2014.03.25 20:16:04 3: OWID: Device OWX_01_DE16C6160000 defined.
2014.03.25 20:16:04 1: OWX: 1-Wire devices found on bus modem1 (OWX_01_DE16C6160000)
2014.03.25 20:19:27 3: OWTHERM: Device OWX_28_03E8C3040000 defined.
2014.03.25 20:19:27 3: OWTHERM: Device OWX_28_E3F03F050000 defined.
2014.03.25 20:19:27 1: OWX: 1-Wire devices found on bus modem1 (OWX_01_DE16C6160000,OWX_28_03E8C3040000,OWX_28_E3F03F050000)

Reboot RPI
pi@raspberrypi ~ $ sudo /etc/init.d/fhem status
fhem is running
pi@raspberrypi ~ $

Leider kann ich FHEM nicht mehr aufrufen (url) folgendes LOG

2014.03.25 20:25:03 1: Including fhem.cfg
2014.03.25 20:25:04 3: telnetPort: port 7072 opened
2014.03.25 20:25:05 3: WEB: port 8083 opened
2014.03.25 20:25:05 3: WEBphone: port 8084 opened
2014.03.25 20:25:05 3: WEBtablet: port 8085 opened
2014.03.25 20:25:06 2: eventTypes: loaded 25 events from ./log/eventTypes.txt
2014.03.25 20:25:07 3: Opening modem0 device /dev/vmodem0
2014.03.25 20:25:07 3: Setting modem0 baudrate to 9600
2014.03.25 20:25:07 3: modem0 device opened
2014.03.25 20:25:07 1: OWX: Serial device /dev/vmodem0 defined
2014.03.25 20:25:07 3: Opening modem1 device /dev/vmodem1
2014.03.25 20:25:07 3: Setting modem1 baudrate to 9600
2014.03.25 20:25:07 3: modem1 device opened
2014.03.25 20:25:07 1: OWX: Serial device /dev/vmodem1 defined
2014.03.25 20:25:07 1: configfile: 0
0
2014.03.25 20:25:07 1: Including ./log/fhem.save
2014.03.25 20:25:07 1: statefile: Please define OWX_01_6C75C6160000 first
Please define OWX_01_DE16C6160000 first
2014.03.25 20:25:08 1: OWX: 1-Wire bus modem0: interface master DS2480 detected for the first time
2014.03.25 20:25:12 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:15 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:44 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:47 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:50 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:53 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:55 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:25:58 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00
2014.03.25 20:26:00 1: OWX: 1-Wire bus modem1: interface not found, answer was 0x16 0x44 0x5a 0x00

das alles ist immer das gleiche Spiel, und es kommt erst dann wenn die Fühler mit OWTHERM ins Spiel kommen.

Ich habe hier noch 3 Kristech ETH Module und noch für 2 Platinen Bausätze sowie 1 fertig bestückte Platine. Die 2 nackten Platinen kann ich zur Not auch noch bestücken.
Nackte Platinen sind noch 13 vorrätig. Also 3 einsatzfähige Module.... wer zuerst kommt ..... ;)

Von einem Absturz von FHEM kann ich nichts sehen.

Lediglich davon, dass das Web-Frontend für eine ganze Weile nicht mehr erreichbar ist. Das deutet auf irgendein Bus-Problem hin - FHEM wird dann immer wieder versuchen, eine Antwort vom Busmaster zu bekommen. Darauf deutet auch der Vorgang nach dem Reboot, denn hier meldet sich der Busmaster nicht korrekt.

Erster Tipp: Nicht rebooten, sondern im Höchstfall (!) den FHEM-Prozess abschießen.
Zweiter Tipp: Verkabelung und Anschluss derselben an den Busmaster sowie Spannungsversorgung überprüfen.

LG

pah

zu Absturz
Ich dachte da das Web-Frontend  nicht mehr reagiert fhem ist tot, werde mal länger warten und beobachten was passiert.

zu Verkabelung 1-wire
Hab da auch alle Versionen durch
VDD + GND auf Platine ->GND
Data auf Platine ->1-wire
oder
GND auf Platine ->GND
VDD auf Platine -> 5 volt
Data auf Platine ->1-wire

zu Spannungsversorgung
bei dem letzten Test hatte ich vom RASPI  (Pin 1+6) die Spannung für das Modul bezogen, 1200 MA sollte doch passen, auser dem Modul hing nichts dran. Hatte auch schon 5 Volt 2000ma direkt an der Platine.

Wie schieße ich fhem ab ?  (sudo /etc/init.d/fhem stop) 

Danke pah

Aktueller Stand
- Fühler DS1820B abgebaut von der Platine
- Sensor  DS2406 (D2P Fuchs-Shop) an das Modul ETH angeschlossen, und siehe an sofort erkannt, A+ B lasen richtig schalten.
aber dann...

- Sensor  DS2406 abgebaut und Fühler DS1820B angeschlossen
- Mit  get Modem1 decices wird der Fühler noch aufgelistet dann kommt sofort
  Ups! Google Chrome konnte keine Verbindung zu 192.168.1.13:8083 herstellen.

Auf der Konsole RPI folgende Fehlermeldung
Use of uninitialized value in substr at ./FHEM/00_OWX.pm line 698.
substr outside of string at ./FHEM/21_OWTHERM.pm line 972.

Könnte es an  OWX/ OWTHERM liegen ?

hier noch die letzten log - Einträge

2014.03.27 02:16:26 1: usb create starting
2014.03.27 02:16:33 1: usb create end
2014.03.27 02:16:40 0: Server started with 38 defined entities (version $Id: fhem.pl 5197 2014-03-10 21:07:30Z rudolfkoenig $
2014.03.27 02:16:41 1: OWX: 1-Wire devices found on bus Modem1 (OWX_01_DE16C6160000)
2014.03.27 02:17:04 1: OWX: 1-Wire devices found on bus Modem1 (OWX_01_DE16C6160000)
2014.03.27 02:17:32 1: OWX: 1-Wire devices found on bus Modem1 (OWX_01_DE16C6160000)
2014.03.27 02:24:12 1: OWX: 1-Wire devices found on bus Modem1 (OWX_01_DE16C6160000,OWX_28_03E8C3040000,OWX_28_E3F03F050000)

Die Kombination OWX/OWTHERM läuft (so die Statistik von heute...) bei einigen hundert Installationen problemlos.

Ich tippe auf einen defekten Sensor, denn dieser meldet bei der Abfrage seines Scratchpad irgendeinen Müll zurück - vielleicht vorher mal falsch herum angeschlossen ?

Ausgerechnet diesen Fehler habe ich beim OWTHERM nicht abgefangen, einen Fix habe ich gerade eingecheckt.

LG

pah

Könnte man den Strom auch von einem PoE-Switch ziehen?

Gesendet von meinem Xperia Pro mit Tapatalk

Klar.

Allerdings ist ein Schaltregler, der aus den 48  V PoE (genauer 37-57 V) 5V macht, relativ teuer, und auch PoE ist für den Hausgebrauch eher zu teuer (Switches nach aktuellem Standard ca. 4x so viel wie ohne PoE). Ausnahmen sind diese Geräte hier:

http://www.amazon.de/TP-Link-TL-PoE150S-Single-Port-frustfreie-Verpackung/dp/B001PS9E5I
http://www.amazon.de/TP-Link-TL-PoE10R-PoE-Splitter-Adapter/dp/B001PS4NWW

Und der Splitter liefert sogar auf Wunsch 5 V.

Bessere Lösung für den versierten Hardware-Kenner: die vier unbenutzten Adern in einem "normalen" Netzwerkkabel direkt zur Stromzufuhr nutzen. Diesen Trick kann man u.a. auch verwenden, um zwei Ethernet-Buchsen mit nur einem Kabel zu bedienen.

Und auch das gibt es beides kommerziell zu kaufen:

http://www.amazon.de/DIGITUS-PoE-Kabelset-passiv-100Mbit/dp/B002NBN72C
http://www.amazon.de/Equip-Anschlussverdoppler-Cat-RJ45-Stecker/dp/B000LRTEPY

Ich denke schon länger über eine Lösung nach, bei der ich alle Switches und einige Endgeräte bei mir im Haus so versorge.

LG

pah

@pah
Problem ETH - Platine gelöst :-)
Habe einen neuen Fühler angeschlossen wie Du schon vermutet hattest,  und alles funktioniert perfekt, vielen Dank pah für Deine Hilfe und die guten Tipps .

@pah: Ich muss nochmal auf das WLAN-Teilchen zurückkommen...Trotz erfolgreicher Konfiguration (meine ich...) finde ich das Ding nicht im WLAN. Entgegen Deiner Konfiguration habe ich keine feste IP eingestellt, sonst aber analog. Aber weder in der Fritzbox-Übersicht, noch im Linux-Netzwerkscanner und auch nicht in der Scanner-App des iPhones taucht das Ding auf. Das unregelmäßige Blinken und Flackern der LED auf dem WLAN-Modul lässt aber auf Netzwerk-Aktivität schließen. Wie und wo finde ich das Dingens?

Danke

Sonntag morgen hab ich etwas Zeit. Heute Abend und morgen den ganzen Tag lang busy.

Wichtigste Punkte:

Auf der Seite Mode Selection auf STA Mode, Data Transfer= Transparent Mode

Auf der Seite STA Interface Setting
- SSID angeben
- Security Mode angeben
- Passwort angeben

WAN Connection Type auf DHCP setzen.

Das sollte reichen.

LG

pah

Hab ich genau so, das ist das Problem...  :(
Hier noch ohne Passwort, aber sonst...

Sieht mir nach einem DHCP-Problem aus.

Kann man protokollieren lassen, welche Clients bei Deinem DHCP-Server Anfragen stellen ?
Darüber hinaus würde ich erst einmal eine feste IP-Adresse vergeben - das benötigt man sowieso, um das dem socat mitzuteilen.

LG

pah

Eine feste IP hatte ich auch schon vergeben, ändert aber nichts. Das Ding wird auch dann weder von der Fritzbox noch von zwei unabhängigen Netzwerkscannern gefunden. Konfiguriere ich ihn als AP, dann bekomme ich ihn zu fassen. Sieht tatsächlich so aus, als würde die Fritzbox dem Modul keine IP zuteilen. Andererseits blinkt die LED auf dem Modul ab und an hektisch, als wäre WLAN-Aktivität vorhanden. Irgendwas passiert also...

Im Log der fritzbox kann man sehen wenn ein WLAN gerät sich zu dieser verbindet bzw. Die Verbindung auf Grund von xyz getrennt wird...

Gruß Marius


Gesendet von meinem iPhone mit Tapatalk

Ja, nur leider taucht das Ding auch da nicht auf. Andere WLAN-Geräte werden problemlos angekoppelt und erhalten statische und dynamische IPs, je nach Einstellung. Das (bzw. DHCP) funktioniert also.

Hm - dann bekommt er gar keine Verbindun gzum Netzwerk, die Authentifizierung wird nicht angenommen.

LG

pah

testhalber mal die Verschlüssellung vom WLAN abschalten?

Gruß
Jens

Verdammte Axt...nicht abschalten...ÄNDERN!!! Ich war auf WPA + WPA2 unterwegs und habe nun mal umgestellt auf WPA...damit klappt es. Verrückt. Ich habe auch im etwas umfangreicheren Manual (welches nicht auf der mitgelieferten CD ist...!) keinen Hinweis darauf gefunden, dass eine der WPA-Verschlüsselungen nicht unterstützt wird.

So, da nun alles wieder gut ist... ein Tipp zum Thema Schaltregler: Mittlerweile hab ich diese Teile: http://www.reichelt.de/Wandler-Module-DC-DC/OKLT1W12NC/3//index.html?ACTION=3&GROUPID=4956&ARTICLE=140737&SEARCH=DC%20DC%20WANDLER&SHOW=1&OFFSET=500& (http://www.reichelt.de/Wandler-Module-DC-DC/OKLT1W12NC/3//index.html?ACTION=3&GROUPID=4956&ARTICLE=140737&SEARCH=DC%20DC%20WANDLER&SHOW=1&OFFSET=500&) in Gebrauch und bin sehr zufrieden...sowohl auf 3,3V als auch 5V per externem Widerstand einstellbar. Die Dinger sind auf SMD-Platinen wie auch auf bedrahteten Platinen einsetzbar.

Moin,

ich habe nun mit diesem Teil (http://www.wvshare.com/product/UART-ETH-E001.htm (http://www.wvshare.com/product/UART-ETH-E001.htm)) ein bisschen rumgespielt und eine Platine für das Conrad-Hutschienen-Gehäuse (http://www.conrad.de/ce/de/product/530730/Hutschienen-Gehaeuse-Kunststoff-Grau-RAL-7035-35-x-86-x-60-PN-5200100035-1-St)  (http://www.conrad.de/ce/de/product/530730/Hutschienen-Gehaeuse-Kunststoff-Grau-RAL-7035-35-x-86-x-60-PN-5200100035-1-St)) entworfen...
Oben drauf ein paar Flackerlichter (Spannungen und Busaktivität) und schon isses hübsch.

Mäusekino.

Glaubst Du eigentlich, dass das Licht im Kühlschrank ausgeht, wenn er zu ist ?

LG

pah

Ich steh auf Mäusekino. Berufsbedingt. Ich habe täglich mehr als 300.000 LEDs um mich rum. Das macht offenbar krank...
Und das mit dem Licht im Kühlschrank hab ich im Alter von 5 oder so getestet. Es war kalt, aber es ist definitiv aus.

Hi uwe.
Schaltplan wäre nett ;) insbesondere wegen der Bus Aktivität

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Zitat von: Tobias am 30 März 2014, 19:02:07
Schaltplan wäre nett

Wenn ich fertig getestet habe. Aber die LED für den Bus ist einfach:

Hallo Uwe !

Zitat von: Tobias am 18 März 2014, 05:53:48
Werde es mir merken. Ich benutze hier Tracepower den TGS 1-2450. Geht von 7-36V

Paßt Der DC/DC Wandler noch auf die neue Platine drauf ?

Gruß, Marc

Der ist da drauf (das Teil über der Schraubklemme) und produziert fleißig 5V.

Spitze  8)

Sorry, ich halte das für Overkill. Weder braucht man 5 W Ausgansleistung, noch so viel Platz.
Bei mir werkelt das Teil vor sich hin:
http://www.conrad.biz/ce/de/product/156127/SpannungsreglerSchaltregler-STMicroelectronics-L4931CD33-Gehaeuseart-SO-8-Ausgangsspannung-33-V-Iout-250-mA-Ausfuehru/SHOP_AREA_18976?

LG

pah

12,5x12,5mm. Der L4931CD33 ist mit seiner Peripherie und den Leiterbahnen ähnlich klein.
Bei Conrad gibt's den OKL mit 200mA, sind aber C-typischerweise teurer als die 1000mA bei Reichelt. Also nicht unbedingt eine Leistungs-, sondern eher eine Preisfrage. Die 200mA wiederum sind ausreichend für das Modul an sich, bei einem umfangreichen Bus könnte es knapp werden, vor allem mit viel Mäusekino ;-) Die 250mA für die 3,3V vom L4931CD33 sollten aber in jedem Fall reichen. Ich habe den OKL mit 1A für die 5V Versorgung. Beim WiFi-Modul habe ich auch den L4931CD33 zusätzlich für die 3,3V.
Aber glücklicherweise kann das ja jeder machen wie er will... :)

Für die 5V incl. Bus ist das sicher OK - ich hatte geglaubt, dass Du nur 200 mA 3,3 V für das Wifi-Teil brauchst.

Ich empfehle übrigens, den Bus immer mit 5V laufen zu lassen. Das ist auch kein Problem, wenn das Wifi-Teil mit 3,3 und der angeschlossene DS2480 mit 5 V arbeiten.

LG

pah

Hallo zusammen,
ich habe das Kristech Teil von Tobias bekommen, danke nochmal dass das so gut und schnell geklappt hat.

Jetzt will ich es auf meiner 7490 einbinden und weis nicht so recht wo ich das:
socat PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.1.101:23
eintragen muss und was vielleicht noch dazu muss, ich bin in Linux nicht ganz so fit, könntet ihr mir bitte weiterhelfen.
Gruß
Matthias

Hallo Matthias,

die Befehle sollen in das Startdatei von fhem. Es müssen alle Befehle aufgenommen werden.

Wichtiger ist allerdings, dass Du socat wahrscheinlich auch noch auf die Frtizbox installieren musst.

Ciao

Alexander

Oh neiin hat das vor mir noch niemand auf der fritzbox gemacht?
Das ist bestimmt nicht einfach nach zu installieren oder?
Welche befehle müssen denn alle in die startfhem?
Gruss
Matthias

Hi !

Ist Deine Fritzbox gefreezt ? Bei Freetz wäre socat dabei. Falls nein, kann ich Dir das Binary für
FritzOS 6.03 schicken.

Gruß, Marc

Ich habe immer noch vor, einen direkten Socket-Zugriff in OWX einzubauen. Dazu fehlt mir schlicht die Zeit - und der Workaround mit socat funktioniert bei mir optimal stabil. Ich habe auf dem Raspberry Pi dem Hardware-Watchfog ein Skript verpasst, das alle 15 Sekunden überprüft, ob socat noch läuft und es ggf. neu startet. Erst wenn das nicht geht, erfolgt ein Neustart von FHEM bzw. des ganzen RPi.

LG

pah

Hi, hab grade nachgesehen sbin/socat ist drin das sollte doch einiges einfacher machen hoffe ich :-)
Ich habe das fhem image für die 7390 installiert scheinbar ist es dabei gewesen.

Was muss jetzt noch genau in die Start fhem und an welche Stelle?
Ich habe gelesen dass es aufjedenfall vor fhem gestartet werden muss...

@pah das wäre natürlich das allerbeste wenn es im OWX mit eingebaut würde, kann da niemend unterstützen?
Ich habe leider wenig Plan von Software ehrlich gesagt habe ich nichtmal das Kristech Konfigurationsprogramm auf einen von 3 Rechnern zum
Laufen gebracht und es dann im Web if auf Polnisch eingestellt, ging aber auch, die wenigen Parameter einzustellen.
Ich hätte auch noch etwas Zeit, also wenn es bald ohne socat ginge wäre sehr gut.

Gruß
Matthias

Oh, man kann damit sehr gut Polnisch lernen. Oder Chinesisch, was den WLAN-Adapter betrifft.

Es sollte sich auch niemand gehindert fühlen, dieses neue Backend zu bauen. In dem Fall sollte aber die moderne modularisierte Version des Backends verwendet werden, d.h. es sollte ein 11_OWX_TCP.pm werden, das bei Bedarf von OWX dazugeladen wird.

Ich bin jedenfalls leider im Moment nicht im Stande, da Arbeit hineinzustecken.

LG

pah

Prototyp WLAN-/1Wire-Interface mit 12V Einspeisung und 5V/3,3V- Schaltregler und China-WLAN-Modul. Passend für Conrad Hutschienengehäuse und mit reichlich Mäusekino, inkl. Reset- und Restore-Tasten.
Pegelanpassung über Optokoppler. Und nun testen, testen, testen... :)
(Leider keine Zeit und Muße für gute Fotos...)

Hallo,

hier läuft jetzt eine von Tobias Platinen mit dem Kristech Adapter. Soweit ich erkennen kann, ganz gut.

Einzig wenn ich fhem mit dem Kommando im FHEM shutdown restart neu starten will, fliegt die socat Verbindung raus.

Stoppe ich fhem mit service fhem stop und starte mit service fhem start dann geht das nach PAH Init-Skript ohne Fehler.

Kann das jemand bestätigen?

Ciao

Alexander

Hallo Alexander,
ja, ist genau so bei mir. Das ist auch der Grund, warum die zwei Teile immer noch auf dem Schreibtisch als Versuchsaufbau mit div. 1-wire Sensoren am Breadboard ihr Dasein fristen und nicht in den Garten umgezogen sind.
Pah hatte in Aussicht gestellt, den socat Prozess irgendwann in OWX zu integrieren, wenn ich das richtig verstanden habe. Solange warte ich eben noch - Ambilight an der Terasse und Zisternenüberwachung sind nicht lebensnotwendig.

Hallo det,

zwischenzeitlich habe mir mal den Code in fhem.pl angeschaut.

Aus der aktuellen fhem.pl (so um Zeile 1374)

if($param && $param eq "restart") {
if ($^O !~ m/Win/) {
system("(sleep 2; exec $^X $0 $attr{global}{configfile})&");
} elsif ($winService->{AsAService}) {
# use the OS SCM to stop and start the service
exec('cmd.exe /C net stop fhem & net start fhem');
}

Wenn ich das richtig verstehe, startet sich bei nicht Windows System fhem selbst wieder
neu. Wenn man bei init.d Anpassung bei start und stop vorgenommen, werden diese
nicht ausgeführt?


Ciao

Alexander

Der socat Prozess schmiert in der Tat dann ab. Darum läuft auf meinem RPi ein Skript, das der watchdig-timer alle 15 Sekunden ausführt und auf darin auf das Vorhandensein von socat prüft. Wenn nicht, wird es neu gestartet ohne FHEM zu tangieren.

LG aus Tel Aviv

pah

Hallo pah,
Wenn Du gesund aus dem biblischen Land zurück bist, freuen wir uns über die Veröffentlichung des kleinen Skripts mit etwas Anleitung.
Danke schon mal und noch eine schöne Zeit!

Zitat von: matthias soll am 05 April 2014, 20:47:43
@pah das wäre natürlich das allerbeste wenn es im OWX mit eingebaut würde, kann da niemend unterstützen?

Ich kann das machen, TcpClient in OWX zum Zugriff auf DS2480 zu integrieren ist nicht so schwer.

Vorher müssen aber sowohl OWX_ASYNC als auch OWCOUNT soweit mal stabil sein. Beides könnt Ihr mit Testen und Feedback beschleunigen (die Unterstützung für DS2480 ist im OWX_ASYNC schon drin ;-))

Ich würde das ausschließlich in OWX_ASYNC einbauen, beim Ansteuern über Ethernet macht das asynchrone Lesen nämlich richtig Sinn. (Und OWX_ASYNC ist so modular, dass der Einbau relariv einfach wird).

Gruß,

Norbert

Da bin ich aber dagegen. In meinem Netz läuft die Ethernet-Verbindung so gut, dass das auch in die asynchrone Mimik hineinmuss.

Außerdem hatten wir ja die hardwarespezifischen Funktionen vom OWX getrennt - das sollten wir auch bei einer Socket-Verbindung beibehalten.

LG aus Tel Aviv

pah

Zitat von: Prof. Dr. Peter Henning am 09 April 2014, 21:33:38In meinem Netz läuft die Ethernet-Verbindung so gut, dass das auch in die asynchrone Mimik hineinmuss.

hab ich was anderes gesagt?

Zitat von: Prof. Dr. Peter Henning am 09 April 2014, 21:33:38
Außerdem hatten wir ja die hardwarespezifischen Funktionen vom OWX getrennt - das sollten wir auch bei einer Socket-Verbindung beibehalten.

dito.

Gruß,

Norbert

Nein, aber ich habe das Falsche geschrieben - asynchron statt synchron. War wohl zu müde gestern abend.

Ich meinte, dass da die synchrone Abfrage ebenfalls möglich sein muss bei den Socket-Verbindungen.

LG - immer noch aus TA

pah

Zitat von: Prof. Dr. Peter Henning am 10 April 2014, 06:31:36
Ich meinte, dass da die synchrone Abfrage ebenfalls möglich sein muss bei den Socket-Verbindungen.

Damit bei einem Unterbrechen der Netzwerkverbindung fhem bis zum Ende des TCP-timeouts klemmt?
Ich hab da kein Problem mit, wenn das einer schriebt und auch supportet.

Die get xxx-kommandos verhalten sich mit OWX_ASYNC übrigens alle synchron, d.h. der User muss warten bis die (frisch aktualisierten) Werte da sind. Nur das Pollem im Hintergrund läuft asynchron.

Gruß,

Norbert

Kurzer Zwischenstand zum WLAN/1Wire-Interface...läuft und läuft und läuft...
Momentan einziger Nachteil ist der hohe Preis der speziellen RS232-geeigneten Optokoppler. Solch ein Teil kostet in der Elektronik-Apotheke mal eben 6€. Die einfache Variante mittels FET o.ä. funktioniert möglicherweise auch, muss ich ggf. noch testen.

Hallo, hab hier immer mal wieder im Thread gelesen, wec´he Bauteile brauche ich für so ein 1wire WLAN teil Kosten?
Ich denke das würed auch noch andere interessieren.
mfg
FT

Die Kosten liegen grob geschätzt zwischen 30 und 40€. Meine derzeitige Testversion ist sicher noch etwas teurer, da ich die Pegelanpassung über Optokoppler gelöst habe, die pah'sche Variante mit Spannungsteiler dürfte dabei die preiswerteste sein. Die Optokoppler hatte ich aus einem anderen Projekt noch rumliegen, daher...Die sind mit 6€ pro Stück aber auch wirklich teuer.

Hallo zusammen, ist jetzt jemand dabei das in OWX zu implementieren? Oder konnte noch keine Einigung gefunden werden?

Zitat von: matthias soll am 22 April 2014, 18:05:44
Hallo zusammen, ist jetzt jemand dabei das in OWX zu implementieren? Oder konnte noch keine Einigung gefunden werden?

Ich hab mal einen ersten Wurf hingelegt:

00_OWX_ASYNC.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/00_OWX_ASYNC.pm)
OWX_Executor.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/OWX_Executor.pm)
OWX_SER.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/OWX_SER.pm)
OWX_DS2480.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/OWX_DS2480.pm)
21_OWAD.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/21_OWAD.pm)
21_OWCOUNT.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/21_OWCOUNT.pm)
21_OWLCD.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/21_OWLCD.pm)
21_OWMULTI.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/21_OWMULTI.pm)
21_OWSWITCH.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/21_OWSWITCH.pm)
21_OWTHERM.pm (https://github.com/ntruchsess/fhem-mirror/raw/owx_async_network/fhem/FHEM/21_OWTHERM.pm)

Das ganze basiert auf der aktuellen Developmentversion von OWX_ASYNC. Wenn mit irgendeinem Frontendmodul was nicht geht ist das Feedback daher ggf. besser im dazugehörigen Thread (http://forum.fhem.de/index.php/topic,13580.msg161708.html#new) aufgehoben.

wird mit: define <name> OWX_ASYNC <hostname|ip>:<port> angelegt.

Unterstützt wird erst mal die grundsätzliche Connectivity, also Verbindung aufbauen und nutzen, solange sie geht. Dinge wie sauberes Wiederverbinden nach Abbruch sind noch nicht drin (das kann die USB-basierte variante bisher auch noch nicht, aber das kommt noch).

Ist allerdings komplett ungetestet, ich besitze keinen dieser Network<->Serial-adapter, wenn ich selber testen soll, muss mir einer einen schicken.

Gruß,

Norbert

Zitat von: ntruchsess am 23 April 2014, 14:43:29
ich besitze keinen dieser Network<->Serial-adapter, wenn ich selber testen soll, muss mir einer einen schicken.

Ich kann Dir gerne einen meiner Prototypen schicken. Wenn ich Deine Adresse habe, geht das Ding auf die Reise :)

Moin,

die Verbindung scheint zu stehen, aber im Log bekomme ich dann die nachfolgenden Meldungen...

So, mittlerweile ist die nötige Leih-Hardware da :-)
Leider geht's erst am Sonntag abend weiter, bin bis dahin unterwegs und kann meinen 1-Wire-testaufbau nicht gut mitnehmen.

Gruß,

Norbert

Hallo Uwe,

gibt bzgl. dieses Platinensatzes Neuigkeiten, gibst Du ihn zum allgemeinen Testen frei ?

Zitat von: UweH am 30 März 2014, 17:53:55
ich habe nun mit diesem Teil (http://www.wvshare.com/product/UART-ETH-E001.htm (http://www.wvshare.com/product/UART-ETH-E001.htm)) ein bisschen rumgespielt und eine Platine für das Conrad-Hutschienen-Gehäuse (http://www.conrad.de/ce/dHae/product/530730/Hutschienen-Gehaeuse-Kunststoff-Grau-RAL-7035-35-x-86-x-60-PN-5200100035-1-St)  (http://www.conrad.de/ce/de/product/530730/Hutschienen-Gehaeuse-Kunststoff-Grau-RAL-7035-35-x-86-x-60-PN-5200100035-1-St)) entworfen...

Gruß, Marc

Moin,

ich hatte in den letzten 2 Wochen wenig Zeit dafür, ab Montag wird es aber wieder besser... :)
Da das Teil hardwaremäßig läuft, werde ich an meinem Platinensatz wohl nichts mehr ändern müssen. Andererseits fehlt's noch am "Powertest", aber wie gesagt, ab Montag... :)
Bin nun noch auf die Rückmeldung von Norbert und die Verhakelung mit OWX_ASYNC gespannt.
Es funktionieren sowohl die LAN:http://forum.fhem.de/index.php/topic,18996.msg154364.html#msg154364 (http://forum.fhem.de/index.php/topic,18996.msg154364.html#msg154364) als auch die WLAN-Version:http://forum.fhem.de/index.php/topic,18996.msg156739.html#msg156739 (http://forum.fhem.de/index.php/topic,18996.msg156739.html#msg156739) problemlos.

Zitat von: UweH am 08 Mai 2014, 20:55:22
Bin nun noch auf die Rückmeldung von Norbert und die Verhakelung mit OWX_ASYNC gespannt.

Das Refactoring des OWX_ASYNC auf Prototheads ist jetzt wohl relativ stabil (http://forum.fhem.de/index.php/topic,13580.msg166756.html#msg166756), das schafft die nötige Luft endlich die Netzwerkanbindung in Angriff zu nehmen. Stay tuned ;-)

Gruß,

Norbert

Bin auch gerade wieder etwas unter Überlast, kann also im Moment nichts beitragen.

Es freut mich auch, dass die neuen Interfaces funktionieren - ich habe schon etwas Neues in der Pipeline:

http://www.ebay.com/itm/Wireless-Serial-4-Pin-Bluetooth-RF-Transceiver-Module-HC-06-RS232-With-backplane-/200924726178?pt=LH_DefaultDomain_0&hash=item2ec80c03a2

LG

pah

@Pah: diese HC-06 Bluetooth-module funktionieren prima, einmal konfiguriert und ab da immer wieder automatisch koppelbar. Nur die Reichweite ist nicht so doll. Bei mir gingen da nur wenige Meter, eigentlich nur im gleichen Raum mit der Gegenstelle oder vieleicht unmittelbar durch eine Leichtbauwand einsetzbar, die Teile sind doch eher für den Nahbereich gedacht.

Gruß,

Norbert

Das ist doch genau der gewünschte Anwendungszweck - mal schnell durch eine Wand, ohne ein Kabel ziehen zu müssen. Oder ein batteriebetriebenes 1-Wire Device, vom Badewannenthermometer bis zum mobilen Warngerät.

LG

pah

Hab gestern endlich mal das Interface angschlossen und gleich mal ein paar kleine Bugs im OWX_ASYNC (branch owx_async_network) gefixed. Funktioniert aber noch nicht so, wie es soll.
Mal ne Frage in die Runde: Das Interface (Kristech KT-ETH-UART-1) muss vermutlich auf TCPSERVER, RAW, 9600 Baud eingestellt werden, damit an der seriellen Schnittstelle genau das rauskommt, was übers Netz reinkommt? Kann man die Einstellung dann irgendwie dauerhaft speichern?

Gruß,

Norbert

Hallo Norbert,

soweit ich mich erinnern kann, war der Haken bei der polnischen Firmware an der gleichen Stelle. Anbei das Bild aus der englischen Version.

Danke Dir Alexander, passt :-)

Gruß,

Norbert

Hallo zusammen,
gibt es hier bald etwas neues?

Also für den Polen Adapter habe ich noch Platinen vorrätig.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Was denn Neues ? Die Dinger laufen bei mir sowohl im Festnetz, als auch per WLAN ganz stabil.

LG

pah

Ich dachte Norbert ist dabei die Software in owxasync zu integrierten.
LG

Zitat von: matthias soll am 28 Mai 2014, 15:53:32Ich dachte Norbert ist dabei die Software in owxasync zu integrierten.

Bin ich auch... Ist aktuell nur ein bischen eng, weil ich eine (richtige) Baustelle vor dem Haus habe die an den Wochenenden einiges an Kraft zehrt (und OWX_ASYNC macht in manchen Szenarien wie Dis- und Reconnect etc... noch etwas Schluckauf, der erst mal auskuriert werden will, bevor ich weitere Interfaces aktiv supporte).

Gruß,

Norbert

Tja, so ist das...

Ich brauche sicher noch Wochen, um mich wieder etwas frei zu schaufeln...

LG

pah

OK alles gut wollte auch nicht drängeln.
LG
Matze

Zitat von: matthias soll am 28 Mai 2014, 15:53:32
Ich dachte Norbert ist dabei die Software in owxasync zu integrierten.

ist jetzt drin (http://sourceforge.net/p/fhem/code/6292/). Mit den richtigen Grundlagen im OWX_ASYNC/OWX_SER/OWX_DS2480 war es eigentlich nur noch ein 3-Zeiler...

unterstützt erst mal eine Konfiguration als TCP-Client (der über Ethernet angebundene DS2480 ist also der TCP-Server).
Die Definition geht beispielsweise so:
define owx OWX_ASYNC 192.168.0.69:4444 (IP-addresse des Moduls 192.168.0.69, Port 4444).

Hat (wie alle TCP-Clients) aber noch das Problem dass das Betriebssystem ein Abschalten bzw. vom Netzwerk entfernen des Ethernet-moduls erst mal (bis zum TCP-Timeout) nicht bemerkt und der Adapter mitunter minutenlang 'Active' bleibt, während die Request alle in Timeout laufen. Da will ich noch einen Error-counter einbauen, der beim Überschreiten eines Schwellwerts einen FHEM-seitigen disconnect macht und danach versucht wieder neu zu verbinden.

Unterstützung für OWX_ASYNC im TCP-Server-mode kommt noch.

EDIT: der Timeout-counter (http://sourceforge.net/p/fhem/code/6294/) ist jetzt auch schon drin. Mit dem Attribut 'maxtimeouts' (default 5) kann man konfigurieren, nach wie vielen Timeouts hintereinander OWX_ASYNC selber die Verbindung abbricht und versucht neu aufzubauen. Die Erkennungszeit hängt natürlich von der Aktivität (bzw. dem Interval der Devices) ab. Der Reconnect dauert danach zwar auch ein bischen (das ist die in DevIo_Opendev eingebaute Logic, die exzessive wiederholte Verbindungsaufbauversuche einbremst), aber alles in allem immer noch deutlich fixer als auf die TCP-Timeouts zu warten.

EDIT: Es müssen alle(!) OWX-relevanten Dateien (OWX_ASYNC, OWX_SER, OWX_DS2480 und alle OWXXX-clients) geupdated werden, die neue Funktionalität baut auf Changes im OWX_ASYNC auf die nicht zu älteren Versionen der Devices kompatibel sind.

Gruß,

Norbert

Hallo,
Das Thema kommt wie gerufen. Im Keller liegt keine 1wire Verkabelung, aber eine LAN dose. Dafür wäre dieses Interface ja dann praktisch um 1wire Sensoren im Keller zu nutzen.
Wird jemand die Platine fertig bestückt / als sammelbestellung anbieten? Oder kann man evtl. Sogar jetzt schon was bekommen?
Schöne grüße & vielen Dank. Super Idee und super Arbeit!

Ich habe noch 3 leere Platinen für je 2€ anzubieten.

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Zitat von: ntruchsess am 21 Juli 2014, 23:17:32
ist jetzt drin (http://sourceforge.net/p/fhem/code/6292/).
unterstützt erst mal eine Konfiguration als TCP-Client (der über Ethernet angebundene DS2480 ist also der TCP-Server).
Die Definition geht beispielsweise so:

Code Auswählen Erweitern

define owx OWX_ASYNC 192.168.0.69 4444 (IP-addresse des Moduls 192.168.0.69, Port 4444).

Hallo Norbert,

erst mal vielen Dank für Deine Mühe.
Mit socat läuft es zwar, aber extrem unkomfortabel... ;-)

Der Verbindungsaufbau zum Interface (Kristech) produziert erst mal nur "OWX: Define failed, unable to identify interface type 192.168.xxxx". In Deinem Beispiel ist der Port mit einem Leerzeichen von der IP getrennt, nicht mit einem Doppelpunkt. Setze ich den Port mit einem Doppelpunkt dahinter, wird das define angelegt, ich bekomme dann keine Fehlermeldung, sondern ein "disconnected" im state.

Ich habe die 3 Dateien aus sourceforge in mein FHEM-Verzeichnis gepackt und den socat-Aufruf aus /etc/init.d/fhem auskommentiert. Soweit alles richtig?

Edit: Ein "get ... devices" produziert: OWX: Discover called with unknown interface serial on bus 1wire at ./FHEM/00_OWX_ASYNC.pm line 417.
Ein "get ... version" liefert "5.8". Viellleicht hilft das weiter...

Zitat von: UweH am 22 Juli 2014, 12:01:23
In Deinem Beispiel ist der Port mit einem Leerzeichen von der IP getrennt, nicht mit einem Doppelpunkt.

Oh, danke. Da gehört natürlich ein Doppelpunkt dazwischen. Hab meinen Post korrigiert.

Zitat von: UweH am 22 Juli 2014, 12:01:23
Ich habe die 3 Dateien aus sourceforge in mein FHEM-Verzeichnis gepackt[...]Soweit alles richtig?

Du musst alle(!) OWX-dateien aktualisieren, die OWX-Clients von vor dem OWX_ASYNC-update letzter Woche sind nicht kompatibel mit dem aktellen code.

Zitat von: UweH am 22 Juli 2014, 12:01:23
Ein "get ... version" liefert "5.8".

im SVN ist mittlerweise Version 5.10 ;-) Damit geht dann auch ein Reconnect bei temporärem Aus- und Wiedereinschalten des Ethernetmoduls.

Das "alle" irritiert mich jetzt etwas... 00_OWX_ASYNC.pm kam per Update und dann finde ich nur noch OWX_SER.pm und OWX_DS2480.pm. Ich verstehe offenbar am System was nicht...

Edit: Nee, Moment , ich versteh es gerade...hab's gefunden (schäm...)

So, alle ( ;)) OWX-Dateien aktualisiert, Version ist jetzt 5.1 (soll dann wohl 5.10 heißen) und mit dem richtigen Port klappt's dann auch  ;)

Hallo Norbert,
ist kaum zu fassen - es funktioniert auf Anhieb mit beiden DS2480 von Tobias Platine! Vielen Dank, da kann die 1-wire Erweiterung in Richtung Garten hinter dem Haus über Netzwerkkabel weitergehen.

Hallo Norbert,

alles, was ich bisher getestet habe, funktioniert, nur...ich kann beim LCD mit dem Befehl "set LCD backlight on" bzw. "off" die Hintergrundbeleuchtung nicht mehr schalten. Was ist das denn für ein kurioses Verhalten? Kann das jemand bestätigen?
Ich habe versucht, mir hier: http://forum.fhem.de/index.php/topic,13580.270.html (http://forum.fhem.de/index.php/topic,13580.270.html) Fakten zu holen, werde aber nicht fündig.

Zitat von: UweH am 22 Juli 2014, 20:07:09
alles, was ich bisher getestet habe, funktioniert, nur...ich kann beim LCD mit dem Befehl "set LCD backlight on" bzw. "off" die Hintergrundbeleuchtung nicht mehr schalten. Was ist das denn für ein kurioses Verhalten? Kann das jemand bestätigen?

Ja, das Verhalten habe ich auch - aber nicht erst seit heute - auf dem CUBIE2 mit USB Interface und auf dem RPI mit USB und dem KRISTEC Interface. Ist das Displax nach dem Serverneustart erst mal an leuchtet es (und Backlight lässt sich nicht mehr ausschalten) - das ist der Normalzustand und war mir nicht Wert hier anzumerken. Wenn es allerdings wie bei dem Test RPI ausgegangen ist (ich hatte das vor diesem Post auf mangelnde Stromversorgung nur über den RPI USB geschoben) lässt sich Backlight nur durch FHEM reboot wieder zum Leben erwecken.

Das ist ja interessant. Ich habe ein Testsystem mit OWX_ASYNC auf einem Cubie 2 aufgesetzt und da zeigt das Display dieses Verhalten. Hab ich bisher noch nie beobachtet, weder auf meinem FHEM-Livesystem noch auf einem Test-Raspi. Werd morgen mal die OWX_ASYNC-Geschichte auf dem Raspi testen, bin ja mal gespannt.

OWLCD ist bei mir ein bischen das Problemkind. Ich habe zwar den zugehörigen 1-Wire LCD-Controller, aber meine Displays (ein 2004 und ein 1602) scheinen nicht die passende Pinbelegung zu haben. Das hat bei mir auch mit dem synchronen OWX nicht richtig funktioniert, daher bin ich was das Testen angeht da vollständig auf Euch angewiesen. Ich werfe aber gerne noch mal einen Blick drauf, ob der asynchrone Code für 'Backlight on/off' tatsächlich so implementiert ist, dass das gleiche über die Leitung gehen sollte. Geht denn sonst alles mit dem LCD?

Gruß,

Norbert

Ja, bei meinem Display funktionieren alle anderen set- und get-Möglichkeiten  ;)

Beim Start von FHEM bekomme ich folgende Meldung auf der Konsole:
"Argument "OWXLCD: Wrong function selected" isn't numeric in numeric eq (==) at ./FHEM/00_OWX_ASYNC.pm line 1090"
Hilft Dir das vielleicht?

Zitat von: UweH am 23 Juli 2014, 11:19:53Hilft Dir das vielleicht?

Danke, das hat geholfen, war ein Typo. Fix ist im SVN commited (http://sourceforge.net/p/fhem/code/6311/) (bitte testen, hab hier grade keine Hardware...)

Gruß,

Norbert

Zitat von: ntruchsess am 24 Juli 2014, 11:18:16
Danke, das hat geholfen

Danke, das hat geholfen  ;)
Die Beleuchtung lässt sich wieder schalten.

Hallo Norbert,
prima, danke! Backlight lässt sich wieder schalten, an 4 unterschiedlich angebundenen Displays soeben getestet.

Hallo zusammen, ich teste das Modul auch grade mit meinem Kristec teil.
Ich bekomme im Log immer den Fehler:

reload: Error:Modul 00_OWX_ASYNC deactivated:
Illegal declaration of anonymous subroutine at ./FHEM/00_OWX_ASYNC.pm line 2046, <$fh> line 54.

Kennt jemand das Problem? Update check sagt dass es nichts neueres gibt.

das ist merkwürdig, die Datei 00_OWX_ASYNC.pm hat ja nur 1239 Zeilen. Scheint irgendwie nochmal geladen zu werden. Mit welcher Aktion kannst Du den Fehler reproduzieren? Kommt irgend ein Fehler auf der Konsole (STDOUT/STDERR)? Gibt's schon beim 'define' einen Fehler (und ist deine Fehlermeldung dann nur der Folgefehler)?

Gruß,
Norbert

Hallo Norbert,

halt nein mein fehler.
War zu blöd die richtigen dateien herunterzuladen.
Jetzt versucht er verbindung aufzubauen hab aber das kistec teil grade nicht laufen.

Hallo zusammen,

ich habe auch das Kristec Teil und wollte Ihn mit OWX_ASYNC testen. FHEM läuft auf einen RPI, 4 Fühler DS18B20 und 2 DS2413.Eine generelle Frage geht OWX_ASYNC auf dem RPI überhaupt fehlerfrei ? Folgende Schritte hatte ich durchgeführt.

FHEM – Update

Socat deaktiviert in der Start - Datei

define Modem1 OWX_ASYNC 192.168.1.120:23

define Modem2 OWX_ASYNC 192.168.1.120:26

 

Die Modems wurden gleich erkannt und Status aktiv , mit get devices Modem1 wurden leider nur 2 Fühler zu Anfang angezeigt, mit immer wieder restart hatte ich es dann irgendwie geschafft dass alle 4 Fühler angezeigt wurden auch der DS2413. Die Fühler gingen aber immer auf Fehlertemperatur 85Grad, mit get Temperature kurzeitig richtiger Wert.

 

Mit Socat – Version liefen alle Devices ordentlich.

 

Kann jemand helfen ?

 

Besten Dank schon mal ...

Hallo Peter,

sind die Sensoren parasitär versorgt?

Gruß,

Norbert

Hallo Norbert
die Sensoren sind parasitär verdrahtet.
Noch mal ich hab für die Installation keine Dateien in das fhem Verzeichnis kopiert, lediglich das fhem update wurde durchgeführt, hoffe das ist richtig.
Zu Socat noch, hier wurden die Sensoren automatisch erkannt, bei ASYNC nicht, hoffe es hilft weiter.
Ich würde halt sehr gerne die ASYNC - Version nutzen
...Danke

Zitat von: Peter_64 am 31 Juli 2014, 12:21:24
...lediglich das fhem update wurde durchgeführt, hoffe das ist richtig.

ja, passt so (und nicht anders). Ist ja alles im SVN drin.

Zitat von: Peter_64 am 31 Juli 2014, 12:21:24
die Sensoren sind parasitär verdrahtet.

Das ist wohl das Problem, OWX_ASYNC ist in den Konvertierungspausen der DS18B20 auf dem 1-Wire-bus aktiv. Das bringt deutlich höheren Durchsatz, stört aber die parasitäre Versorgung. (It's not a bug, it's a feature...). Ich habe vor da noch einen (per Attribut konfigurierbaren) 'parasitären' Modus einzubauen, der alle Abfragen streng serialisiert. Das verringert dann zwar den maximal möglichen Durchsatz gegenüber einer aktiven Spannungsversorgung, aber anders geht's parasitär wohl nicht. Der Pi selbst sollte jedenfalls nicht der Flaschenhals sein, damit lief's bei mir im Test (mit über USB angebundenem Busmaster, das Kristech-modul habe ich mit dem Pi noch nicht zusammen getestet) eigentlich anstandslos.

Gruß,

Norbert

Hallo Norbert,
danke schon mal für den Tipp, da werde ich zum Test anders verdrahten und berichten.

Grüße

Hallo Peter,

ich habe mal einen Patch (https://github.com/ntruchsess/fhem-mirror/commit/cf13d46c34def1b0303eb73e952d63e5f5833bd8) gemacht, mit dem man per Attribute 'buspower=parasitic' das parallele Bearbeiten der Abfragen abstellen kann. Kannst Du Deine parasitär versorgten Sensoren damit mal testen? (Attribut 'dokick' darf dabei nicht auf 1 gesetzt sein)

EDIT: hab es grade selber getestet und für gut befunden. Ist schon im SVN und kann in Kürze per Update bezogen werden. Stellt man jetzt 'buspower' auf 'parasitic' wird automatisch 'dokick' ignoriert.

Gruß,

Norbert

Hallo Norbert,
danke für die schnelle Umsetzung, wenn es im SVN ist werd ich testen (DS2406, DS2413 + die Temp)
Gruß Peter

EDIT: Habe gerade den Test gestartet. nach Restart  wird nur ein DS18B20 erkannt, auch mit  get Modem1 devices werden keine weiteren Fühler angezeigt, auch die 2413 usw. werden nicht gefunden. Der DS18B20 hat dafür keine Fehler mehr. Die Einstellungen
buspower -> parasitic und maxtimeouts -> 1 denke sollten passen. Gibt es eine alternative die Fühler zu aktivieren ?

Gruß

Hallo,

dazu muss ich auch mal meinen Senf dazugeben...ich habe ebenfalls zwei LAN/DS2480-Interfaces laufen (unter OXW_ASYNC, einmal KrisTech und ein Chinateil, siehe diesen Thread weiter vorn), an denen diverse Devices hängen. Erfahrungen bisher:

• Ich habe mehrere Anläufe gebraucht, bis FHEM kapiert hatte, dass ich zwei Interfaces einrichten möchte. Beim Erstellen der Definition eines Interfaces:

define 1wire_1 OWX_ASYNC xxxxx

über die Kommandozeile geht noch alles gut, beim zweiten friert FHEM ein. Jedesmal und reproduzierbar. Ich habe dann die fhem.cfg auf der Konsole editiert und rebootet. Auch da braucht's schon mal zwei- oder drei FHEM Neustarts, bevor die Verbindungen da sind. Dazu muss aber vorher die Stromversorgung der Interfaces kurz unterbrochen bzw. ein Restart des Interfaces durchgeführt werden, sonst gibt's keine Verbindung. Sehr merkwürdig. [/li]

• Nach einem "shutdown restart" werden die Verbindungen meist wieder hergestellt, aber eben auch nicht immer. Dann hilft ein Restart der Interfaces (siehe oben...) und FHEM bekommt sie sofort zu fassen. 
• Ein Ausfall eines Interfaces nimmt FHEM hin und bleibt am Leben, nach ca. 1min wird die Verbindung auf "disconnected" gesetzt. Nachdem das Interface wieder aktiviert wurde, braucht FHEM dann auch ca. 1 min, bis die Verbindung wieder steht. Sehr hübsch  :)
• Und: Wenn die Interfaces laufen, dann laufen sie auch. Während des "normalen" Betriebes kam es bisher zu keinem Verbindungsabbruch  :)

@ntruchsess:
Soweit also schon sehr gut, nur das Problem, dass OWX_ASYNC die Verbindung zu einem schon ewig laufenden Interface nicht mehr aufbaut, kannst Du hoffentlich noch beheben. Es sei denn, das betrifft nur mich...  >:(
Daten dazu kann ich gerne liefern, wenn Du mir sagst, was Du brauchst.
Das Interface ist dann übrigens anpingbar, die Weboberfläche erreichbar. Nur für OWX_ASYNC existiert es offenbar nicht.

wenn schon die Meckerecke heute geöffnet hat - meine 2 USB Interface an dem. Cubie2 bringen im ASYNC Modus zwar FHEM  nicht zum Absturz, aber letztes Wochenende in Urlaub gefahren, da lieferte eines davon (das aus China) keine Werte mehr. Über VPN shutdown restart - ging kurz, dann wieder keine Werte. Der China Adapter hat keine serial - werde morgen mal gegen einen anderen tauschen und berichten.

Zitat von: det. am 01 August 2014, 18:35:32
wenn schon die Meckerecke heute geöffnet hat

Oh, bitte nicht missverstehen, mein Beitrag vorhin soll kein Meckern gewesen sein...wir testen ja schließlich.

Zitat von: UweH am 01 August 2014, 18:59:53
Oh, bitte nicht missverstehen, mein Beitrag vorhin soll kein Meckern gewesen sein...wir testen ja schließlich.

na... das war ironisch gemeint - wenn wir Dysfunktionen nicht melden, kann sie Norbert auch nicht beseitigen

 :) 8) Jo

Ich hoffe, dass ich am WE noch dazu komme, den dritten LAN/1-Wire-Adapter zusammen zu löten, dann quäle ich OWX_ASYNC mit drei von den Dingern... :o

Zitat von: Peter_64 am 01 August 2014, 12:36:10
Die Einstellungen buspower -> parasitic und maxtimeouts -> 1 denke sollten passen. Gibt es eine alternative die Fühler zu aktivieren ?

Wenn Du die Sensoren in der fhem.cfg umbenennst, dann werden Sie beim Starten bzw. get <...> devices nicht gelöscht. Nur - wenn die Devices bei der Bussuche nicht antworten, dann wahrscheinlich beim normalen Auslesen auch nicht :-(
Ich seh schon, ich muss das mit parasitärer Versorgung selber mal testen...

Zitat von: UweH am 01 August 2014, 18:10:26
Beim Erstellen der Definition eines Interfaces:

Code Auswählen Erweitern

define 1wire_1 OWX_ASYNC xxxxxüber die Kommandozeile geht noch alles gut, beim zweiten friert FHEM ein.

Das muss ich mir erst mal näher ansehen, so aus dem Stegreif habe ich da keine Erklärung für. Zum Glück habe ich ja 2 Ethernet<->1Wire Interfaces zum testen da...

Zitat von: UweH am 01 August 2014, 18:10:26
Dazu muss aber vorher die Stromversorgung der Interfaces kurz unterbrochen bzw. ein Restart des Interfaces durchgeführt werden, sonst gibt's keine Verbindung.[...]meist wieder hergestellt, aber eben auch nicht immer. Dann hilft ein Restart der Interfaces (siehe oben...)

Wenn ein FHEM-seitiger Verbindungsneuaufbau nicht geht, dann liegt das am Interface, das keine neue Verbindung entgegen nimmt, auch wenn die vorherige Verbingung geschlossen wurde. Spätestens beim FHEM-neustart wird der Socket beim beenden des Perl-prozesses zuverlässig geschlossen - wenn das Interface damit nicht klarkommt ist das natürlich schlecht. Deshalb geht es nach einem Interface-reset auch sofort wieder, OWX_ASYNC versucht regelmäßig wieder neu zu verbinden - bis es eben klappt. Wenn das Interface keine neue Verbindung entgegen nimmt, dann kann man FHEM-seitig daran nichts ändern :-(
Eventuell geht es besser, wenn man das Interface nicht als Server laufen läßt, sonder so einstellt, dass OWX_ASYNC einen Serversocket öffnet und das Interface sich dahin verbindet. Im FRM habe ich das so gelöst - das muss ich aber erst ins OWX_ASYNC implementieren...
Wenn die Verbindung erst mal steht, macht es keinen Unterschied.

Gruß,

Norbert

Zitat von: ntruchsess am 03 August 2014, 21:41:43
Wenn ein FHEM-seitiger Verbindungsneuaufbau nicht geht, dann liegt das am Interface, das keine neue Verbindung entgegen nimmt, auch wenn die vorherige Verbingung geschlossen wurde. Spätestens beim FHEM-neustart wird der Socket beim beenden des Perl-prozesses zuverlässig geschlossen - wenn das Interface damit nicht klarkommt ist das natürlich schlecht. Deshalb geht es nach einem Interface-reset auch sofort wieder, OWX_ASYNC versucht regelmäßig wieder neu zu verbinden - bis es eben klappt. Wenn das Interface keine neue Verbindung entgegen nimmt, dann kann man FHEM-seitig daran nichts ändern :-(
Eventuell geht es besser, wenn man das Interface nicht als Server laufen läßt, sonder so einstellt, dass OWX_ASYNC einen Serversocket öffnet und das Interface sich dahin verbindet. Im FRM habe ich das so gelöst - das muss ich aber erst ins OWX_ASYNC implementieren...
Wenn die Verbindung erst mal steht, macht es keinen Unterschied.

Gruß,

Norbert

Hi,

genau das Verhalten  habe ich in der Vergangenheit bei dem Kristech Teil in Verbindung mit socat und OWServer als auch OWX bereits beobachten können, scheinbar nimmt das Interface nach einem Fhem Abbruch keine Verbindungen mehr entgegen oder der 1Wire Busmaster lässt sich nicht neu initialisieren, da das Kristech Teil auch keine Möglichkeit mitbringt es über das Netzwerk neu zu starten ist zwangsweise ein Stecker ziehen notwendig, es sei denn man kann die Stromversorgung anderweitig remote schalten (Homematic etc.) ::) daher fristet es sein Dasein derzeit in der Schublade :( und es werkeln weiter die Raspberrys mit Uwes 1Wire Aufsteckmodul in meinen Unterverteilungen...

Greetz
Eldrik

Hallo Norbert,
Zitat
,,Nur – wenn die Devices bei der Bussuche nicht antworten, dann wahrscheinlich beim normalen Auslesen auch nicht"

Wenn ich die Devices einzeln in die Konsole klopfe sind Sie alle da, und geben richtige Werte aus. Zum Test habe ich Anschluss autocreate deaktiviert um die Devices zu halten, was auch klappte. Beim Schalten des DS2413 (A off) kam eine Fehlermeldung am Modem(habe ich leider nicht mehr), dann ging nichts mehr auch Neustart FHEM und Stromlos/ Adapter brachen nichts. Mit RPI Neustart waren die Modem wieder aktiv, die Bussuche bringt 1 Device von 7 vorhandenen. Ich hoffe die Infos können Dir helfen...

EDIT:
Hier doch noch die Fehlermeldung welche nach kurzem ordentlichen laufen immer kommt.
Modem1
Init Failed: OWX_SER::Detect 1-Wire bus Modem1: interface not detected, answer was 0x03 0x41 0x43 0x03 0x81

Gruß und danke

Hallo zusammen,

Könnte es vlt. sein das man damit der Reconnect funktioniert und das Kristech Teil neue Verbindungen entgegen nimmt einen Timeout definieren muss?
Standardmäßig steht der auf 0 also kein Timeout...
Siehe Screenshot...

den Timeout auf Seiten des Kristech-interfaces zu setzen ist vielversprechend. Kannst Du das mal testen und berichten? Ich hab vorraussichtlich erst am Wochenende wieder die Gelegenheit dazu...

Gruß,

Norbert

Kann ich machen...
wie konstruiere ich denn am sinnvollsten das Problem um es testen zu können?

Hi,

ich würde sagen FHEM starten, Kristech anbinden und FHEM nach dem Einlesen von Sensoren und eines Save von FHEM, hart beenden und danach wieder versuchen normal eine Verbindung herzustellen.

Greetz
Eldrik

Hallo,

Also...
1. im Kristech einen Timeout von 5 Sekunden eingestellt.
2. FHEM hat eine Verbindung und bekommt werte von den DS18B20.
3. killall perl
4. Käffchen geholt.
5. service fhem start

Hier das log...  :-\

2014.08.05 14:48:36 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:48:36 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:48:36 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:48:36 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:48:42 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:48:42 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:48:42 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:48:42 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:48:48 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:48:48 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:48:48 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:48:48 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)


dann mal einen shutdown restart  :-\

2014.08.05 14:56:44 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:44 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:56:44 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:56:44 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_1: interface master DS2480 detected for the first time
2014.08.05 14:56:50 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:50 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:56:50 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:56:50 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_2: interface master DS2480 re-detected
2014.08.05 14:56:50 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:50 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:56:50 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:56:50 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_1: interface master DS2480 detected for the first time
2014.08.05 14:56:56 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:56 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:56:56 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:56:56 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_2: interface master DS2480 re-detected
2014.08.05 14:56:56 3: OWX_ASYNC_Disconnect
2014.08.05 14:56:56 1: 192.168.178.40:23 disconnected, waiting to reappear (1W_IF_ETH_1_1)
2014.08.05 14:56:56 1: 192.168.178.40:23 reappeared (1W_IF_ETH_1_1)
2014.08.05 14:56:56 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_1: interface master DS2480 detected for the first time
2014.08.05 14:57:02 3: OWX_ASYNC_Disconnect
2014.08.05 14:57:02 1: 192.168.178.40:26 disconnected, waiting to reappear (1W_IF_ETH_1_2)
2014.08.05 14:57:02 1: 192.168.178.40:26 reappeared (1W_IF_ETH_1_2)
2014.08.05 14:57:02 3: OWX_SER::Detect 1-Wire bus 1W_IF_ETH_1_2: interface master DS2480 re-detected


Grüße Marius

5 Sekunden Timeout ist wohl etwas arg kurz. Ich weiß ja nicht, was der Timeout genau aussagt, aber wenn es bedeutet, dass nach 5 Sekunden ohne Daten das Interface restartet, dann kann das so nicht funktionieren - dann müsste der Timeout länger sein als die Pausen in der Kommunikation (also länger als das kürzeste eingestellte Interval eines OWX-devices) + Sicherheitszuschlag.

Gruß,

Norbert

Auf den Trichter bin ich dann auch gekommen nachdem ich nochmal drüber nachgedacht habe...  ::)

Hab jetzt mal den Intervall der OWID's auf dem Board auf 60 Sekunden und den Timeout des Kristech Moduls auf 120 Sekunden gestellt...
Sieht vielversprechend aus. Die Verbindung wird nach jedem harten beenden von fhem wieder aufgebaut...

Werde das mal weiter beobachten...

Edit:
Komando zurück...
Das Kristech Modul trennt jetzt alle 120 Sekunden die Verbindung. Auch wenn ein device innerhalb der Zeit abgefragt wird.

Moin,

ich habe das auch grad mal getestet, kann die Erfahrung von corny456 bestätigen. Nach der eingestellten Zeit unterbricht das Modul die Verbindung und OWX_ASYNC baut sie wieder auf.

Wäre auch zu einfach gewesen...  :'(

Hallo Norbert,
mal aktueller Stand...

zu -> einlesen der Sensoren!
Es wird nur ein Sensor von 7 angezeigt (mit get Modem1 ...), aber die 7 manuell angelegten Sensoren laufen seit Tagen stabil und ohne jeden Fehler.

zu ->Reconnect!
Hier habe ich ebenfalls am Kristech den Timeout mit 120 sec. OWID's 60 gesetzt. Nach fhem.cfg speichern kam bei dem Modem disconnect, was auch so blieb, ein anschießender shutdown bringt Init Failed:OWX_SER::Detect 1-Wire bus Modem1:interface not detected answer ...usw. Dann geht nichts mehr, erst wenn ich das Interface stromlos setze und einen shutdown ausführe geht alles wie es soll.

Ich hoffe die Infos können helfen, es läuft ja eigentlich schon ganz gut ...danke.

Kurzes Statement nach einer Woche Betrieb mit drei LAN/1Wire-Interfaces und zeitweise einem WLAN/1Wire-Interface auf Cubieboard 2 über OWX_ASYNC: Läuft!
Da man den China-Interfaces per Weboberfläche einen Restart verpassen kann, ist die Verbindungsaufnahme nach einem shutdown restart kein Problem.

Moin,

ich hatte vor längerer Zeit schon einmal in diesem Thread (Seite 15 oder Umgebung) ein paar Bildchen von meinem WLAN/1-Wire-Interface gezeigt... Auf Grund vieler Anfragen, die mich in den letzten Tagen erreichen (ich hatte das Teil vor kurzem mal erwähnt und nun ploppt es hoch...), hier mal ein paar Daten zum WLAN/1-Wire-Interface. Das WLAN-Modul selbst ist eine Empfehlung von pah (s. irgendwo weiter vorn), der Rest ist SMD-Hühnerfutter. Da die eine Hälfte der Schaltung lieber 5V mag und die andere 3,3V, werden kurzerhand beide Spannungen aus der 12V-Versorgungsspannung mittels Schaltregler gewonnen. Die Pegelanpassung erfolgt mit schnellen Optokopplern. Alles zusammen passt in das bewährte 2-fach Hutschienengehäuse.
Wer sich solch ein Teil zusammenschrauben will, kann die Target-Datei bekommen, ich könnte maximal die Platinen liefern. Zeit für Fertiggeräte u. ä. habe ich leider nicht.

Platine + Bestückungsliste tät's. WiFi-Midul ist ohnehin schon zu mir unterwegs...
Sag an: wie weiter?
Merci & schönen abend!

Auch von meiner seite noch das Statement !

1xLAN/1Wire-Interfaces über OWX_ASYNC:
Alles läuft bestens, 3xds2413, 6 temperature, 1ds2406, auch das einlesen der Sensoren geht bestens auf einmal ?
Danke Tobias

Hallo,

ich habe auch einen Kristech am laufen.

Auch ich habe das Problem, das der Apdater nach einem Verlust der Verbindung keine neue Verbindung akzeptiert. Zwischenzeitlich habe ich Kontakt mit Kristech,
sie konnten das Problem bisher anscheinend nicht reproduzieren.

Mal sehen, was sie zu socat meinen.

Zitat von: Alexander Bauer am 27 August 2014, 22:23:08
Zwischenzeitlich habe ich Kontakt mit Kristech,

Dieser Effekt beschränkt sich aber nicht nur auf die Kristech-Teile, das passiert auch bei meinen China-Adaptern (http://www.wvshare.com/product/UART-ETH-E001.htm (http://www.wvshare.com/product/UART-ETH-E001.htm) und dem WLAN-Interface. Und es ist auch völlig egal, ob die Verbindung von socat aufgebaut wurde oder von OWX_ASYNC. Daher bin ich mal gespannt, ob Kristech eine Lösung anbieten kann...

So,

ich melde mich nach längerer Abstinenz auch wieder zurück.

Habe zwar immer noch zuviel um die Ohren - aber schraube schon wieder ein wenig an den OW...-Modulen.

LG

pah

Hallo zusammen,
nach einem Update heute kam im Log  folgende Fehlermeldung!

2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:03:42 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.09 21:04:10 1: PERL WARNING: Argument "45.2M-BM-0C" isn't numeric in numeric lt (<) at (eval 40) line 1.
2014.10.09 21:04:10 1: PERL WARNING: Argument "45.2M-BM-0C" isn't numeric in numeric gt (>) at (eval 41) line 1.
2014.10.09 21:04:10 1: PERL WARNING: Argument "45.2M-BM-0C" isn't numeric in numeric lt (<) at (eval 46) line 1.

Hat jemand eine Idee an was es liegen kann ?
Ich arbeite mit OWX_ASYNC habe einige Tempfühler und ds2413 dran, hatte keine Fehler vor dem Update ?

Besten Dank im voraus für einen Tipp

an OWX_ASYNC wurde in den letzten 2 Monaten nichts geändert. Du hast ein Device in der fhem.cfg, dessen TYPE mit 'OW' beginnt, das aber keine 'ROM_ID' gesetzt hat: https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/00_OWX_ASYNC.pm#L580

Wie das mit dem Update zusammenhängt, erschließt sich mir erst mal nicht.

Gruß,

Norbert

Hallo Norbert,
ich habe jetzt alle Device durch, alle  OWX - Devices hatten das ROM_ID gesetzt. Bei den beiden Modem OWX_ASYNC steht zweimal FF drin. Die  OWDevice der OWServer haben alle IODev stehen z.B. DS9490r, nur beim OWServer selbst steht bei DS9490r keine IODev.

Hier noch mal ein Auszug vom Log.
Sorry wegen falscher Info... der Fehler ist zum ersten mal bereits am 5.10.2014 ohne Update aufgeschlagen.

Eine Idee ?

2014.10.10 00:16:26 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric gt (>) at (eval 348) line 1.
2014.10.10 00:18:09 0: Server shutdown
2014.10.10 00:18:13 1: Including fhem.cfg
2014.10.10 00:19:59 1: Including ./log/fhem.save
2014.10.10 00:20:12 0: Server started with 61 defined entities (version $Id: fhem.pl 6707 2014-10-08 08:30:15Z rudolfkoenig $, os linux, user fhem, pid 8434)
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric lt (<) at (eval 27) line 1.
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric gt (>) at (eval 28) line 1.
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric lt (<) at (eval 33) line 1.
2014.10.10 00:20:22 1: PERL WARNING: Argument "42.8M-BM-0C" isn't numeric in numeric gt (>) at (eval 34) line 1.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014.10.10 00:20:25 1: PERL WARNING: Use of uninitialized value in substr at ./FHEM/00_OWX_ASYNC.pm line 580.
2014

Hallo an alle,

Zu dem Problem "Init Failed:OWX_SER::Detect 1-Wire bus Modem1:interface not detected answer" konnte ich folgendes bisher feststellen:
Auf meinem System (Raspi - IF-ETH mit Kristech - auf Kanal1: Umweltsensor - Temperatursensor DS18B20 - Auf Kanal2: Switch DS2408 - Module u.a. Stellmotor, Pid20)
wird der Kanal mit den Sensoren jedesmal blockiert wenn innerhalb von ca 10 sec. nach dem Auslesen eines Sensors ein Schaltbefehl zum Switch gesendet wird, dies tritt dummerweise innerhalb weniger Stunden Betrieb mal auf. Zur Zeit lasse ich den PID aus, so werden keine Schaltbefehle gesendet und es läuft seit einigen Tagen problemlos. Zum Test nochmals einige Schaltbefehle von "Hand" gesendet Blockade erfolgte wieder nach dem ein Schaltbefehl in den 10sec.-Fenster lag. Folglich würde ich auf ein Timing- oder ein Puffer-Problem tippen.
Leider fehlt mir die Zeit das momentan weiter zu verfolgen. Vielleicht hat jemand die Zeit das zu Prüfen.

Grüße
Michel

Bitte mal separaten Thread lesen und diese Meldung dort noch einmal posten

http://forum.fhem.de/index.php/topic,27607.0.html

LG

pah

Hi,

kann ich machen aber bitte vorher kurz eine PN.
Ich gehe bis jetzt davon aus, dass es nicht mit OWSwitch zusammenhängt, da:
- bei nicht der Bus mit den Aktoren blockiert sondern der mit den Sensoren (kann weiter schalten aber keine Sensoren mehr auslesen)
- funktioniert erst wieder wenn ich alles stromlos mache (wie hier schon öfters erwähnt)
- Fehler bestand schon vor dem Update von OWSwitch
weswegen ich es hier gepostet habe

Nachtrag:
Getestet OWX mit Socat für beide Kanäle und OWX_Async für beide Kanäle. Mischbetrieb OWX mit Socat für Kanal 1 und OWX_Async für Kanal 2 nicht getestet.
OWSwitch wird mit set xxx output angesprochen.

Grüße
Michel

Moin,

mal ne Frage in die Runde: Benutzt eigentlich jemand ein Ethernet/1-Wire-Interface mit diesem Bauteil: http://www.wvshare.com/product/UART-ETH-E001.htm (http://www.wvshare.com/product/UART-ETH-E001.htm)? Ich habe davon 3, die funktionieren tadellos, trotzdem gibt's ein kleines Problem. Laut Manual (siehe Anhang) gibt es die Möglichkeit, denen per UDP einen Reset-Befehl zu senden...ich habe nur keine Ahnung von der Materie. Kann da jemand weiterhelfen?

Danke und Gruß
Uwe

Sollte mit einem einfachen Call von socat erledigt werden.

LG

pah

Hätte ich jetzt ein Foto von mir gemacht, hättest Du ein Gesicht voller Fragezeichen gesehen  ::)
Socat ist mir ein Begriff und setze ich auch ein, der Rest ist ein Mysterium...

man socat => Optionen nachsehen, um mit einem UDP-Port zu verbinden

echo "HIER DER STRING ZUM RESET" | socat "HIER DIE OPTIONEN ZUM VERBINDEN"

LG

pah

Mach mal ein Foto.

Zitat von: Prof. Dr. Peter Henning am 12 Januar 2015, 19:34:45
Mach mal ein Foto.

Lieber nicht.

Danke für die Hinweise, ich werde mein Glück versuchen.

Hi,

wäre es unter Umständen auch möglich eine Huckepackplatine zu erstellen die für den "Tischeinsatz" gedacht ist?

Ich hätte mehrere Einsatzszenarien für einen solchen Adapter, möchte mir aber ungern ein Hutschienenmodul in mein "LackRack" hängen.

Gehäuse könnte ich erstellen und evtl bald auch Drucken. Muss nur meinen 3D Drucker wieder ans laufen bringen.

Huckepack worauf ?

LG

pah

Das "Huckepack" würde mich auch interessieren, ich kann Dir aber verraten, dass ich sowohl für das WLAN-Modul als auch für das LAN-Modul Platinen habe. Wo Du die reinschraubst, ist ja letztlich Dir überlassen...

achso ja okay :) dachte das versteht man. Mit Huckepack ist gemeint, dass die Platine obendrauf ist. Also so ähnlich wie die bei Uwe nur eben so klein wie möglich.

Im Grunde genommen ist es mir egal worauf... ob kristech oder chinateil. Was meint ihr denn welcher besser ist? Habe den ganzen Thread durchgelesen aber habe keine preferenz rauslesen können.
Wlan brauche ich jetzt nicht da ich erstmal eines in meinem Lackrack im Keller verbauen bzw aufstellen will.

Uwe wie sehen die für die LAN Version denn aus?

Meine Güte, ich habe doch nicht um eine Erklärung des Wortes "Huckepack" nachgesucht  ::)

Sondern es ist dem Post absolut nicht zu entnehmen, was wo drauf sein soll !

pah

Ich habe zu der WIFI-Version eine Wiki-Seite mit Schaltplan erstellt, noch etwas rudimentär: http://www.fhemwiki.de/wiki/1W-IF-WIFI

Interessante Option: Offenbar gibt es ein ESP8266-Funkmodul zukaufen, welches nur 3 € kosten soll und eine serielle Schnittstelle bereitstellt: http://forum.fhem.de/index.php/topic,28905.0.html

LG

pah

Zitat von: Prof. Dr. Peter Henning am 26 Januar 2015, 05:25:09
Meine Güte, ich habe doch nicht um eine Erklärung des Wortes "Huckepack" nachgesucht  ::)

Ich auch nicht, ich war nur etwas überrascht, dass Eddi.B offenbar diesen Thread hier nicht richtig gelesen hat, denn sonst wäre er auf dieses hier (http://forum.fhem.de/index.php/topic,18996.msg156739.html#msg156739) gestossen...Huckepackiger geht's nicht.

Gruß
Uwe

Zitat von: Eddi.B am 25 Januar 2015, 21:00:11
Im Grunde genommen ist es mir egal worauf... ob kristech oder chinateil. Was meint ihr denn welcher besser ist? Habe den ganzen Thread durchgelesen aber habe keine preferenz rauslesen können.

Das ist auch fast egal. Der Kristech hat zwei Ausgänge, ist breiter als der Chinese und inkl. Versand etwa doppelt so teuer. Der Chinamann hat drei Ausgänge (aber nicht nötig...). Was mir beim Chinesen besser gefällt, ist die Möglichkeit, das Modul per Button auf der Webseite zu resetten (geht auch mit einem String per socat, aber da bin ich noch nicht dahintergestiegen). Hat den Vorteil, dass man den Reset-Befehl beim shutdown restart an das Modul senden kann. Geht m.W. beim Kristech nicht.
Hab mir gerade auch noch den hier (http://www.ebay.de/itm/USR-TCP232-E-Serial-Server-RS232-RS485-Auf-Ethernet-TTL-Level-DHCP-Web-Modul-/201223231518?pt=DE_Computing_Parallel_Seriell_PS_2&hash=item2ed9d6d81e) gegönnt und werde mal testen. Das wäre ziemlich preiswert

Zitat von: UweH am 26 Januar 2015, 18:38:53
Ich auch nicht, ich war nur etwas überrascht, dass Eddi.B offenbar diesen Thread hier nicht richtig gelesen hat, denn sonst wäre er auf dieses hier (http://forum.fhem.de/index.php/topic,18996.msg156739.html#msg156739) gestossen...Huckepackiger geht's nicht.

Gruß
Uwe

na selbstverständlich habe ich das Teil gesehen :)

Wenn wir dann schon bei Huckepackiger sind... Es ist viel zu Huckepackig ;-) Ich bräuchte es so klein wie möglich. Deines ist ja für ein Hutschienengehäuse gedacht und dementsprechend dimensioniert.

Zitat von: Eddi.B am 26 Januar 2015, 23:07:42
Ich bräuchte es so klein wie möglich.

Dann empfehle ich Dir Target, Eagle oder DesignSpark.

Gruß
Uwe

Zitat von: UweH am 26 Januar 2015, 18:57:31
Hab mir gerade auch noch den hier (http://www.ebay.de/itm/USR-TCP232-E-Serial-Server-RS232-RS485-Auf-Ethernet-TTL-Level-DHCP-Web-Modul-/201223231518?pt=DE_Computing_Parallel_Seriell_PS_2&hash=item2ed9d6d81e) gegönnt und werde mal testen. Das wäre ziemlich preiswert

Um mich mal selber zu zitieren...  ;) Habe das Teil getestet und funktioniert. Kommt offenbar aus der gleichen Schmiede wie die weiter vorn angesprochenen China-Teile, haben auch alle die gleiche Weboberfäche. Ist sozusagen die Einkanal-Variante. Cool.
Lieferzeit 4 Wochen sind akzeptabel, zumal ohne Versandkosten. Der darf mir gleich noch eins schicken :)

Zitat von: UweH am 27 Januar 2015, 16:27:13
Dann empfehle ich Dir Target, Eagle oder DesignSpark.

Gruß
Uwe

Das selbe dachte ich mir dann auch... habs dann aber gelassen ;)

Was verlangst du für eine LAN Platine?

Moin Mitstreiter,

ich hatte vor kurzem gleich mal das nächste Teil (http://www.ebay.de/itm/251629146345?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT) geordert und es heute bekommen...Test erfolgreich. Funktioniert auch und zudem bisher (glaube ich jedenfalls) das preiswerteste. Witzigerweise die gleiche Anschlussbelegung wie bei dem hier (http://www.ebay.de/itm/USR-TCP232-E-Serial-Server-RS232-RS485-Auf-Ethernet-TTL-Level-DHCP-Web-Modul-/201223231518?pt=DE_Computing_Parallel_Seriell_PS_2&hash=item2ed9d6d81e).

Gruß
Uwe

Hm, ich habe jetzt zwei verschiedene ESP8266 hier liegen und werde es mit denen probieren. Anscheinend kann man die sogar neu flashen, jedenfalls gibt es diverse Ausgaben der Firmware im Netz.

Kosten nur ca. 5 Euro.

LG

pah

Hallo pah,

wir sollten eine alternative Firmware für das ESP8266 Funkmodul in Betracht ziehen.
https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en

Hiermit kann der WiFi-Modus konfiguriert werden:
wifi.setmode()
dann folgt die Verbindung mit dem AP:
wifi.sta.config()
wifi.sta.connect()
und zum Schluss noch die UART-Konfiguration:
uart.setup()

Der Vorteil wäre, dass bei Spannungsverlust die Konfiguration erhalten bleibt und bei Spannungsaufbau das "1W-ESP8266-Interface" ein Reconnect zum AP durchführt.

Uff, noch ein Untersystem zum Flashen :-((

Eigentlich habe ich dafür zu viele Baustellen. Neben dem Original  habe ich jetzt auch einen ESP8266-3 da. Für den gibt es witzige Experimentalboards: http://www.limpkin.fr/index.php?post/2014/11/27/A-Development-Board-for-the-ESP8266-03

Ich will dieses Modul aber lieber auf eine Mini-Platine lösten mit direktem 1-Wire Busmaster. Das wäre DIE Aktor/Sensorplattform.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2015, 12:22:26
ich will dieses Modul aber lieber auf eine Mini-Platine lösten mit direktem 1-Wire Busmaster. Das wäre DIE Aktor/Sensorplattform.

Was mir momentan nicht ganz einleuchtet...was ist mit dem hier (http://forum.fhem.de/index.php/topic,18996.msg143181.html#msg143181)? Damit lief es doch (und läuft bei mir) und nix mit flashen. Mal vom Preis abgesehen und dem vielleicht etwas höheren Stromverbrauch.
Mit sinkendem Preis lässt der Comfort nach... Sehe ich jetzt aktuell bei dem Ethernet-Interface, was ich gestern in Betrieb genommen habe. Funktioniert zwar, aber es hat keinen http-Zugang und lässt sich auch nicht über externe Befehle ansprechen.

Gruß
Uwe

Oh, DAS DA ist bei mir im produktiven Einsatz in der Garage...

Ich spiele nur gerne herum - und ein WIFI-Interface für 5 Euro ist einfach unschlagbar. Vielleicht kann ich damit auch einen EBUS-Koppler für weniger al s10 Euro realisieren. Und wenn nicht, liegt das einfach jahrelang in der Bastelkiste.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 21 Februar 2015, 14:17:01
Ich spiele nur gerne herum

Kommt mir bekannt vor  ;D

Ich hatte nur den Eindruck, was Entscheidendes verpasst zu haben, da sich die ESP8266-Geschichte in zwei Threads abspielt...
Jetzt bin ich im Bilde  :)
Danke

Ich glaube hier hat jemand die Idee aufgegriffen oder zumindest analoge Gedanken:

http://www.hobby-boards.com/store/products.php?product=Wireless-Master (http://www.hobby-boards.com/store/products.php?product=Wireless-Master)
http://www.hobby-boards.com/store/products.php?product=Wireless-Daughter-Card (http://www.hobby-boards.com/store/products.php?product=Wireless-Daughter-Card)

Das ist doch eine Nebelkerze ! Was dort angeboten wird, gibt es seit Monaten hier im Thread.

LG

pah

Sorry .. wollte keine Schleichwerbung machen oder ... Nebelkerzen ... werfen.
War nur als Info was es sonst noch so gibt gedacht.
Ich finde das hier im Forum diskutierte Interface besser und vor allem günstiger und nicht propietär.
Sobald die ganzen Bauteile aus Fernost eingetroffen sind löte ich mir auch ein paar davon.

Zitat von: locutus am 21 Februar 2015, 10:13:18
Hallo pah,

wir sollten eine alternative Firmware für das ESP8266 Funkmodul in Betracht ziehen.
https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en

Hiermit kann der WiFi-Modus konfiguriert werden:

Code Auswählen Erweitern

wifi.setmode()
dann folgt die Verbindung mit dem AP:

Code Auswählen Erweitern

wifi.sta.config()
wifi.sta.connect()
und zum Schluss noch die UART-Konfiguration:

Code Auswählen Erweitern

uart.setup()

Der Vorteil wäre, dass bei Spannungsverlust die Konfiguration erhalten bleibt und bei Spannungsaufbau das "1W-ESP8266-Interface" ein Reconnect zum AP durchführt.

Das geht doch alles mid der Standard-Firmware auch oder täusch ich mich da?
Über die AT-Kommandos kann man doch auch alles einstellen und es bleibt erhalten.

Hallo Technikinteressierte und Kreative,
ich möchte euch ein weiteres 1-Wire Interface mit dem ESP8266-WLAN-Funkmodul (http://www.mikrocontroller.net/articles/ESP8266) vorstellen.
Grundkenntnisse in der Handhabung des ESP8266-Funkmoduls und einen USB zu TTL-Konverter mit 3,3V-Logik setze ich voraus. Und hier die Kurzanleitung ...

Die Zutaten:
DS2480B (Serial to 1-Wire Line Driver)
ESP8266 (ESP-01)
5V-zu-3,3V Pegelwandler (Logic Level Converter)
3,3V Spannungsquelle
5V Spannungsquelle

1. Verbindung ins lokale Netzwerk herstellen
Zuerst sollte das ESP8266-Funkmodul mittels AT-Befehl eine Verbindung ins lokale Netzwerk herstellen.

Test Kommando
AT gibt ein "OK" zurück

Reset des Moduls
AT+RST

Setzen des WiFi-Betriebsmodus: 1=Station, 2=Access Point, 3=Beides
AT+CWMODE=<mode>

Verbinden mit WiFi-Netzwerk
AT+CWJAP="<access_point_name>","<password>"

Ausgabe der eigenen IP-Adresse
AT+CIFSR

Die IP-Adresse ist nun bekannt. Bitte vorsichtshalber einmal das Funkmodul von der 3,3V Spannungsversorgung trennen, dann wieder Spannung anlegen und die IP-Adresse des Funkmoduls anpingen.

2. Installation der ESP8266-transparent-bridge Firmware
Es werden ein ESP8266-Flash-Tool (z.B. NodeMCU Flasher) und die beiden binären Dateien benötigt:
https://github.com/beckdac/ESP8266-transparent-bridge/tree/master/firmware

Dabei sind die Offsets 0x00000 und 0x40000 zu beachten:
0x00000.bin in 0x00000
0x40000.bin in 0x40000

Nun muss das Funkmodul in den "boot mode" versetzt und die neue Firmware installiert werden. Dazu wird GPIO0 auf GND gelegt.
Nach dem der Chip erfolgreich geflasht wurde, wird die Verbindung zur Spannungsversorgung getrennt. Danach wird die Verbindung zwischen GPIO0 und GND getrennt.

3. Konfiguration der TCP zu UART-Brücke
Die ESP8266-transparent-bridge (https://github.com/beckdac/ESP8266-transparent-bridge) lässt sich komfortabel via Telent konfigurieren:
telnet 192.168.xxx.xxx:23

Entscheidend ist die Wahl der korrekten Baudrate - der DS2480B kommuniziert mit 9600 Baud.
Dieses Kommando gibt die Einstellungen aus:
+++AT BAUD

Dieser Befehl ändert die Einstellungen:
+++AT BAUD 9600

4. Das 1W-ESP8266-Interface
Jetzt kann das Funkmodul an den Busmaster angeschlossen werden. esp8266_ds2480b.jpg als Bsp. zur Veranschaulichung. Farbkodierung der Drähte:
rot: 5V
orange: 3,3V
schwarz: GND
gelb: 1-Wire
grün: TX
violett: RX

5. Einbindung in FHEM
Die Vorgehensweise wurde bereits von pah beschrieben. Hier noch kurz erläutert:

/etc/init.d/fhem editieren:
socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.xxx.xxx:23 &
sleep 2
pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
chmod 666 $pty

FHEM Definition:
define 1W_WIFI OWX /dev/vmodem0

Oder mit OWX_ASYNC:
define 1W_WIFI OWX_ASYNC 192.168.xxx.xxx:23

Hallo

@locutus einfach Spitze!

Ich verfolge das Thema hier sehr interessiert!!! und habe zum Basteln schon fast alles geordert.
Zu den DS2480B finde ich leider nur fuchs.shop.com als "einfache Bezugsquelle", oder woher bezieht Ihr das Bauteil?

Wäre für spätere Entwicklungen der DS 2482-100S, im Bezug zu 1Wire, nicht besser geeignet (3,3V, Preis und Verfügbarkeit)?
Das ESP8266-Funkmodul, ESP8266-ESP03 mehr I/Os,  scheint I2C in Software zu können.
Oder verstehe ich irgendwas falsch?

CK

Meine Bauteile kommen auch von Fuchs.

Es bleibt dir überlassen, welches Funkmodul du verwendest.
Beim ESP-03 wird sehr oft die schlechte Funkreichweite der Keramikantenne bemängelt. Dann doch lieber das ESP-07 oder ESP-12 Funkmodul.

Das neuartige 1-Wire Interface arbeitet mit einer seriellen Schnittstelle und mir ist kein I2C-to-LAN Converter bekannt.

Danke

ZitatDas neuartige 1-Wire Interface arbeitet mit einer seriellen Schnittstelle und mir ist kein I2C-to-LAN Converter bekannt.

Ich meinte ESP8266 (z.B.ESP-07 ) --> DS 2482 --> 1Wire
Meine Infos zu I2C habe ich von hier https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en (https://github.com/nodemcu/nodemcu-firmware/wiki/nodemcu_api_en)

CK

Der I2C-Bus wird zwar unterstützt, aber wo sind die LUA-Quellcodes für den DS2482? Ich bin schon an der tcp2uart (https://github.com/nodemcu/nodemcu-firmware/blob/master/lua_examples/tcp2uart.lua)-Brücke mit NodeMCU gescheitert. I2C-Bus mit NodeMCU, daran wage ich momentan nicht zu denken.

Ich verstehe ein bisschen Bahnhof

"LUA-Quellcode"  mein (neues, I2C) Programm im Flash?

Ansonsten trifft für mich zu, erst mal alles haben, zusammenbauen und verstehen!!!
Ein "Ethernet to Serial Port RJ45-Modul" ist bei mir auch noch unterwegs, was mit einem DS2480B ausgestattet werden will.

CK

Zitat von: le66ck am 14 März 2015, 12:50:02
Ein "Ethernet to Serial Port RJ45-Modul" ist bei mir auch noch unterwegs, was mit einem DS2480B ausgestattet werden will.

Dafür hab ich Platinen gehäkelt. Passend für dieses Gehäuse  (http://www.conrad.de/ce/de/product/530730/Hutschienen-Gehaeuse-Kunststoff-Grau-RAL-7035-35-x-86-x-60-PN-5200100035-1-St)und dieses (http://www.ebay.de/itm/USR-TCP232-E-Serial-Server-RS232-RS485-Auf-Ethernet-TTL-Level-DHCP-Web-Modul-/201223231518?pt=DE_Computing_Parallel_Seriell_PS_2&hash=item2ed9d6d81e) und dieses (http://www.ebay.de/itm/251629146345?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT) und dieses (http://www.wvshare.com/product/UART-ETH-E001.htm) Interface. Bei Interesse bitte PM.
Auf dem Foto rechts der Platinensatz (3Stück) und oben ein Komplettgerät ohne Gehäuse.

Hallo UweH

Gibts dazu noch einen gehäkelten Schaltplan?
Ich hab das Modul bestellt http://www.ebay.de/itm/251629146345?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/251629146345?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
Sollte passen!?

CK

Zitat von: le66ck am 14 März 2015, 13:38:41
Gibts dazu noch einen gehäkelten Schaltplan?

Ja

Zitat
Sollte passen!?

Ja. Witzigerweise steckt bei dem Foto ebendieses Interface drauf.

ZitatGibts dazu noch einen gehäkelten Schaltplan?
Ja

Per PM oder wo?
Würde gerne vorher draufschauen!

CK

Zitat von: le66ck am 14 März 2015, 13:59:01
Würde gerne vorher draufschauen!

Ahhh...

Auf dem Bild erkenne ich IC2 bzw 4 nicht ?

sind da

Zitat von: UweH am 14 März 2015, 14:53:21
sind da

(http://forum.fhem.de/Smileys/default/wink.gif)

Übrigens findet man alle Daten dazu im Datenblatt des DS2480.

Darin als IC2 und IC4 gekennzeichnet?
(http://forum.fhem.de/Smileys/default/huh.gif)

 ::)

@pah: Ja...

Ein Batteriebetrieb ist mit der Vorgestellten Methode von locotus leider nicht sinnvoll möglich, sehe ich das richtig?

Das Kristech Interface verbraucht ca. 170mA, das eBay Ethernet-to-TTL Modul ca. 180mA, das USR-WIFI232 Modul bis zu 300mA, der ESP8266 bis zu 215mA. Den 1-Wire-Bus an der Batterie zu betreiben, halte ich für unpraktisch.

Kommt auf die Batterie an....

Außerdem sollte es möglich sein (z.B. durch ein 1-Wire Timing Device, gibt es), ein solches Gerät alle 5 Minuten aufzuwecken.

LG

pah

Hallo,
ich möchte euch ein weiteres 1-Wire Interface vorstellen. Dieses Mal ein Interface, das auf der Frequenz von 434 MHz funkt. Die Funkmodule werden unter der Bezeichnung HC-11 (http://www.elecrow.com/download/HC-11.pdf) angeboten und sind relativ unkompliziert in der Handhabung. Herstellerseitig ist schon die korrekte Rate von 9600 Baud eingestellt. Wer dennoch die Einstellungen verändern möchte, kann dies mittels AT-Kommando bewerkstelligen.

Variante Nr. 1
- ein HC-11 Funkmodul verbunden mit dem GPIO-UART-Port des Raspberry Pi
- ein zweites HC-11 Funkmodul verbunden mit dem DS2480B
define 1W_RF OWX /dev/ttyAMA0

Variante Nr. 2
- ein HC-11 Funkmodul verbunden mit einem USB zu TTL-Adapter (FTDI FT232RL) am Hostrechner
- ein zweites HC-11 Funkmodul verbunden mit dem DS2480B
define 1W_RF OWX /dev/ttyUSB0

Variante Nr. 3
- ein HC-11-USB am Hostrechner
- ein HC-11 Funkmodul verbunden mit dem DS2480B
define 1W_RF OWX /dev/ttyACM0

Ich habe dasselbe noch mit einem Bluetooth-Modul vor - liegt seit Monaten bei mir herum.

LG

pah

Bei mir auch...  ::)

Hallo Zusammen
und schöne Oster,

Hallo UweH,

ich würde gern auf Deinen Post#84 zurück kommen.
Wie funktioniert das mit dem Reset auf Werkseinstellung beim UART-ETH-E001 von Waveshare Electronics.
Ich kämpfe gerade mit dem Teil.

Danke
Viele Grüße
Iron

Im laufenden Betrieb mit einem Draht GND und Reload für ca. 2 sek brücken. Dann lädt das Teil die Werkseinstellungen und lässt sich über das Softwaretool wieder im Netz finden. Unbedingt die Software-Version 1.4.3.0 benutzen, die Vorversion ist fehlerhaft.

Gruß
Uwe

Hallo,

vielen Dank für die Antwort.
Der Schaltplan im Wiki zum 1W-IF-ETH, funktioniert der auch mit dem UART-ETH-E001 von Waveshare Electronics ich habe kein anderen im Forum gefunden.
Oder sind da Änderungen notwendig da im Forum ein anderer Schaltplan gehandelt wird.

Viele Grüße

Woher soll ich das denn wissen ?

pah

Hallo,

ich habe den UART-ETH-E001 mit dem Schaltplan aus dem Wiki zum 1W-IF-ETH zum laufen bekommen aber nur einen Kanal (Port23) läuft auch seit ein paar Tagen stabil. Leider kann ich das vom Port 26 nicht behaupten der will einfach nicht laufen.
Allerdings hatte ich mit "vmodem" kein erfolgt ich habe es mit den folgenden Einstellungen geschafft:

define 1wireEHT1 OWX_ASYNC 192.168.2.133:23
attr 1wireEHT1 buspower real
define 1wireEHT2 OWX_ASYNC 192.168.2.133:26
attr 1wireEHT2 buspower real

Nur beim Port 26 habe ich keinen erfolgt.
Nachfolgend Auszug aus dem Log:


2015.04.12 09:47:59 3: Opening 1wireEHT1 device 192.168.2.133:23
2015.04.12 09:47:59 3: 1wireEHT1 device opened
2015.04.12 09:48:10 3: OWX_SER::Detect 1-Wire bus 1wireEHT1: interface master DS2480 detected for the first time
2015.04.12 09:48:10 3: Opening 1wireEHT2 device 192.168.2.133:26
2015.04.12 09:48:10 3: 1wireEHT2 device opened
2015.04.12 09:50:51 3: OWX_SER::Detect 1-Wire bus 1wireEHT2: interface not detected, answer was
2015.04.12 09:50:51 1: PERL WARNING: Use of uninitialized value $interface in string eq at ./FHEM/OWX_SER.pm line 288.
2015.04.12 09:50:51 1: PERL WARNING: Use of uninitialized value $interface in string eq at ./FHEM/OWX_SER.pm line 290.
2015.04.12 09:51:01 3: NTFY return:  1wireEHT2:OWX_ASYNC_Init failed: OWX_SER::Detect 1-Wire bus 1wireEHT2: interface not detected, answer was
Es wird der Port 26 geöffnet findet aber den DS2480 nicht, den DS2480 habe ich schon ausgetauscht.
Trotz der Zahlreichen Informationen im Forum zum Thema bin ich nicht zu einer Lösung gekommen.
Vielleicht hat einer eine Idee woran es liegen kann.

Viele Grüße

Wenn die beiden Porteinstellungen identisch sind und Du den DS2480 schon getauscht hast, bleibt eigentlich nur ein Fehler auf der Platine / Verdrahtung. Falls es möglich ist, speise doch den nicht funktionierenden DS2480 mit dem funktionierenden Port ein und umgekehrt, um das Problem einzugrenzen.

Gruß
Uwe

Zitat von: locutus am 22 März 2015, 00:19:23ich möchte euch ein weiteres 1-Wire Interface vorstellen. Dieses Mal ein Interface, das auf der Frequenz von 434 MHz funkt. Die Funkmodule werden unter der Bezeichnung HC-11 (http://www.elecrow.com/download/HC-11.pdf) angeboten und sind relativ unkompliziert in der Handhabung. Herstellerseitig ist schon die korrekte Rate von 9600 Baud eingestellt. Wer dennoch die Einstellungen verändern möchte, kann dies mittels AT-Kommando bewerkstelligen.Variante Nr. 3
- ein HC-11-USB am Hostrechner

Wäre das also ein http://www.ebay.de/itm/1Stk-HC-11-USB-CC1101-433Mhz-Wireless-Transceiver-Modul-Neu-/181522242890 ?

Zitat von: AT+UPDATEPut the module in the status of waiting for software update.
After sending the command, the module will not respond to command any more, until it is re-energized.
After serial port assistant sends this command, close the serial port, select file in HC11 updater, and open the serial port.
Then the module can update software version.

Konnte hier schon jemand eine Firmware einspielen oder gar erstellen, welche dieses Modul (mit USB-Anbindung per FTDI?) einfach getaktete Bitstreams à la LIRC zur Steuerung beliebiger 433MHz-AM-bedienter Geräte senden lässt?
(Burst aus 512 Bit internem Puffer kann CC1101 ja ohne weitere Last für den Host...)

http://www.harctoolbox.org/lirc_rpi.html (endlich zur Laufzeit abschaltbarer Softcarrier) ist ja auch eine interessante Entwicklung für den "eierlegenden Wollmilchtransceiver", wenn man 3.3V-RF-Module findet, da die ARM-GPIOs anders als Arduinos ja nicht 5V-tolerant sind.

Hallo Uwe,

ZitatWenn die beiden Porteinstellungen identisch sind und Du den DS2480 schon getauscht hast, bleibt eigentlich nur ein Fehler auf der Platine / Verdrahtung. Falls es möglich ist, speise doch den nicht funktionierenden DS2480 mit dem funktionierenden Port ein und umgekehrt, um das Problem einzugrenzen.

Danke für die Unterstützung.
Funktioniert nun, aber frage bitte nicht woran es gelegen hat. Beim Tausch der Anschlüsse hat jeder für sich funktioniert aber nicht zusammen,
am nächsten Tag haben plötzlich beide Ports funktioniert, es hat sich vom Grundsatz her nichts verändert?????

Grüße
Iron 

Nun ja, 99% aller Computerfehler beginnen mit dem Statement "Ich habe doch gar nichts geändert...".

LG

pah

Zitat von: Dime am 18 April 2015, 13:51:46
Wäre das also ein http://www.ebay.de/itm/1Stk-HC-11-USB-CC1101-433Mhz-Wireless-Transceiver-Modul-Neu-/181522242890 ?Konnte hier schon jemand eine Firmware einspielen oder gar erstellen, welche dieses Modul (mit USB-Anbindung per FTDI?) einfach getaktete Bitstreams à la LIRC zur Steuerung beliebiger 433MHz-AM-bedienter Geräte senden lässt?
...
http://www.harctoolbox.org/lirc_rpi.html (endlich zur Laufzeit abschaltbarer Softcarrier) ist ja auch eine interessante Entwicklung für den "eierlegenden Wollmilchtransceiver", wenn man 3.3V-RF-Module findet, da die ARM-GPIOs anders als Arduinos ja nicht 5V-tolerant sind.

Zitat von: Prof. Dr. Olaf Droegehornhttps://groups.google.com/d/msg/fhem-users/nONFmfFVdmg/DaW5IAKh7PsJ 16.10.2011
Seit heute kann die Firmware für CUNOv2 nun auch Infrarot SENDEN.
Dazu habe ich eine neue Firmware im CVS eingestellt.

Nun steht http://busware.de/tiki-index.php?page=CUNO ja vor der Ablösung durch http://busware.de/tiki-index.php?page=CUNX.
Wie sieht's darauf denn mit dem IR-Transceiver aus?

Ein kurzes Update zum Stand der Hardwareentwicklung:
Der Prototyp des 1-Wire Interfaces mit dem ESP8266-WLAN-Funkmodul (http://forum.fhem.de/index.php/topic,18996.msg273097.html#msg273097) ist nun funktionsfähig. Die Schaltung ist auf ein Minimum an Bauteilen reduziert. Die Spannungsversorgung erfolgt wahlweise über ein externes 9-12V Wechselspannungsnetzteil oder über ein 5V Gleichstromnetzteil. Die Platine passt in ein Hutschienengehäuse.

Ich werde die Platine überarbeiten. Die nichtkommerzielle Fertigung und der Verkauf sind ab Herbst geplant.
Eventuell wird es in Zukunft eine Erweiterungsplatine für das 1-Wire Interface geben.

Coole Sache :)
Hast du schon den voraussichtlichen Preis festgelegt?

OK, Schaltplan ? Wiki-Seite ?

LG

pah

Zitat von: Kuzl am 02 März 2015, 11:06:57
Das geht doch alles mit der Standard-Firmware auch oder täusch ich mich da?
Über die AT-Kommandos kann man doch auch alles einstellen und es bleibt erhalten.

Hallo Kuzl,

wenn Du da etwas hast, würde mich das interessieren, bei mir (http://forum.fhem.de/index.php/topic,28905.msg299250.html#msg299250) habe ich das noch nicht hinbekommen (FW 0.9.2.4).

Danke + Gruß

PeMue

Hab da leider nichts :D wird soviel ich weis die UART-Bridge benötigt, die alles direkt auf den UART ausgibt, was über TCP kommt. Mit den sachen die die AT-Firmware ausgibt kann ein anderes Bauteil leider nix anfangen.

Hab auch ein ESP8266-07 Modul mit der "transparent bridge" Firmware im Einsatz. Funktioniert echt super!
Mit der "normalen" Firmware (nennt sich auch "AT firmware", http://www.electrodragon.com/w/ESP8266_Firmware) funktioniert es nicht, da diese den AT Overhead hat und deswegen die UART Daten - wie der Name schon sagt - nur mit AT Befehlen übertragen werden können.

Hier ist die transparente Bridge gut beschrieben:
https://github.com/beckdac/ESP8266-transparent-bridge


Ich hab mir auch eine PCB mit ESP8266-07, 1-Wire Master (DS2480+), schöner Spannungsversorgung sowie ATtiny44 als 1-Wire Slave gemacht.
Die Anregungen kamen von diesen Beiträgen:
http://forum.fhem.de/index.php/topic,22431.msg158105.html#msg158105
http://www.fhemwiki.de/wiki/1W-IF-WIFI

Näheres folgt Ende der Woche.

Das ESP8266-07 <-> DS2480 Busmaster Board, das ich designed habe, läuft jetzt.

Hier habe ich es grob beschrieben:
http://forum.fhem.de/index.php/topic,38024.0.html

Wie ist denn der Stromverbrauch des Teils ?

LG

pah

Zitat von: Prof. Dr. Peter Henning am 11 Juni 2015, 05:47:17
Wie ist denn der Stromverbrauch des Teils ?

In der Konfiguration mit 5V Spannungsversorgung, ATTiny als DS2423 und zwei Komparatoren liegt der mittlere Stromverbrauch bei ~50mA, die Peaks bei ca. 330mA.
In angefügten Bild sind die Strompeaks des ESP8266 gut zu sehen.
[attachthumb=1]

Für ein USB Netzteil ist das kein Problem - für Batteriebetrieb ist es eindeutig zu viel, aber die Schaltung ist auch nicht auf Stromverbrauch optimiert...


Beste Grüße,
doubh

---

PS: dummy Frage, aber wie füge für ich ein Bild direkt in ein Thema ein und nicht nur als Anlage...?

Zitat von: doubh am 11 Juni 2015, 08:55:14
PS: dummy Frage, aber wie füge für ich ein Bild direkt in ein Thema ein und nicht nur als Anlage...?

Mit dem IMG-Tag. Das Bild muss entweder auf einem externen Server liegen, oder Du hängst das hier ein, speicherst, klickst auf das Bild, kopierst die Link-Adresse und editierst den Beitrag zum Einfügen von IMG-Tag ;)

mal ne generelle Frage:
Ist es möglich von mehreren fhem Instanzen gleichzeitig auf die Bridge zuzugreifen?

Gruß,
Kuzl

Und was sollte dann Kollisionen verhindern ?

LG

pah

Zitat von: doubh am 11 Juni 2015, 08:55:14
PS: dummy Frage, aber wie füge für ich ein Bild direkt in ein Thema ein und nicht nur als Anlage...?

so: (http://forum.fhem.de/index.php?action=dlattach;topic=18996.0;attach=33294;image)
- Post abschicken
- den Post anschauen, auf die Grafik klicken und mit dem img Tag einbinden ODER
- einen externen Server verwenden.

Gruß PeMue

Wenn fhem die "serielle schnittstelle" belegt kann ja das andere fhem nicht darauf zugreifen. allerdings weiß ich nicht, ob das auch für socat gilt und ob fhem die schnittstelle dauerhaft belegt.

Auch wenn das wieder freigegeben würde (was nicht der Fall ist...), kann man das nicht ohne Weiteres durch ein anderes Programm bedienen.

LG

pah

Alles klar, danke für die Info.

Dann bleibt wohl für mehrere FHEM im Haus nur ein Raspberry Pi mit OWFS oder das ganze über FHEM2FHEM zu verteilen.

VG
Kuzl

Separate FHEM-Instanzen habe ich nur zu Sicherheitszwecken (Lämrpegelmessung nach außen sichtbar). Das Verteilen auf verschiedene Anzeige.-und Bediengeräte im Haus mache ich mit _einer_ FHEM-Instanz und einem Apache-Webserver.

LG

pah

okay das würde sich schon regeln lassen... allerdings ist mir gestern abend noch ne ganz andere Idee gekommen:
Man könnte doch auf einen Busmaster verzichten und die komplette Verwaltung der Sensoren auch vom ESP8266 machen lassen. Der kann dann für jeden Sensor über MQTT einen Topic anlegen der dann im Netzwerk entsprechend ausgelesen und bedient werden kann.

Für Temperatur- und Feuchtigkeitssensoren mit Sicherheit sehr einfach umsetzbar. Würde halt den relativ teueren Busmaster sparen und für manche, die nur Temperatursensoren haben ausreichend. Ich probier das ganze in nächster Zeit mal aus.

Was ist denn an einem Busmaster für 10 Euro teuer ?

Außerdem halte ich es für Unsinn, das ganze 1-Wire-Protokoll in einem ESP abwickeln zu wollen.

pah

Naja da kommt ja noch das netzteil und versandkosten dazu. Ich hab den busmaster nur bei händlern gefunden die 5€ versandkosten verlangen, dann kommt allein dieser schon auf 10€. Und wenn ich mir die sparen kann, warum nicht. Wie gesagt natürlich hat das ganze dann weitaus weniger funktionsumfang aber für reine temperatur und feuchtigkeitssachen reicht das

Dann kauf den Kram doch in China.
Guckst du hier:
http://de.aliexpress.com/item/Free-Shipping-DS2480B-DS2480-original-SOP8-in-stock/1907670034.html (http://de.aliexpress.com/item/Free-Shipping-DS2480B-DS2480-original-SOP8-in-stock/1907670034.html)

Für 14$ inc. Versand bekommst du 5 Stück.
Dauert eben nur ca. einen Monat.
Da rechnet sich sogar eine Fehllieferung. Da sollte man beim freundlichen Chinesen nämlich aufpassen.
Den Gewinn den der deutsche Händler macht kann ich auch selbst einstecken.

Für einfache Aufgaben wie Temperatur- und Feuchtemessung braucht man auch kein Netzteil.

LG

pah

wenn mehr als 3-4 sensoren hat schon, hab ich schon ernüchternd getestet

Das ist sicher nicht richtig.
Eine Versorgung über die Spannung des USB ist problemlos möglich, hier fließen Ströme von wenigen mA.

LG

pah

Ich hatte gedacht du meinst Batterien.
Über USB geht es auch mit deinem Wlan-1-wire-Interface... allerdings stellt sich mir dann die Frage: Warum dann WLAN???
Dann kann man auch gleich ein USB-Interface benützen

Natürlich braucht man für das WLAN-Interface eine externe Spannung - ich hatte eines mit USB-Anschluss gemeint.

LG

pah

Dann war das wohl ein Missverständnis :D
Ich werde einen noch freien Slot von einem 4-fach USB-Netzteil verwenden.

Ich habe so etwas hier mit Tapete überzogen und neben ein Tablet-Display an die Wand geklebt:

http://www.conrad.biz/ce/de/product/511575/ACDC-Printnetzteil-Mean-Well-PM-05-5-5-VDC-1-A-5-W?ref=searchDetail

Hoher WAF.

LG

pah

Ein wenig später als angekündigt (http://forum.fhem.de/index.php/topic,18996.msg297787.html#msg297787) ist nun endlich das 1-Wire-Interface in geringer Stückzahl verfügbar.

Verfügbarkeit und Preise:
http://forum.fhem.de/index.php/topic,47184.0.html

Hallo Leute!

ich habe mit auch einen HC-11-USB zugelegt und bekomme ihn leider nicht zum Laufen.
Bei mir hängt via USB an einem Raspberry Pi3, auf dem FHEM läuft. Die Geräte /dev/ttyACM0 und /dev/ttyAMA0 sind vorhanden, rechte zwecks der Einfachheit auf 777 gestellt.

Zitat von: locutus am 22 März 2015, 00:19:23
Hallo,
ich möchte euch ein weiteres 1-Wire Interface vorstellen. Dieses Mal ein Interface, das auf der Frequenz von 434 MHz funkt. Die Funkmodule werden unter der Bezeichnung HC-11 (http://www.elecrow.com/download/HC-11.pdf) angeboten und sind relativ unkompliziert in der Handhabung. Herstellerseitig ist schon die korrekte Rate von 9600 Baud eingestellt. Wer dennoch die Einstellungen verändern möchte, kann dies mittels AT-Kommando bewerkstelligen.

....

Variante Nr. 3
- ein HC-11-USB am Hostrechner
- ein HC-11 Funkmodul verbunden mit dem DS2480B

Code Auswählen Erweitern

define 1W_RF OWX /dev/ttyACM0

Wenn ich das gerät im FHEM anlegen will erhalte ich die Fehlermeldung "OWX: 1-Wire bus 1W_RF: interface not found, answer was" - und dahinter nix mehr. Das ganze läuft dann in einer Endlosschleife und blockiert FHEM bis ich es abschieße und neu starte..

Hat jemand eine Idee wie ich hier am besten vorgehen sollte?

Danke!

lg,
Dragon

Interface not found gibt es, wenn der DS2480B nicht antwortet.

Tipp zum Vorgehen: auf der DS2480B-Seite statt des DS2480B einen Computer mit serieller Schnittstelle anschließen (z.B. einen weiteren Raspberry Pi) und schauen, ob überhaupt irgend etwas durchkommt.

LG

pah

Hallo PAH,

ich denke ich hab hier einen totalen Exoten erwischt.
Der CC1101 ist verbaut, und am Gehäuse steht auch HC-11-USB. Aber so wie ich bisher die Beschreibung gelesen hab im Foum, dürfte da keine Intelligenz drinnen stecken.
Allerdings ist da einerseits ein STM32 verbaut und beim Transceiver Modul ein STM8S003F3.
(siehe Fotos unter https://cloud.shadowghost.net/index.php/s/jJ3ItEQdKRV69BO )

Ist der dann überhaupt von FHEM ansprechbar?

lg,
Dragon

FHEM sollte davon gar nichts sehen - sondern nur eine serielle Schnittstelle (UART), an der (über welche Funk- oder Kabeklstrecke auch immer) ein DS2480B hängt.

Das scheint nicht ordentlich zu funktionieren, muss also als Erstes getestet werden.

Ich kenne diesen speziellen Funktransceiver nicht (und hab auch keine Zeit, ihn mir anzusehen). In der Bedienungsanleitung sollte man nach "Transparent UART Mode" Ausschau halten, ggf. muss das erst eingestellt werden.

LG

pah

Also ich kann mit dem Modul, bem drücken einer seitlichen Taste via AT Kommandos kommunizieren / sprich Baudrate usw... umstellen.
(Habs ab 9600 gelassen - weil ich gesehen habe, dass das auch die default Baudrate ist mit der das Perl-Modul kommuniziert).

Der Modus "transparent UART Mode" ist aktiv - lustigerweise kann ich den gar nicht abschalten (was mich etwas wundert - weil das Kommando existiert)

ich fürchte fast, dass das Modul selbst etwas hat.

Hallo zusammen,

ich habe das 1-Wire-Interface mit dem ESP8266-WLAN-Funkmodul redesignt und auf die Größe eines USB-Sticks reduziert.
Der Stick kann entweder als normaler COM-zu-1W-Busmaster oder aber als 1W-WLAN-Bridge fungieren. Die Betriebsart wird mittels Schalter gewählt. In der Betriebsart WLAN ist der USB-Stick nicht mehr auf einen lokalen USB-Anschluss am Hostrechner angewiesen. Stattdessen kann der Stick direkt am 5V USB-Steckernetzteil angeschlossen und in der Funkreichweite eines WLAN-AP platziert.
Das ESP8266-WLAN-Modul selbst arbeitet als Access Point - in diesem Fall stellt es selbst einen DHCP-Server zur Verfügung, man kann sich per Laptop, Tablet etc. damit verbinden und dann die Konfiguration durchführen.
Access Point: DoitWiFi_Config
IP-Adresse: 192.168.4.1
Die ESP8266 Serial WiFi Shield Firmware (http://www.esp8266.com/viewtopic.php?f=5&t=7124) stellt die serielle Schnittstelle des Busmasters transparent auf einem TCP-Port bereit.

Die Eckdaten:
DS2480B Serial 1-Wire Line Driver
FT230XS USB UART Interface IC
DS9503 ESD Protection Diode
USB Typ A Stecker
3-pol. WAGO Klemme mit Betätigungsdrücker

Einbindung in FHEM (USB-Modus)
define 1W_USB OWX /dev/ttyUSB0

Einbindung in FHEM (WLAN-Modus)
Hier noch kurz erläutert:

/etc/init.d/fhem editieren:
socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.xxx.xxx:9000 &
sleep 2
pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
chmod 666 $pty

FHEM Definition:
define 1W_WIFI OWX /dev/vmodem0

Oder mit OWX_ASYNC:
define <name> OWX_ASYNC <ip-address>:<port>
Bsp.:
define 1W_WIFI OWX_ASYNC 192.168.100.254:9000

Verfügbarkeit und Preise
Ich biete die Geräte im Marktplatz zum Kauf an.

EDIT
Schaltplan, Stückliste und Gerberdaten (https://www.itead.cc/open-pcb/pcb-prototyping/2layer-color-pcb-5cm-x-5cm-max.html) im Anhang.
Die Verwendung der Daten für kommerzielle Zwecke, Herstellung oder gewerblichen Vertrieb ist untersagt.

Scharfe Sache, gratuliere zum Erfolg. Jetzt muss ich nur noch das asynchrone Backend zu Ende bauen - habe mich mit dem Aufwand für mein DoorPi-Projekt ziemlich verschätzt.

LG

pah

Eigentlich schon etwas gemein, dies an einem Sonntag Mittag zu posten... :)

Ich hätte Interesse an 3-5 Stück, sollte es eine zweite Runde geben...

Danke, -MN

Hallo!

Ich habe auch Interesse an einem Gerät.

VG
   (;-)Mi

Auch hier würde Interesse bestehen!
Würde 2-3 Stück nehmen wollen.

grtz
CmdA

mit zwei Stück wäre ich auch dabei!

Gruß,
wbini

Moin,
wenn hier der neue Anmeldebereich für dieses tolle Gerät ist, bitte ich mit 2 Stück auf die Liste zu kommen.

Gruß
Andi

Mit 2-3 Geräten wäre ich auch dabei.

Gruß
Rü

Auch ich hätte gerne 2 Stück

Grüße
r

Ich würde auch gerne 2 Stück nehmen.....

Ihr würde auch 1 nehmen

Gruß Stefan

Gesendet von meinem SM-G920F mit Tapatalk

Servus,

wenn noch verfügbar würde ich auch
gern 1 Stück nehmen


mfg aherby

Da hänge ich mich mal mit an, würde auch 2 Stück haben wollen.

Guten Abend,hier wäre auch Interesse an 2 Stück. Danke im Voraus!

Hallo locutus,

wie stehen die Chancen an Dein entwickeltes "1-Wire-Interface mit dem ESP8266-WLAN-Funkmodul" zu kommen?
Bietest Du die Teile überhaupt noch an?

Gruß,
wbini

Heute war die Antwort darauf: Ja ... und in 30 Minuten fünf weg. Mmmist...
Ich hoffe auf eine Fortsetzung im nächsten Jahr ...

Sorry für die (vielleicht dumme) Frage:

Benötige ich noch einen Pullup oder ist der im Busmaster "integriert"?

Danke.

Moin,

muss mich leider noch einmal zu Wort melden.

Ich fürchte ich benötige Hilfe beim einbinden der 1-wire to WLAN-Bridge. Ich kriege das Teil einfach nicht ans laufen.

IP-Adresse:Port ist über das ESP8266-Webinterface eingestellt (192.168.1.15:9001 TCP). Das Interface wird auch im Netz erkannt, pings kommen durch, soweit so gut.

Ich möchte das Interface über WLAN einbinden, also /etc/init.d/fhem wie folgt editiert (Auszug):

# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
#       /opt/hmcfgusb/hmland -d -p 1234 -r 0
#

socat -s -lfSocat.log PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.1.15:9001 &
sleep 2
pty=`ls -l /dev/vmodem0 | grep -oE '[^ ]+$'`
chmod 666 $pty


        perl fhem.pl fhem.cfg

Sollte an der Stelle korrekt sein, oder?
Nur der Vollständigkeit halber, beenden von socat habe ich an folgender Stelle in die /etc/init.d/fhem eingebunden:


        echo "Stopping fhem..."

# if you want to stop hmland during fhem stop:
#       pkill hmland

pid=`ps -eo fname,pid | grep socat | grep -oE '[^ ]+$'`
kill -9 $pid

Bis hierher funktioniert auch alles ohne Problem, ich bekomme keine Fehlermeldungen o.ä., vmodem0 wird korrekt angelegt.

ls -l /dev/vmodem0
/dev/vmodem0 -> /dev/pts/0

Definition in FHEM:

define 1W_WIFI OWX /dev/vmodem0

Status bleibt auf failed, das Logfile sagt:

2016.12.24 11:06:03 3: Opening 1W_WIFI device /dev/vmodem0
2016.12.24 11:06:03 3: Setting 1W_WIFI serial parameters to 9600,8,N,1
2016.12.24 11:06:03 3: 1W_WIFI device opened
2016.12.24 11:06:03 1: OWX: Serial device /dev/vmodem0 defined
2016.12.24 11:06:07 1: OWX: 1-Wire bus 1W_WIFI: interface not found, answer was
2016.12.24 11:06:09 1: OWX: 1-Wire bus 1W_WIFI: interface not found, answer was
2016.12.24 11:06:12 1: OWX: 1-Wire bus 1W_WIFI: interface not found, answer was
2016.12.24 11:06:15 1: OWX: 1-Wire bus 1W_WIFI: interface not found, answer was

Wenn ich per OWX_ASYNC definiere gibts im Grunde das gleiche Spiel:

define 1W_WIFI_USB1 OWX_ASYNC 192.168.1.15:9001

Status bleibt zunächst auf disconnected.

Logfile (anders als bei OWX wird hier das Log regelrecht geflutet):

2016.12.24 11:22:17 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:22:17 3: 1W_WIFI_USB1 device opened
2016.12.24 11:24:59 3: OWX_SER::Detect 1-Wire bus 1W_WIFI_USB1: interface not detected, answer was
2016.12.24 11:24:59 1: PERL WARNING: Use of uninitialized value $interface in string eq at ./FHEM/OWX_SER.pm line 288.
2016.12.24 11:24:59 1: PERL WARNING: Use of uninitialized value $interface in string eq at ./FHEM/OWX_SER.pm line 290.
2016.12.24 11:24:59 1: define 1W_WIFI_USB1 OWX_ASYNC 192.168.1.15:9001: OWX_ASYNC_Init failed: OWX_SER::Detect 1-Wire bus 1W_WIFI_USB1: interface not detected, answer was

2016.12.24 11:28:51 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:54 3: Can't connect to 192.168.1.15:9001: Die Wartezeit für die Verbindung ist abgelaufen
2016.12.24 11:28:54 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:54 1: Perfmon: possible freeze starting at 11:28:52, delay is 2.475
2016.12.24 11:28:54 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:54 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:54 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:54 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:55 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:55 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:55 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:56 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:56 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:56 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:57 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001
2016.12.24 11:28:58 3: Opening 1W_WIFI_USB1 device 192.168.1.15:9001

Nach einem Neustart von FHEM wechselt der STATE in:

STATE
Init Failed: OWX_SER::Detect 1-Wire bus 1W_WIFI_USB1: interface not detected, answer was

Das Log sagt dazu:

2016.12.24 11:40:25 3: 1W_WIFI_USB1 device opened
2016.12.24 11:43:06 3: OWX_SER::Detect 1-Wire bus 1W_WIFI_USB1: interface not detected, answer was
2016.12.24 11:43:06 2: OWX: Error initializing 1W_WIFI_USB1: OWX_ASYNC_Init failed: OWX_SER::Detect 1-Wire bus 1W_WIFI_USB1: interface not detected, answer was


Weiß aktuell nicht so recht weiter und bin für jeden Tipp dankbar!

Wo kann ich ansetzen? Habe ich was übersehen oder was falsch gemacht?
Habe diesen ganzen Thread hier schon durch aber den zündenen Tip habe ich nicht finden können :(

Vielen Dank im voraus.

grtz
CmdA

Moin,

mit der Inbetriebnahme des 1-Wire-USB-Adapter mit ESP8266-WLAN-Schnittstelle habe ich so meine Probleme...

Ich habe mich auf den Adapter eingeloggt und dann eine Feste IP Adresse zugewiesen, diese ist auch frei. Dann habe ich den WLAN AP mit Passwort angegeben und gespeichert. Nun sollte ich den Adapter im Netzwerk finden,  oder?
Habe es auch mit DHCP probiert aber auch ohne Erfolg.
Irgend was mache ich noch falsch... Den Adapter finde ich in meinem Netzwerk nicht !?

Jens

Zitat von: jensweber am 26 Dezember 2016, 10:25:05
Moin,

mit der Inbetriebnahme des 1-Wire-USB-Adapter mit ESP8266-WLAN-Schnittstelle habe ich so meine Probleme...

Ich habe mich auf den Adapter eingeloggt und dann eine Feste IP Adresse zugewiesen, diese ist auch frei. Dann habe ich den WLAN AP mit Passwort angegeben und gespeichert. Nun sollte ich den Adapter im Netzwerk finden,  oder?
Habe es auch mit DHCP probiert aber auch ohne Erfolg.
Irgend was mache ich noch falsch... Den Adapter finde ich in meinem Netzwerk nicht !?

Jens

Willkommen im Club ;)

Ich bin leider auch nur einen kleinen Schritt weiter als du... Im Netzwerk ist mein Adapter zu finden.
Du solltest zunächst mal versuchen die Entfernung vom Adapter zum Router / Access-Point zu verringern. Für
so ein kleines Gerät ist die Reichweite schon sehr gut aber eben doch relativ klein.

Wenn der Adapter ein WLAN in Reichweite hat solltest du das auch per Dropdown auswählen können und nur noch das Passwort eingeben müssen. DHCP würde ich zunächst in jedem Fall aktiviert lassen bis du den Adapter sicher im Netzwerk hast.

grtz
CmdA


EDIT:
Mit meinem Problem bin ich leider auch keinen Schritt weiter gekommen.
Ich hatte ein Port-Problem vermutet und probiere seit gestern diverse Ports durch, allerdings ohne Erfolg, ich bekomme einfach keine Verbindung zu FHEM.

Aktueller Stand:
Sobald der Adapter im Netzwerk ist hängt FHEM und scheint den Adapter zu suchen. Erst wenn ich den Adapter vom Netzwerk nehme fängt sich FHEM wieder nach einiger Zeit.
Ob ich versuche den Adapter per OWX oder OW_ASYNC versuche ein zubinden macht keinen Unterschied. Socat läuft und legt das virtuelle Device auch an. Ob die socat-Geschichte korrekt läuft kann ich nur vermuten da ich keine Ahnung habe wie ich das überprüfen könnte. (Außer prüfen ob socat läuft und korrekt auf /dev/vmodem0 verlinkt).

Habe den Adapter auch einmal im USB-Modus verbunden um sicher zu stellen das der Adapter funktioniert. Das hat geklappt weshalb ich einen defekt ausschliesse. (Wäre auch seltsam wenn gleich beide kaputt wären, habe 2 Stück, mit beiden habe ich die selben Probleme).

ratlose Grüße
cmdA

Ist der TCP-Port in der Firewall freigegeben? Wie sieht es mit einem anderen Port aus? Für gewöhnlich nimmt man dafür 2323.
Folgende Parameter sollten nicht verändert werden:
Baud: 9600
Databits: 8
Parity: NONE
Stopbits: 1
Socket Type: Server
Transport Type: TCP

Zitat von: C0mmanda am 26 Dezember 2016, 10:30:49
Du solltest zunächst mal versuchen die Entfernung vom Adapter zum Router / Access-Point zu verringern. Für so ein kleines Gerät ist die Reichweite schon sehr gut aber eben doch relativ klein.

Die Funkreichweite der Keramikantenne ist bescheiden. Das Funkmodul ist mit einem zusätzlichen U.FL-Connector für eine externe Antenne ausgestattet.

Zitat von: C0mmanda am 22 Dezember 2016, 17:54:17
Benötige ich noch einen Pullup oder ist der im Busmaster "integriert"?

1W-Emulationen, die auf Ardunio- oder Raspberry Pi Basis laufen, benötigten einen Pullup-Widerstand. Der echte MAXIM DS2480B benötigt keinen Widerstand.

Zitat von: locutus am 26 Dezember 2016, 16:50:35
Ist der TCP-Port in der Firewall freigegeben? Wie sieht es mit einem anderen Port aus? Für gewöhnlich nimmt man dafür 2323.
Folgende Parameter sollten nicht verändert werden:
Baud: 9600
Databits: 8
Parity: NONE
Stopbits: 1
Socket Type: Server
Transport Type: TCP

Ich wüßte nicht das ich eine Firewall habe. Mein FHEM läuft auf einem Debian Jessie (Intel NUC), bewußt installiert habe ich keine Firewall.
Habe auch sonst nie Probleme mit geschlossenen Ports gehabt.
Zum testen habe ich auch bereits versucht den Adapter auf einer zweiten FHEM-Instanz auf einem Raspberry einzubinden, auch das hat leider nicht geklappt. (Gleiches Verhalten wie auf dem NUC)

Ich habe bereits mehrere Ports getestet, ohne Erfolg.
2323, 2424, 24, 25, 9000, 9001, 9999, 9099 und keine Ahnung welche noch.

Wie kann ich prüfen ob der Port offen und frei ist?

Alle anderen Settings sind genau wie sein sollen (Baud, Databits, Parity, Stopbits).

Zitat
1W-Emulationen, die auf Ardunio- oder Raspberry Pi Basis laufen, benötigten einen Pullup-Widerstand. Der echte MAXIM DS2480B benötigt keinen Widerstand.

Danke für die Info.
Jetzt muss nur noch der Adapter rennen ;)

Ich bin jetzt nicht der Linux und Netzwerkprofi, habe aber mal versucht mit Hilfe von Google heraus zu finden ob die Ports passen.

Erstmal die Settings vom Adapter:


Serial Setting:

Baud: 9600
Databits: 8
Parity: NONE
Stopbits: 1

Network Setting:
Socket Type: Server
Transport Type: TCP
Local Port: 2324


Der Adapter ist im Netzwerk zu finden, anpingbar etc. IP: 192.168.1.155.

Auf dem FHEM-Rechner läuft socat wie beschrieben:


ps au | grep socat
root     18532  0.0  0.4   4780  2244 pts/1    S    08:08   0:00 socat -s PTY,link=/dev/vmodem0,raw,echo=0,waitslave TCP4:192.168.1.155:2324
pi       20155  0.0  0.3   4604  1892 pts/1    S+   08:20   0:00 grep --color=auto socat

Jetzt habe ich mit Hilfe von nmap geprüft ob die Ports offen/erreichbar sind.

Zunächst einmal das gesamte LAN auf Port 2324 geprüft mit " nmap -sT -p2324 192.168.1.0-254". (Die Liste poste ich jetzt mal nicht).
Ergebnis: KEIN Netzwerkteilnehmer besetzt Port 2324.
(Port 2323 hatte ich als erstes versucht, der war schon belegt).

Dann habe ich Adapter und FHEM-Rechner getestet:

Adapter:
nmap -sT -p2324 192.168.1.155

Starting Nmap 6.47 ( http://nmap.org ) at 2016-12-27 08:27 CET
Nmap scan report for DoitWiFi-Device.fritz.box (192.168.1.155)
Host is up (0.010s latency).
PORT     STATE SERVICE
2324/tcp open  unknown

Port am Adapter stimmt und ist offen.

Am FHEM-Rechner ist der Port jedoch zu, obwohl socat korrekt läuft:
nmap -sT -p2324 192.168.1.5 

Starting Nmap 6.47 ( http://nmap.org ) at 2016-12-27 08:28 CET
Nmap scan report for 192.168.1.5
Host is up (0.00052s latency).
PORT     STATE  SERVICE
2324/tcp closed unknown

Jetzt die Preisfrage:
Wie bringe ich das System dazu den Port zu öffnen und darauf zu lauschen?
Sollte (ohne Firewall) der Port nicht vom System geöffnet werden sobald ein Dienst (socat) darauf zugreift bzw. darauf lauscht?

Oder bin ich hier gerade komplett auf dem Holzweg?

Danke für die Hilfe.

grtz
CmdA

Moin,

leider habe ich es noch immer nicht am laufen, allerdings auch neue Erkenntnisse...

Habe mal einen Raspi3 rausgekramt und ein frisches Debian + FHEM aufgesetzt damit ich in Ruhe testen kann.

Zunächst mal beide Adapter im USB-Modus.
Ergebnis:
1 Adapter lässt sich problemlos einbinden und findet sofort 1-wire Devices --> Läuft 1a.
1 Adapter lässt sich selbst im USB-Modus nicht verbinden.

Dann mit dem funktionierenden Adapter weiter getestet um in ins WIFI zu bekommen.
Leider funktioniert das immer noch nicht, mal was aus dem Log während der Adapter initialisiert werden sollte:

Define per OWX_ASYNC <ip-nummer>:<port>

2016.12.27 21:48:07 0: Server started with 9 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1269)
2016.12.27 21:48:14 3: Opening 1wire_WIFI device 192.168.1.14:2324
2016.12.27 21:48:14 3: 1wire_WIFI device opened
2016.12.27 21:50:56 3: OWX_SER::Detect 1-Wire bus 1wire_WIFI: interface not detected, answer was
2016.12.27 21:50:56 1: PERL WARNING: Use of uninitialized value $interface in string eq at ./FHEM/OWX_SER.pm line 288.
2016.12.27 21:50:56 1: PERL WARNING: Use of uninitialized value $interface in string eq at ./FHEM/OWX_SER.pm line 290.
2016.12.27 21:50:56 1: define 1wire_WIFI OWX_ASYNC 192.168.1.14:2324: OWX_ASYNC_Init failed: OWX_SER::Detect 1-Wire bus 1wire_WIFI: interface not detected, answer was


Define per OWX /dev/vmodem0

2016.12.27 21:52:12 3: Opening 1wire_WIFI device /dev/vmodem0
2016.12.27 21:52:12 3: Setting 1wire_WIFI serial parameters to 9600,8,N,1
2016.12.27 21:52:12 3: 1wire_WIFI device opened
2016.12.27 21:52:12 1: OWX: Serial device /dev/vmodem0 defined
2016.12.27 21:52:16 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:18 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:21 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:24 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:26 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:29 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:31 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was
2016.12.27 21:52:34 1: OWX: 1-Wire bus 1wire_WIFI: interface not found, answer was

Da stimmt doch was nicht?! Der Adapter wird doch zunächst erkannt....??

weiterhin ratlose Grüße
cmdA

Nein, wird er NICHT.

Die Tatsache, dass das USB-Device geöffnet wird, besagt nicht die Erkennung des Busmasters.

Hier gibt es tatsächlich keinerlei Response vom Busmaster => entweder falsch angeschlossen (RX/TX vertauscht) oder defekt.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2016, 04:32:18
Nein, wird er NICHT.

Die Tatsache, dass das USB_Device geöffnet wird, besagt nicht die Erkennung des Busmasters.

Macht Sinn.
Hab das öffnen wohl falsch interpretiert.

Zitat
Hier gibt es tatsächlich keinerlei Response vom Busmaster => entweder falsch angeschlossen (RX/TX vertauscht) oder defekt.

LG

pah

Vielen Dank für deine Diagnose/Einschätzung pah.
Ich dachte schon ich stelle mich einfach nur dumm an.. :(

grtz
CmdA

Zitat von: C0mmanda am 27 Dezember 2016, 23:11:29
Habe mal einen Raspi3 rausgekramt und ein frisches Debian + FHEM aufgesetzt damit ich in Ruhe testen kann.

Zunächst mal beide Adapter im USB-Modus.
Ergebnis:
1 Adapter lässt sich problemlos einbinden und findet sofort 1-wire Devices --> Läuft 1a.
1 Adapter lässt sich selbst im USB-Modus nicht verbinden.

USB zu Seriell Wandler mit FTDI Chipsatz werden nach der Trennung vom System neu enumeriert. Daher kann es vorkommen, dass FHEM den Wandler unter /dev/ttyUSB0 erwartet während er unter /dev/ttyUSB1 verfügbar ist.
Um dieses Problem auszuschließen, empfiehlt es sich den Wandler unter seiner eindeutigen ID anzusprechen.
define 1W_USB OWX /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_ ...

Teste bitte die WLAN-Verbindung zum Busmaster mit Hilfe einer TCP Client Software. Sende im HEX-Datenformat FF oder F0. Der Busmaster sollte mit 3F antworten.

Zitat von: locutus am 28 Dezember 2016, 22:39:51
USB zu Seriell Wandler mit FTDI Chipsatz werden nach der Trennung vom System neu enumeriert. Daher kann es vorkommen, dass FHEM den Wandler unter /dev/ttyUSB0 erwartet während er unter /dev/ttyUSB1 verfügbar ist.
Um dieses Problem auszuschließen, empfiehlt es sich den Wandler unter seiner eindeutigen ID anzusprechen.

Code Auswählen Erweitern

define 1W_USB OWX /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_ ...

Teste bitte die WLAN-Verbindung zum Busmaster mit Hilfe einer TCP Client Software. Sende im HEX-Datenformat FF oder F0. Der Busmaster sollte mit 3F antworten.

Das Ergebnis in Bildern unten angehängt:

1. Adapter 1 im USB-Mode --> Failed
2. Adapter 2 im USB-Mode --> Wird erkannt
3. Adapter 1 im WIFI-Mode --> TCP-Paket kommt an, aber es kommt keine bzw eine leere (0Byte) Antwort.
4. Adapter 2 im WIFI-Mode --> TCP-Paket kommt an, aber es kommt keine bzw eine leere (0Byte) Antwort.

Wobei ich mir mit dem TCP-Tool nicht 100%ig sicher bin da ich sowas noch nie genutzt habe.
Ich bin auf Mac, iOS und Linux unterwegs und da gibt es leider nicht das gleiche Tool welches du benutzt.

Hallo C0mmanda,
Fehler lokalisiert und beseitigt. Schuld war in beiden Fällen der mechanische Umschalter (SW1 im Schaltplan (https://forum.fhem.de/index.php?action=dlattach;topic=18996.0;attach=63026;image)). Die Kontakte waren ohne Funktion - notfalls kann man zwei Kontakte auch dauerhaft überbrücken. Ich habe beide Umschalter ausgetauscht.

Zitat von: locutus am 11 Januar 2017, 21:15:29
Hallo C0mmanda,
Fehler lokalisiert und beseitigt. Schuld war in beiden Fällen der mechanische Umschalter (SW1 im Schaltplan (https://forum.fhem.de/index.php?action=dlattach;topic=18996.0;attach=63026;image)). Die Kontakte waren ohne Funktion - notfalls kann man zwei Kontakte auch dauerhaft überbrücken. Ich habe beide Umschalter ausgetauscht.

Vielen Dank für die schnelle Bearbeitung/Reparatur!
Bin nun auch endlich dazu gekommen die Sticks zu testen und es hat auf Anhieb
Tadellos funktioniert.

Danke!!

Grtz
CmdA

Hallo,

gab es eine Änderung mit einem der letzten updates, sodass mein 1-Wire-Interface mit dem ESP8266-WLAN-Funkmodul von Loctus nivht mehr funktioniert ?

https://forum.fhem.de/index.php/topic,74457.msg662034.html#msg662034

Danke, Jens

1. OWX_ASYNC wird nicht weiter entwickelt
2. Niemand braucht socat für OWX, bitte Commandref lesen.


LG

pah

Zitat von: Prof. Dr. Peter Henning am 24 Juli 2017, 05:57:01
1. OWX_ASYNC wird nicht weiter entwickelt

OK. soweit verstanden, aber weas für einen grund gibt es dann, dass OWX_ASYNC seit ca. 19.07. nicht mehr funktioniert ?

Wie kann ich den Busmaster von Loctus hardwaremässig zurücksetzen?
Oder ggf. wo bekomme ich die Firmware und den Bus master neu zu Flaschen?
Muss ich dabei was beachten?

Jens

Gesendet von meinem F5121 mit Tapatalk

Zitat von: Jewe am 11 November 2017, 15:10:54
Wie kann ich den Busmaster von Loctus hardwaremässig zurücksetzen?

Den DS2480B-Busmaster von der Spannungsversorgung trennen und die Daten im 1-byte Buffer sind verloren.

Zitat
Oder ggf. wo bekomme ich die Firmware und den Bus master neu zu Flaschen?

Ich bezweifle, dass es so etwas wie Firmware für den DS2480B (https://datasheets.maximintegrated.com/en/ds/DS2480B.pdf) gibt, aber falls doch, dann solltest du dein Anliegen an Maxim Integrated richten.

Zitat von: Jewe am 11 November 2017, 15:10:54
Oder ggf. wo bekomme ich die Firmware und den Bus master neu zu Flaschen?

Der Busmaster ist herstellerseitig hart codiert und kann nicht mit neuer Firmware geflasht werden. Falls hinter dem Busmaster keine ESD-Schutzdiode angeordnet ist, kann man den DS2480 schon mal zerschießen (ich kenne den Schaltplan nicht, gehe aber davon aus, locutus die eingebaut hat).

Gruß
Uwe

Jaja ... die Präzision bei der Fragestellung...  ;D
Ich bin sicher, locutus hat hier irgendwo den Downloadlink und Infos zur ESP8266-Firmware versteckt. Und Infos zur Konfiguration auch. Aber auch das löst möglicherweise nicht das Problem...

Ja, auf präzise Fragen bekommt man präzise Antworten  :)
Bin mal gespannt, wie es weitergeht. Vielleicht mache ich Popcorn.

Vielleicht war die Frage ein wenig falsch,mag sein. Aber das bringt mich nun auch nicht weiter. Die Dinger funktionieren nicht mehr und gut.

Gesendet von meinem F5121 mit Tapatalk

Wenn nach einem FHEM-Update das WLAN-Modul nicht mehr funktioniert, ist in der Regel nicht das WLAN-Modul Schuld.
Wie aus diesem und dem anderen Thread, in dem Du diese Fragen gestellt hast, hervorgeht, hast Du ziemlich massiv die OWX-Module hin- und her kopiert und offenbar ja auch was mit OWX_ASYNC vermischt. Hast Du (was man ja haben sollte) ein Backup Deiner FHEM-Instanz vor dem bewussten Update? Mal eingespielt? Funktioniert der Kram dann wieder?

Gruß
Uwe

EDIT: Noch was. In einem der anderen Beiträge sprichst Du von einem USB-Interface:

Zitat
Das Gateway habe ich definiert
define 1W_USB OWX /dev/ttyUSB1

Funktionieren Deine Sensoren damit?

Ja klar, und das funktioniert eben nicht.
Deshalb die Vermutung, daß die Busmaster nun nicht mehr funktioniern.

Und das hin und herkopieren der Dateien habe ich gemacht, weil owx_async nach dem Update nicht mehr funktioniert hat und nach dem Update im Oktober das ich wegen einem anderen Modul gemacht hatte ging wieder nix mehr. Naja den Rest kann man hier ja lesen...

Die Dateien sollte aber mit dem Update und alles auf dem aktuellen Stand sein.

Gesendet von meinem F5121 mit Tapatalk

Um ein Hardwaredefekt auszuschließen, würde ich eine andere Softwareumgebung, wie z. B. owTools (https://www.tm3d.de/elektronik-projekte/owtools-software) für Testzwecke nehmen.

Zitat von: Pfriemler am 12 November 2017, 17:10:23
Ich bin sicher, locutus hat hier irgendwo den Downloadlink und Infos zur ESP8266-Firmware versteckt. Und Infos zur Konfiguration auch.

... immer noch da, wo sie hingehören.
https://forum.fhem.de/index.php/topic,18996.msg489913.html#msg489913

Hallo,

den OneWireViewer habe ich installiert. Nach dem Starten kommt die Auswahl des Adapters bzw. des Port´s. Der 1-Wire-Adapter wird bei mir als COM5 erkannt. Diesen wähle ich aus. Danach kommt die Fehlermeldung
1-Wire Net not available
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Cannot load default adapter. Please check that the adapter
is connected and that no other application is using the
port.

If you have checked the adapter, the default port might
not be selected.  Either set the value of the TMEX default
using the utility provided with the TMEX Runtime, or create
a new file in the <user.home>/OneWireViewer folder called
onewireviewer.properties with two lines, similar to the
following:

#native win32 drivers adapter.name={DS9097U}
  adapter.port=COM1
#or javax.comm drivers adapter.name=DS9097U
  adapter.port=COM1

The full path to this file should be:
C:\Users\moab\OneWireViewer\onewireviewer.properties

Heist das nun, dass der Adapter einen Schuss weg hat ?

In der Vergangenheit hat sich der Umschalter SW1 als potentielle Fehlerquelle herauskristallisiert. Also Kontakte prüfen, gegebenenfalls überbrücken. Ansonsten ist das Gerät nur bedingt reparabel. Die Gründe dafür werden hier (https://www.mikrocontroller.net/topic/430135) erläutert.

Hallo Locutus,
habe an den Schaltern rumgespielt und siehe da er funktioniert wieder.

Danke.

Zitat von: locutus am 11 September 2016, 11:26:20
Hallo zusammen,

ich habe das 1-Wire-Interface mit dem ESP8266-WLAN-Funkmodul redesignt und auf die Größe eines USB-Sticks reduziert.

Schaltplan, Stückliste und Gerberdaten (https://www.itead.cc/open-pcb/pcb-prototyping/2layer-color-pcb-5cm-x-5cm-max.html) im Anhang.

Hallo locutus,

ich habe mir gerade die Stückliste bzw. Deine Bilder des 1-Wire-USB-Adapter mit WLAN-Schnittstelle angeschaut. Ist das wirklich ein ESP-12, der verbaut ist? Der müsste doch eine PCB Antenne haben. Ich meine, auf den Bildern ist ein ESP-07 verbaut.

Danke für eine kurze Info.

Gruß PeMue

der ESP-07 ist pinkompatibel mit einem 12E (exkl. der zusätzlichen Pins).
ich habe auch esp-link geflasht, da locutus Vorschlag bei W-LAN Kennwörtern auf 30 Zeichen begrenzt ist.

Zitat von: habeIchVergessen am 12 Januar 2018, 18:58:42
... der ESP-07 ist pinkompatibel mit einem 12E (exkl. der zusätzlichen Pins).

Danke für die Info, ich war der Meinung, dass die beiden nicht pinkompatibel seien  ???

Gruß PeMue

Moin,

ich habe noch Probleme, den Stick von locutus zum Fliegen zu kriegen.
Ich hoffe, ihr könnt mir hier weiterhelfen.

Ich benutze den busmaster im WLAN Modus und habe einen 2fach 1W Counter dran, ebenfalls von locutus.
Teilweise wurde der auch erkannt, dann wieder nicht mehr.
Den SW1 Schalter hab ich gemessen, der scheint ok.

Wenn ich mich mit putty auf den busmaster verbinde, und FF sende, antwortet er mit GG, bei F0 mit G1. (Was bedeutet das?)

Früher hatte ich einen 4fach Counter von locutus dran, mit den identischen Problemen. Also liegt es wohl eher am Busmaster..

fhem.log mit verbose=5:

2018.03.02 18:05:20 1: OWX_Init called for bus OWXWIFI with interface state opened, now going for detect
2018.03.02 18:05:20 1: OWX_TCP::Query OWXWIFI: Sending out0xc1
2018.03.02 18:05:20 5: SW: c1
2018.03.02 18:05:20 5: OWX_TCP::Query OWXWIFI: Received 1 of 1 bytes in first attempt and state opened
2018.03.02 18:05:20 1: OWX_TCP::Query OWXWIFI: Sending out0x17 0x45 0x5b 0x0f 0x91
2018.03.02 18:05:20 5: SW: 17455b0f91
2018.03.02 18:05:20 5: OWX_TCP::Query OWXWIFI: Received 5 of 5 bytes in first attempt and state opened
2018.03.02 18:05:20 1: OWX_TCP::Detect 1-Wire bus OWXWIFI: interface master DS2480 detected for the first time
2018.03.02 18:05:20 1: OWX_TCP::Query OWXWIFI: Sending out0xe3 0xc5
2018.03.02 18:05:20 5: SW: e3c5
2018.03.02 18:05:20 5: OWX_TCP::Query OWXWIFI: Received 1 of 1 bytes in first attempt and state opened
2018.03.02 18:05:20 4: OWX_TCP: No presence detected on bus OWXWIFI
2018.03.02 18:05:20 1: OWX_TCP::Query OWXWIFI: Sending out0xe1 0xf0 0xe3 0xb5
2018.03.02 18:05:20 5: SW: e1f0e3b5
2018.03.02 18:05:20 5: OWX_TCP::Query OWXWIFI: Received 1 of 1 bytes in first attempt and state opened
2018.03.02 18:05:20 1: OWX_TCP::Query OWXWIFI: Sending out0xe1 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xe3 0xa5
2018.03.02 18:05:20 5: SW: e100000000000000000000000000000000e3a5
2018.03.02 18:05:20 5: OWX_TCP::Query OWXWIFI: Received 16 of 16 bytes in first attempt and state opened
2018.03.02 18:05:20 1: OWX_TCP::Search CRC failed on bus OWXWIFI
2018.03.02 18:05:20 1: OWX_Discover: 1-Wire devices found on bus OWXWIFI ()


list des OVX Devices
Internals:
   ALARMED    no
   ASYNCHRONOUS 0
   DEF        192.168.178.43:2323
   DeviceName 192.168.178.43:2323
   FD         32
   INITDONE   1
   INTERFACE  DS2480
   NAME       OWXWIFI
   NR         468
   PARTIAL   
   PRESENT    1
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   interval   60
   timeout    8
   version    7.05
   DEVHASH:
     OWXWIFI    Busmaster
   DEVS:
   READINGS:
     2018-03-02 18:18:12   queue           0
     2018-03-02 18:18:12   state           opened
Attributes:
   asynchronous 0
   interval   60
   room       OWX
   timeout    8
   verbose    5


Edit: noch mehr log-Auszüge von Gestern:

2018.03.01 07:23:38 3: Opening OWXWIFI device 192.168.178.43:2323
2018.03.01 07:23:38 3: OWXWIFI device opened
2018.03.01 07:23:48 3: OWCOUNT:  Device OWX_1D_40DA84000005 defined.
2018.03.01 07:23:48 3: OWCOUNT:  Device OWX_1D_41DA84000005 defined.
...
2018.03.01 07:24:08 1: OWXCOUNT_BinValues getpage: OWX_1D_40DA84000005: invalid CRC, 255 255 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.03.01 07:24:08 1: OWXCOUNT_BinValues getpage: OWX_1D_40DA84000005: invalid CRC, 255 255 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
2018.03.01 07:24:15 1: OWX_TCP::Query OWXWIFI: 5 of 54 bytes - something wrong with the 1-Wire device ???
2018.03.01 07:24:21 1: OWX_TCP::Query OWXWIFI: 29 of 54 bytes - something wrong with the 1-Wire device ???
2018.03.01 07:24:25 1: PERL WARNING: Use of uninitialized value $minInt in numeric lt (<) at fhem.pl line 4543.

....
2018.03.01 07:24:39 1: OWX_Init called for bus OWXWIFI with interface state opened, now going for detect
2018.03.01 07:24:39 1: OWX_TCP::Detect 1-Wire bus OWXWIFI: interface master DS2480 detected for the first time
2018.03.01 07:24:39 1: OWX_TCP::Search CRC failed on bus OWXWIFI
2018.03.01 07:24:39 1: OWX_Discover: Device OWX_1D_40DA84000005 of type OWCOUNT is unused, consider deletion !
2018.03.01 07:24:39 1: OWX_Discover: Device OWX_1D_41DA84000005 of type OWCOUNT is unused, consider deletion !
2018.03.01 07:24:39 1: OWX_Discover: 1-Wire devices found on bus OWXWIFI ()
...
2018.03.01 07:28:51 1: OWX_TCP::Query OWXWIFI: 32 of 54 bytes - something wrong with the 1-Wire device ???
2018.03.01 07:28:53 3: connexoon: request active
2018.03.01 07:29:16 1: OWX_TCP::Query OWXWIFI: 18 of 54 bytes - something wrong with the 1-Wire device ???
...
2018.03.01 20:57:43 1: OWX_TCP::Search reset failed on bus OWXWIFI


Danke für eure Unterstützung!

Leider musste auch ich jetzt frierend die Erfahrung machen, dass reopen in der aktuell per update ausgelieferten Fassung bei 00_OWX.pm nicht funktioniert, ja schlimmer: Bei mir beliebig wiederholbar das FHEM komplett abschießt.

Ich hatte einen Watchdog, der aufgrund meiner Beobachtung, dass vereinzelt mein Device auf disconnected springt, ein Reopen selbständig nach 2 Minuten ausführt. Dieser Fall trat nun bei einer 2-tägigen Abwesenheit und Temperaturen von -6 Grad ein. Da war es dann gestern Abend bei Rückkehr schnukelig kalt...

Ich habe das dann fünf- sechsmal noch mit neu gestartetem FHEM wiederholt und die Gegenprobe gemacht: Bei der vorherige Fassung (die bei mir am 19.2. geupdatet wurde) habe ich keine Probleme mit set OWio reopen...


Herzliche Grüße

Christian

Zitat von: cwagner am 05 März 2018, 10:49:40
Leider musste auch ich jetzt frierend die Erfahrung machen, dass reopen in der aktuell per update ausgelieferten Fassung bei 00_OWX.pm nicht funktioniert, ja schlimmer: Bei mir beliebig wiederholbar das FHEM komplett abschießt.

Ich hatte einen Watchdog, der aufgrund meiner Beobachtung, dass vereinzelt mein Device auf disconnected springt, ein Reopen selbständig nach 2 Minuten ausführt. Dieser Fall trat nun bei einer 2-tägigen Abwesenheit und Temperaturen von -6 Grad ein. Da war es dann gestern Abend bei Rückkehr schnukelig kalt...

Ich habe das dann fünf- sechsmal noch mit neu gestartetem FHEM wiederholt und die Gegenprobe gemacht: Bei der vorherige Fassung (die bei mir am 19.2. geupdatet wurde) habe ich keine Probleme mit set OWio reopen...


Herzliche Grüße

Christian

Hier gehts zum Thema:
https://forum.fhem.de/index.php/topic,85007.0.html

Hab deinen Beitrag dort verlinkt.

Dass ein reload fhem abschießt habe ich auch beobachtet...
Aber das hat wohl nicht unbedingt mit meinem o.g. Problem (#444) zu tun.

Der Counter wird mal erkannt und dann wieder nicht.
Am Wlan kann es nicht liegen, da hab ich einen ping mitlaufen lassen.

Keiner ne Idee, was ich noch machen könnte?

Hallo zusammen,

ich baue gerade für jemanden locutus' 1-wire Interface (https://forum.fhem.de/index.php/topic,18996.msg489913.html#msg489913) nach. Das Interface wird von FHEM erkannt, der (direkt) angeschlossene Sensor DS18B20 leider nicht. Aus meiner Sicht kann das nur am Pegelwandler liegen, ich verwende diesen hier (https://www.voelkner.de/products/852833/Nexperia-MOSFET-BSS138PS-115-2-N-Kanal-420mW-TSSOP-6.html). Oder der Ausgangsfilter ist so intolerant, dass nur 470 pF/62 Ohm gehen, ich verwende (mangels vorhandenen Bauteilen) C9 = 100 nF bzw. R3 = 27 Ohm (Grenzfrequenz ist ähnlich).
Dummerweise passiert das bei drei gleich aufgebauten Modulen  >:( >:( >:(
Ein get <name> devices findet etwas, aber mit der Adresse OWX_Discover: 1-Wire devices found on bus PM1WUSB01
00.000000000000      unknown        OWX_00_000000000000
das Log sagt folgendes:
2018.03.27 20:23:25 3: OWX_SER::Reset Alarm presence detected on bus PM1WUSB01
2018.03.27 20:23:26 3: OWX_SER::Reset Alarm presence detected on bus PM1WUSB01
2018.03.27 20:23:26 1: OWX_SER::Search CRC failed on bus PM1WUSB01
2018.03.27 20:23:26 2: OWX_Discover: Device with unknown family code '00' found on bus PM1WUSB01
2018.03.27 20:23:26 1: OWX_Discover: 1-Wire devices found on bus PM1WUSB01 (OWX_00_000000000000)
Und schließlich das List:
Internals:
   ALARMED    yes
   ASYNCHRONOUS 0
   BLOCK      0
   BUSY       0
   DEF        /dev/ttyUSB3
   DeviceName /dev/ttyUSB3
   FD         18
   INITDONE   0
   INTERFACE 
   NAME       PM1WUSB01
   NR         653
   PARTIAL   
   PRESENT    0
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   interval   300
   timeout    2
   DEVHASH:
     OWX_00_000000000000 00.000000000000.00
     PM1WUSB01  Busmaster
   DEVS:
     00.000000000000.00
   READINGS:
     2018-03-27 20:16:38   state           opened
Attributes:
   room       Radio
Hat jemand einen Tipp für mich, wo ich noch suchen kann?

Danke + Gruß

Peter

Sieht sehr nach Hardwareproblem aus. Hast Du mal das einfache Ding hier probiert: https://wiki.fhem.de/wiki/1-Wire_Pegelwandler

LG

pah

Hallo zusammen,

ich möchte euch die neue Version des 1-Wire-USB-Adapters vorstellen. Die wichtigsten Neuerungen im Überblick:
- FT230XS durch CH340G ersetzt
- ESP8266 durch USR-WIFI232-T (https://www.usriot.com/products/wireless-wifi-module.html) oder USR-C215 (https://www.usriot.com/products/iot-wifi-module.html) ersetzt
- 433 MHz RF-Schnittstelle hinzugefügt
- WLAN-Status-LED hinzugefügt
- Taster hinzugefügt (WPS oder RELOAD Funktion konfigurierbar per Lötbrücke)

Das WLAN-Modul selbst arbeitet als Access Point - in diesem Fall stellt es selbst einen DHCP-Server zur Verfügung, man kann sich per Laptop, Tablet etc. damit verbinden und dann die Konfiguration durchführen.
Access Point: USR-WIFI232-T oder USR-C215
IP-Adresse: 10.10.100.254
Benutzername und Passwort: admin

Erforderliche Voreinstellungen (wie Abgebildet):
- Port ID -> frei wählbar (voreingestellt 8899)
- TCP Time Out Setting -> 0 (nur USR-WIFI232-T)
- Baud Rate -> 9600


Das Funktionsprinzip der 433 MHz RF-Schnittstelle: https://forum.fhem.de/index.php/topic,18996.msg276368.html#msg276368
Info zum 1-Wire-USB-Adapter Ver. 1: https://forum.fhem.de/index.php/topic,18996.msg489913.html#msg489913


Im Anhang Gerberdaten und Schaltplan für die, die selbst löten möchten.
Die Verwendung der Daten für kommerzielle Zwecke, Herstellung oder gewerblichen Vertrieb ist untersagt.


Verfügbarkeit und Preise
Ich biete die Geräte im Marktplatz (https://forum.fhem.de/index.php/topic,57559.0.html) zum Kauf an.

Wenn noch möglich, dann würde ich: 1 x USB, 1 x WLAN nehmen.

Gruß,
wbini

Bei der nächsten Verfügbarkeit würde ich gerne einen mit USB nehmen.

Vielen Dank

Jürgen

Falls es eine Neuauflage gibt, habe ich ebenfalls Interesse an einem Stick mit WLAN.
LG,
Daniel

Zitat von: Prof. Dr. Peter Henning am 28 März 2018, 07:11:47
Sieht sehr nach Hardwareproblem aus. Hast Du mal das einfache Ding hier probiert: https://wiki.fhem.de/wiki/1-Wire_Pegelwandler

Der Pegelwandler hat funktioniert, die Ausgangsspannung (bei 3,3 V Eingangsspannung) war 4,35 V, was aber m.E. noch im akzeptablen Rahmen liegt.
Systematische Fehlersuche:
- testen, ob der FT230X funktioniert (geht nur ohne Busmaster) ok
- testen, ob der Pegelwandler funktioniert ok
- durchpiepsen des ESD Bausteins ok
- checken des Ausgangsfilters nok
d.h. der Ausgangsfilter muss laut Datenblatt (62 Ohm, 470 pF) sein. Ich habe jetzt aus Ermangelung der 62 Ohm 51 Ohm und die passenden 470 pF genommen. Und siehe da: jetzt geht's.
Datenblatt lesen hilft manchmal   8) 8) 8)

Gruß PeMue

Zitat von: habeIchVergessen am 12 Januar 2018, 18:58:42
der ESP07 ist pinkompatibel mit einem ESP12E (exkl. der zusätzlichen Pins).

Pinkompatibel schon, nur meine ESP07 waren Schrott: einer war nicht flashbar, der andere war flashbar, aber man konnte sich nicht auf die Konfiguationsseite einloggen.
Daher meine klare Empfehlung: entweder ESP12E oder ESP12F verwenden, aber ja keinen ESP07.

Gruß PeMue

Hallo locutus,

Zitat von: locutus am 06 Mai 2018, 09:00:03
ich möchte euch die neue Version des 1-Wire-USB-Adapters vorstellen.

ich habe eine Frage zu Deinem USR-C215, siehe Dein Bild
https://forum.fhem.de/index.php?action=dlattach;topic=18996.0;attach=100685;image
Der sieht deutlich anders aus, als der auf der usriot Webseite, siehe
https://www.usriot.com/wp-content/uploads/2016/03/C215-3-480x480.jpg
Ich habe jetzt einen, da befürchte ich, dass die onboard Antenne fehlt, siehe Bild im Anhang.
Hast Du den originalen USR-C215 oder einen Clon?
Bitte poste doch mal einen Link, wo Du den bestellt hast.
Ich will den 1-wire Adapter nicht aufbauen, solange ich nicht weiß, ob ich die richtigen Komponenten habe.

Danke + Gruß

Peter

Zitat von: PeMue am 09 September 2018, 15:10:12
ich habe eine Frage zu Deinem USR-C215, siehe Dein Bild ...
Der sieht deutlich anders aus, als der auf der usriot Webseite

Auf dem Bild ist ein pinkompatibler USR-WIFI232-T abgebildet.

ZitatBitte poste doch mal einen Link, wo Du den bestellt hast.

eBay Artikel 272468585726 (https://www.ebay.de/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=272468585726&_sacat=0)

Hallo zusammen,

so sieht dann der Adapter mit dem USR-C215 mit externer Antenne aus.

Einrichung:
- Adapter einstecken und danach den Taster länger als 3 s drücken (Reset der Einstellungen auf AP)
- der USR-C215 spannt einen Access Point auf, sich per WLAN mit diesem verbinden (ohne Passwort)
- im Browser die Adresse 10.10.100.254 aufrufen (user: admin, pw: admin)
- die Einstellungen wie in den zwei Bildern gezeigt vornehmen
- bei DHCP sollte man im Router diesem Gerät immer dieselbe Adresse zuweisen lassen
- bei bestehender LAN Verbindung leuchtet die grüne LED

Die externe Flachantenne sieht zwar nicht wirklich gut aus (WAF?), aber die Reichweite ist gigantisch, bei mir auf der Terasse geht der Adapter ohne Probleme.

Gruß Peter

Hallo,

hier die Antwort auf per PM gestellte Fragen:

Zitat
Wo genau ist der Taster, um den USR-C215 zu resetten? Auf dem USR-C215 habe ich nichts gefunden. Auf dem größeren Board ist eine Schiebeschalter (den habe ich nicht angerührt) und ein mit SW2 gekennzeichneter Taster. Den habe ich für >3s gedrückt. Hat aber nicht geholfen. Hast Du einen Tipp?

Das ist der Taster mit der Bezeichnung SW2. Ggf. die 3 s etwas großzügiger auslegen, die können relativ lang sein.

ZitatIch bekomme den  Access Point des USR-C215 im Browser nicht aufgerufen, es erscheint eine Fehlermeldung "401 Unauthorized".

Du müsstest Dich mit dem WLAN AP der SSID USR-C215 verbinden (ohne Passwort), dann im Browser die Adresse10.10.100.254 aufrufen, user: admin, pw: admin
Danach solltest Du auf oben gezeigten Konfigurationsseite sein.

Gruß Peter

So, Problem gelöst. Ich habe die ganze Zeit versucht, mich über ein IPad auf dem USR-C215 einzuloggen. Erst als ich mich mit einer Windows 10 Maschine & Firefox eingeloggt habe, hat es funktioniert. Warum auch immer...
LG,
Daniel

Hallo,

nachdem meine USR-C215-Variante seit längerer Zeit problemlos im Einsatz ist, würde ich gerne auch die 433 MHz-Version mal auszuprobieren.
Hat eventuell jemand beide Varianten gegenübergestellt ? - Batteriebetrieb, Stromverbrauch, Reichweite etc...

LG,
wbini

Hallo,

Ich lese auf den letzten Seiten immer nur WLAN. Gibt es die LAN Variante nicht mehr?
Bin auch der Suche nach einem Interface mit LAN Anschluß evtl als Fertiggerät oder aktuellem Schaltplänen als Bild bzw. im Eagle Format.
mit Target3001 kann ich nichts anfangen.

Besser: Reed-Oeffner nehmen, die sind genau so teuer. Und damit offen, wenn das Fenster geschlossen ist. Dann genügt ein kleiner Arduino Micro, um alle 250 ms den Bus abzufragen und nur die geöffneten Fenster zu registrieren.

LG

pah

Zitat von: PeMue am 16 Februar 2019, 11:15:03
Hallo zusammen,

so sieht dann der Adapter mit dem USR-C215 mit externer Antenne aus.

Einrichung:
- Adapter einstecken und danach den Taster länger als 3 s drücken (Reset der Einstellungen auf AP)
- der USR-C215 spannt einen Access Point auf, sich per WLAN mit diesem verbinden (ohne Passwort)
- im Browser die Adresse 10.10.100.254 aufrufen (user: admin, pw: admin)
- die Einstellungen wie in den zwei Bildern gezeigt vornehmen
- bei DHCP sollte man im Router diesem Gerät immer dieselbe Adresse zuweisen lassen
- bei bestehender LAN Verbindung leuchtet die grüne LED

Die externe Flachantenne sieht zwar nicht wirklich gut aus (WAF?), aber die Reichweite ist gigantisch, bei mir auf der Terasse geht der Adapter ohne Probleme.

Gruß Peter

Ist noch einer zu haben? Wenn ja, welcher Preis?
Bräuchte auch noch einen WLAN CUL 433 ? Hast da auch noch einen? Wenn ja, welcher Preis?

Wer bitte ist mit "fhemser" gemeint? Dieser Post hat auch nichts mit dem Thema des Threads zu tun, bitte entfernen.

LG

pah

moin,

... genau... weg damit ! war nur eine frage.... kommt so schnell nicht wieder vor.... ordnung muss sein :-)

freundliche grüsse vom fpg

Gut erkannt - denn die Nutzer von FHEM wollen ja nicht nur etwas suchen, sondern etwas finden.

LG

pah

moin,

... das mit dem "finden" kann ich nachvollziehen...

der fpg