LCD funktioniert nicht in FHEM mit OWServer / OWDevice

Begonnen von harry-th, 14 Januar 2016, 12:37:18

Vorheriges Thema - Nächstes Thema

harry-th

Hallo,
ich habe jetzt schon seit 2 Tagen versucht, herauszubringen, wie man ein LCD welches über das Adaptermodul von Louis Swart am 1-wirebus angeschlossen ist, unter FHEM ans Laufen bekommt.
Mein FHEM läuft auf einem BananaPro mit installiertem owserver. Als 1-Wire Busmaster verwende ich die RPI2 Platine von Sheepwalk Electronics mit dem 2482-100.
Ich kann das LCD via <IP BananaPro>:2121 ansprechen und da funktioniert auch alles (ein/Ausschalten, Backlight an/aus, Text ausgeben, ...).
In FHEM habe ich folgende Definitionen:
Server:

define OneWireServer OWServer localhost:4304
attr OneWireServer nonblocking 1
attr OneWireServer room OneWire

Device:

define lcd_20x4 OWDevice FF.4B0900000100 30
attr lcd_20x4 IODev OneWireServer
attr lcd_20x4 model LCD
attr lcd_20x4 room OneWire

Wenn ich versuche, mit "set lcd_20x4 LCDon 1" es einzuschalten, tut sich nix.
Auch ein "set lcd_20x4 backlight 1" bewirkt nichts.
Ich sehe jedoch, dass die readings upgedated werden. Auch die Tasten kann ich einlesen.
Es scheint dass das Displayadapterboard korrekt eingebunden ist, nur alles was aufs Display gehen soll funktioniert nicht.
Ich habe in einem anderen thread gelesen, dass man das Display in der 99_myUtils.pm irgendwie initialisieren muss aber daraus bin ich nicht schlau geworden.
Ich bin momentan mit meinem Latein am Ende.
Es wäre nett, wenn mir jemand auf die Sprünge helfen könnte.

Vielen Dank Vorab

Harald

det.

Hallo Harald,
Wenn Du es mit OWX versuchen möchtest, kann ich Dir Beispielcode zukommen lassen. Funktioniert seit Jahren zuverlässig.
LG
det.

harry-th

Hallo det.
vielen Dank für das Angebot!
Ich hatte in irgendeinem der vielen Threads gelesen, dass OWserver/ OWDevice das modernere Konzept wären und OWX nicht mehr weiter gepflegt würde.
Falls das eine falsche Annahme ist würde ich gerne mal versuchen das Display mit OWX ans Laufen zu bekommen.
Muss ich da den owserver auf meinem BananaPro wieder entfernen oder greift OWX auch auf diese Schnittstelle zu?

danke schon mal im Voraus

Viele Grüße

Harald

det.

Hallo Harald,
das ist hier im Forum so was wie die Glaubensfrage Vorder- oder Hinterradantrieb. Habe beides probiert und bin bei B** und OWX geblieben. Läuft sehr stabil, Dank an pah! Zur Weiterentwicklung - da muß nicht laufend was rumentwickelt werden, wenn das Zeugs macht was es soll.  Ich denke, zum Probieren schadet es nicht, wenn der OWserver im Hintergrund weiterläuft, Du ihm in FHEN aber keinen Adapter zuweist. Ich sende Dir mal etwas aus meiner fhem.cfg per pm, wenn ich wieder daheim bin. Ganz wichtig ist mEn eine stabile 5V Versorgung des 1-wire Systems, dazu gibts hier im Forum genug zum Nachlesen.
Ich bitte darum hiermit keinen shitstorm ausgelöst zu haben auch hatte ich nicht vor Audi und VW Fahrer zu beleidigen!
LG
det.

Prof. Dr. Peter Henning

"Das modernere Konzept", rofl.

"OWX nicht mehr weiter entwickelt", soso. Wer hat denn das dämliche Gerücht in die Welt gesetzt ?

Allerdings braucht man in der Tat für Hardware, die stabil ist, auch stabile Software.

LG

pah

harry-th

Hallo det.
vielen Dank soweit.
Jetzt hab ich nur noch das Problem, dass ich meinen 1-Wire Busmaster via I2C am BananaPro angeschlossen habe.
Lt. Commandref unterstützt OWX nur USB oder Netzwerk.
In einem thread wird angedeutet, dass evtl. auch I2C integriert werden würde
http://forum.fhem.de/index.php?topic=18808.0
Ist da noch was passiert was in der Commandref noch nicht nachgezogen worden ist oder bleibt dann nur der Weg über Arduino?

danke für die Unterstützung

Gruß

Harald

det.

Hallo Harald,
Frag mal Locutus, ob er Dir einen seiner Eigenbau USB Adapter verkauft oder bestell Dir einen von PC Sensors. Ist eh besser, wenn Du davon was zum Wechseln da hast, wenn mal wieder Gewittersaison mit Überspannung kommt - der größte Feind der Hausautomatisierung.
LG
det.

harry-th

Hallo det.
danke für den Tip aber leider sind meine USB-Buchsen schon alle belegt und einen Hub will ich aus Gründen der Energieeffizienz nicht dranhängen.
Außerdem hab ich nun eben schon diesen Busmaster gekauft.
Muss ich hoffen dass sich vielleicht doch noch jemand findet, der mir einen Tip für meine Konfiguration geben kann.

trotzdem vielen Dank für deine Hilfe

Gruß

Harald

Prof. Dr. Peter Henning

Pardon, aber "Keinen Hub aus Gründen der Energieeffizienz" ist kompletter Unsinn. Ein passiver Mini-Hub ist im Eigenverbrauch vernachlässigbar.

LG

pah

harry-th

Hallo pah,
ein passiver Hub kann aber auch nicht mehr als das liefern, was der USB Anschluss hergibt (hier 500 mA) und da es bei den bisher angeschlossenen Geräten nicht so einfach ist, den Maximalstromverbrauch zu kalkulieren, möchte ich hier auf der sicheren Seite bleiben, also wenn Hub dann aktiv.
Der RPI2 I2c to 1-Wire Busmaster hängt direkt an den 5V die meinen BananaPro speisen (max 3A), da sollte es kein Problem mit dem Stromverbrauch geben.

Viele Grüße

Harald

Prof. Dr. Peter Henning

Natürlich sollte man den 1-Wire Bus in der Regel immer am USB-Anschluss vorbei mit Spannung versorgen.

LG

pah

ext23

Zitat von: harry-th am 18 Januar 2016, 12:39:43
da es bei den bisher angeschlossenen Geräten nicht so einfach ist, den Maximalstromverbrauch zu kalkulieren, möchte ich hier auf der sicheren Seite bleiben, also wenn Hub dann aktiv.

Das sind doch dann nur 2 Geräte (1Wire + X) oder was verstehe ich da gerade nicht. Und dann melden Geräten ja eigentlich ihren Stromverbrauch vorher, es sei denn es ist was selbst gebasteltes ;-)

Bei mir läuft das LCD übrigens auch. Ich nehm auch das OWX aber diese Async Variante.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

harry-th

Hallo Daniel,
ich hab über meine 2 USB Schnittstellen eine FHZ1350 und einen CUL angeschlossen.
Der Plan ist, alles 1-Wire spezifische über die I2C-Schnittstelle mit einem I2C to 1-Wire Modul abzuhandeln.
In anderen Threads in diesem Forum behaupten etliche user, dass bei ihnen die Konfiguration OWServer/OWDevice mit dem LCD-Modul von Louis Swart einwandfrei funktioniert.
So wie es aussieht scheint es nur igendein kleines Detail zu sein, welches ich noch nicht richtig mache.
Wenn ich über das WEB-Interface von owfs auf meinem BananaPro auf das LCD zugreife, funktioniert es perfekt.
Ich habe festgestellt, dass, wenn ich das LCD via WEB-Interfcae einschalte und dann via FHEM "set lcd_20x4 line20.0 abcdefg" ausgebe, auf dem Display erscheint: "bcdef||".
Ein- und Ausschalten und Backlight an/aus via FHEM geht aber definitiv nicht.
Warum es via WeEB-Interface geht und via FHEM nur halb ist mir ein Rätsel.
Villeicht hat ja jemand, bei dem es in meiner Konfiguration läuft noch einen Tip für mich.

Viele Grüße

Harald

harry-th

Hallo,
ich habe jetzt nach viel herumprobieren einige neue Erkenntnisse, warum das Schreiben mit 1-wire devices in Verbindung mit OWServer nicht richtig funktioniert.
Ich habe testhalber die neueste Version von OWFS (3.1p1) installiert um zu sehen ob die sich anders verhält aber auch hier macht das Schreiben Probleme.
Alles was gelesen werden kann funktioniert einwandfrei.
Ich habe durch Herumprobieren herausgefunden, dass das Schreiben auch funktioniert, wenn man vor den zu schreibenden Wert eine 0 einfügt, also z.B.
set MyDS18B20 temphigh 050
Dann wird mit
get MyDS18B20 temphigh
der Wert 50 zurückgegeben.
Wenn ich
set MyDS18B20 temphigh 50
schreibe, dann wird 0 zurückgelesen.
Im Falle des LCD Displays (4x20) kann ich die Beleuchtung einschalten mit
set MyLCD backlight 01
während
set MyLCD backlight 1
nichts bewirkt.
Wenn ich Text ans LCD schicken will bewirkt
set line20.0 abcdefg
die LCD Anzeige
bcdefg||
während die Eingabe
set line20.0 0abcdefg
die Anzeige
abcdefg||
bewirkt

Für mich sieht es so aus, dass beim Schreiben der Pointer um 1 versetzt ist, ich weiss aber nicht ob das im FHEM Modul oder beim OWFS passiert.
Ich bin leider nicht so gut, dass ich durch Studium der Sourcen dem Fehler auf die Spur kommen kann.

Falls mir jemand dabei helfen könnte, wäre ich sehr dankbar.

Gruß

Harald

fruit

#14
I am having similar problems to harry-th with my new Louis Swart LCDs. I also have a Sheepwalk Electronics interface and owserver on a separate Pi running raspbian jessie.
Everything 1-wire is fine except for the LCDs

Yesterday I set up another Pi running raspbian jessie with a second Sheepwalk Electronics interface and an updated instance of fhem, same LCD problems with owfs-2.9p8
Today I have set the same hardware up with raspbian wheezy - and the LCD works as it should with owfs-2.8p15

Looks to me as though the problem is within the current owfs - sadly I'm not clever enough to even know where to look :\

Edit: Replacing owfs-2.9p8 and related packages with owfs-2.8p15 versions in jessie corrects the problem - here anyway.
owfs_3.1p1-2 etc. show the same corruption.
Feel free to follow up in German if you prefer