DS2890 wird nicht korrekt erkannt

[UweH]

Hallo Mitstreiter,

ich habe es nach langer Suche geschafft, doch noch funktionierende DS2890 im TO-92 Gehäuse aufzutreiben.
Jetzt gibt es aber ein Problem bei der Einrichtung.
OWServer erkennt das Ding als DS2890, legt aber kein Device an. Müsste ja im Raum OWDevice auftauchen, tut es aber nicht.
Über OWX wird das Teil mit OWID als Device erkannt, das Attribut model wird nicht automatisch belegt und auch ein händisches Eintragen nützt nichts.

Internals bei OWX:

Code Auswählen Erweitern

Internals:
   ASYNC      1
   CFGFN
   DEF        2C 79A007000000
   INTERVAL   300
   IODev      1wire_2
   NAME       OWX_2C_79A007000000
   NOTIFYDEV  global
   NR         162
   NTFY_ORDER 50-OWX_2C_79A007000000
   NUMTASKS   0
   OW_FAMILY  2C
   OW_ID      79A007000000
   PRESENT    1
   ROM_ID     2C.79A007000000.51
   STATE      present
   TYPE       OWID
   Readings:
     2016-01-28 18:34:29   present         1
     2016-01-28 18:34:18   state           Initialized
Attributes:
   IODev      1wire_2
   model      DS2890
   room       OWX
   stateFormat {ReadingsVal($name,"present",0) ? "present" : "not present"}

Nun bin ich etwas ratlos.

Gruß
Uwe

[Prof. Dr. Peter Henning]

Na ja, wenn es so schwierig ist, die Dinger aufzutreiben, nennt Dir das schon die Lösung: Kein Modulentwickler benutzt sie...

Musst wohl selbst etwas dafür schreiben ...

LG

pah

[UweH]

Na ja, wenn es so schwierig ist, die Dinger aufzutreiben, nennt Dir das schon die Lösung: Kein Modulentwickler benutzt sie...

Nee, weil offiziell ja auch nicht mehr auf dem Markt und quasi nicht beschaffbar. Bedarf und Interesse an 0 -10 V Ausgängen ist ja vorhanden, wie dieser und andere Threads zeigen.

Musst wohl selbst etwas dafür schreiben ...

Das wäre so, wie wenn ich meinen taubstummen Kollegen bitten würde, mir das Geräusch zu beschreiben, was da gerade in der Luft hängt...
Vielleicht ist einer der Interessenten an einem 1Wire 0-10V Ausgang in der Lage, was zu schreiben.
Meine neue chinesische Freundin ist jedenfalls ganz heiß drauf, die Dinger abzusetzen. Scheinbar original DS2890 in TO-92.Aber auch wenn nicht original, der One Wire Viewer erkennt sie und kann den Poti-Ausgang regeln.

Gruß
Uwe

[Prof. Dr. Peter Henning]

Interessiert bin ich durchaus, nenn mir mal die Quelle.

LG

pah

[fiedel]

In der Commandref unter "OWDevice" gibt es eine Liste unterstützter Schaltkreise, in der dein Poti leider fehlt. Dort steht aber auch:

Das Hinzufügen weiterer Geräte ist im Modulcode (subroutine OWDevice_GetDetails) sehr einfach möglich.

Vielleicht lohnt es sich da mal ginzugucken. Ich würde mir angucken, wie z.B. der 1820 oder 2405 dort eingebunden sind und versuchen es dann sinngemäß zu übertragen.

[Prof. Dr. Peter Henning]

fiedel, das ist leider nicht richtig. Man kann bei 1-Wire-Bausteinen die internen Register und die nötigen Abläufe zum Setzen NICHT von einem Baustein auf den anderen übertragen ("heiteres Registerraten").

Mal sehen, ich habe mir mal ein paar von diesen chinesischen DS2890 bestellt.

LG

pah

[fiedel]

Hi Peter,
das ist mir schon klar. Man schaut in das Datenblatt des neuen Bausteins, welche Register es wofür gibt und muss diese dann in den Code sinnvoll einfügen. Aber wie man das in der Praxis machen muss, könnte man sich an den vorh. Bausteinen abgucken. So besser? 

[Prof. Dr. Peter Henning]

Nee, eben nicht. Bei manchen der IC muss man erst interne Register umschaufeln, um sie zu lesen oder zu setzen. Die Dinger sind äußerst unterschiedlich...

Speziell beim DS2890 müssen Kommandos implementiert werden, um linear/logarithmisch, persistent/nicht persistent und die Auflösung umzuschalten.

Uwe, die 6-Pin Teile gefallen mir sogar besser, weil dort der variable Widerstand nicht gegen Masse geht.

LG

pah

[UweH]

Uwe, die 6-Pin Teile gefallen mir sogar besser, weil dort der variable Widerstand nicht gegen Masse geht.

Mir natürlich auch, nur leider gibt's die 6-poligen nicht mal beim Chinesen. Ich habe jetzt ein Jahr lang mit gefühlt hunderten Händlern Kontakt gehabt (Alibaba). Die bieten alle einen DS2890-Klon im DIL8-Gehäuse an (seltsamerweise keine SMD), aber niemand kennt die Belegung (auf Nachfrage bei den Händlern schweigen sie dann dezent). Man kann den 100kOhm-Widerstand auf Pin 5-7 messen, aber die restliche Belegung bleibt ein Mysterium. Ich habe zwei meiner Muster geopfert, um durch trial-and-error hinter die Beschaltung zu kommen, habe aber leider keinen Erfolg gehabt.
Auch die Suchmaschinen haben wiederum nur andere Käufer zu Tage gefördert, die die gleiche Frage nach der Pin-Belegung gestellt haben...
Insofern war ich erst mal ganz froh, überhaupt einen Lieferanten aufgetan zu haben, der auch Stückzahlen von dem Teil liefern kann.

Gruß
Uwe

[Prof. Dr. Peter Henning]

Ich sag doch: Die sind irgendwie an die Masken gekommen und produzieren jetzt irgendetwas.

LG

pah

[Prof. Dr. Peter Henning]

Na, dann probier doch mal die Alpha-Version des neuen Moduls aus (OWVAR muss zusammen mit OWX ersetzt werden, bitte nur in Testumgebungen verwenden.

Es funktioniert schon das Setzen eines "value" zwischen 0 und 100  (soll Prozent des Vollausschlages sein) sowie das Lesen dieses Wertes.

Ansonsten noch sehr Alpha.

LG

pah

[UweH]

Ja sowas...Danke
Hab ich gleich mal eingespielt und ein bisschen rumprobiert. Ein paarmal  hat's super funktioniert, nun bekomme ich (auch nach einem Neustart) folgende Meldung bei der Eingabe eines Value

Code Auswählen Erweitern

OWVAR: Could not set device OWX_2C_F29A07000000, reason: OWXVAR: Set failed with return value 255 from set value 0
und FHEM schmiert ab. Aber gut, Alpha

Gruß
Uwe

[Prof. Dr. Peter Henning]

FHEM schmiert ab ? Das sollt schon gar nicht vorkommen....

Weitere Entwicklung nicht vor dem 16. zu erwarten, habe noch einen EU-Projektantrag zu schreiben. Aber immerhin, die ersten Schritte sind getan.

LG

pah

[Prof. Dr. Peter Henning]

Hat mir jetzt doch keine Ruhe gelassen, also schnell noch eine halbe Stunde investiert. Hier ist die Beta-Version, probier sie mal mit

define owpot OWVAR DS2890 (hier 1-Wire ID)
attr owpot Function 1.02*V+0.58|1/1.02*(U-0.58)
attr owpot IODev (hier IO-Dev)
attr owpot Name poti
attr owpot Unit kOhm
attr owpot model DS2890
attr owpot room OWX

Warum die krummen Werte ? Wollte den value direkt in Kiloohm haben - und mein Exemplar hat einen Offset von 584 Ohm und einen maximalen Widerstand von 102,5 kOhm.

Die Attribute kann man natürlich auch weglassen.

Es sollten jetzt keine Abstürze und Fehler mehr auftauchen - demnächst kann ich das zusammen mit der aktuellen Version von OWX einchecken. Jetzt brauchen wir nur noch ein paar schöne Anwendungsfälle, und eine Sammelbestellung von DS2890....

LG

pah

[UweH]

Ich bin ja baff...Danke. Ich komme erst heute Abend wieder dazu, das zu testen. Aber der erste 0-10V-Regler hat gestern auf dem Steckbrett schon mal funktioniert... 

Gruß
Uwe

[UweH]

So, bin nun doch eher zum testen gekommen. Mit der neuen OWX-Version startet FHEM nicht, folgende Meldung im Log:

Code Auswählen Erweitern

OWX: Discover called with unknown interface DS2480
Angeschlossen ist ein USB-Busmaster. Mit einer alten OWX-Version startet FHEM problemlos. Ich habe es auf zwei verschiedenen Testumgebungen ausprobiert, gleiches Ergebnis. Kann ich noch was tun, um das Problem einzugrenzen?

Gruß
Uwe

[Prof. Dr. Peter Henning]

Klar doch. Das haben wir den nicht abgesprochenen Änderungen durch Norbert Truchsess zu verdanken. Irgendwann schmeiße ich den ganzen Müll wieder heraus...

Bitte die beiliegenden Files ebenfalls ins FHEM-Verzeichnis legen.

LG

pah

[UweH]

Klappt leider immer noch nicht. Trotz der zusätzlichen Dateien die Meldung (jetzt mit verbose 5):

Code Auswählen Erweitern

2016.02.05 20:32:34 5: Cmd: >get 1wire_USB devices<
2016.02.05 20:32:34 1: OWX: Discover called with unknown interface DS2480
2016.02.05 20:32:34 4: name: /fhem?detail=1wire_USB&dev.get1wire_USB=1wire_USB&cmd.get1wire_USB=get&arg.get1wire_USB=devices&val.get1wire_USB=&XHR=1&addLinks=1&fw_id=116 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip

Mit einer alten 00_OWX.pm sieht ein "get 1wire_USB devices" dann wieder so aus:

Code Auswählen Erweitern

2016.02.05 20:36:46 5: Cmd: >get 1wire_USB devices<
2016.02.05 20:36:47 1: OWX: 1-Wire devices found on bus 1wire_USB (Temp.AZ,OWX_28_F09339050000,OWX_2C_F29A07000000,OWX_12_36FC79000000,OWX_3A_41C002000000,LCD)
2016.02.05 20:36:47 4: name: /fhem?detail=1wire_USB&dev.get1wire_USB=1wire_USB&cmd.get1wire_USB=get&arg.get1wire_USB=devices&val.get1wire_USB=&XHR=1&addLinks=1&fw_id=130 / RL:268 / text/plain; charset=UTF-8 / Content-Encoding: gzip

[Prof. Dr. Peter Henning]

Diese Fehlermeldung kann es nur geben, wenn das Modul 11_OWX_SER.pm nicht gefunden wurde.

Bitte nochmal überprüfen, ob Du die oben mitgeschickten Module wirklich richtig installiert hast.

Ansonsten kannst Du das "neue" OWVAR auch selbst in das "alte" OWX eintragen. Dazu ist folgendes nötig:

1. Suche nach

Code Auswählen Erweitern

  $hash->{Clients} = ":OWAD:OWCOUNT:OWID:OWLCD:OWMULTI:OWSWITCH:OWTHERM:";

Da hinein muss am Ende das neue Modul, die Zeile muss also lauten

Code Auswählen Erweitern

  $hash->{Clients} = ":OWAD:OWCOUNT:OWID:OWLCD:OWMULTI:OWSWITCH:OWTHERM:OWVAR:";

2. Suche nach dem Code

Code Auswählen Erweitern

   #-- Family 29 = Switch DS2408
    }elsif( $owx_f eq "29" ){
      $chip     = "DS2408";
      $acstring = "OWSWITCH DS2408"; 
    #-- Family 3A = Switch DS2413
    }elsif( $owx_f eq "3A" ){
      $chip     = "DS2413";
      $acstring = "OWSWITCH DS2413"; 


Dieser Code dient für die automatische Erkennung der Devices, da muss das neue Module auch hinein. Er muss also lauten

Code Auswählen Erweitern

   #-- Family 29 = Switch DS2408
    }elsif( $owx_f eq "29" ){
      $chip     = "DS2408";
      $acstring = "OWSWITCH DS2408"; 
   #-- Family 2C = Potentiometer DS2490
    }elsif( $owx_f eq "2C" ){
      $chip     = "DS2890";
      $acstring = "OWVAR DS2890"; 
    #-- Family 3A = Switch DS2413
    }elsif( $owx_f eq "3A" ){
      $chip     = "DS2413";
      $acstring = "OWSWITCH DS2413"; 


Damit sollte auch das "alte" OWX mit dem neuen Modul zurecht kommen.

LG

pah

[UweH]

OK, Danke, mit dem Einfügen des Codes in eine vorherige OWX (6392) funktioniert es nun auch. Der Steckbrett-Regler dimmt hier fröhlich ein kleines 12V-Lämpchen. 
11_OWX_SER.pm und Kollegen sind korrekt im Pfad, steht auch was plausibles drin, Rechte sind richtig gesetzt, muss also auch aus meiner Sicht funktionieren. Ich schmeiß das nachher nochmal alles raus und installier es neu. Habe ich zwar gestern auch schon mindestens 10x gemacht, aber irgendwo ist ja ein Haken...

Gruß
Uwe

[UweH]

So, warum auch immer, es funktioniert nicht mit dem USB-Interface, nur über das LAN/1Wire-Interface. Ich habe gestern aber immer nur per USB getestet...
Version:

Code Auswählen Erweitern

21_OWTVAR.pm       6379 2016-02-04 22:31:34Z pahenning
00_OWX.pm          2015 pahenning
11_OWX_TCP.pm      2015 - pahenning
Über das USB-Interface funktioniert es nur mit der modifizierten "alt-" OWX. Ist mir persönlich wurscht, weil ich normalerweise eh nur über LAN auf den 1wire-Bus zugreife, merkwürdig (für mich) allemal.
OWTVAR macht jedenfalls, was es soll.
Vielen Dank für die schnelle Umsetzung 

Gruß
Uwe

[Prof. Dr. Peter Henning]

Sehr mysteriös - und sollte sich nicht auf OWVAR beschränken. Bei mir bedient genau diese Software parallel vier verschiedene USB/1-Wire und zwei TCP/IP/1-Wire an einem Raspberry Pi 2.

LG

pah

[UweH]

Jetzt brauchen wir nur noch ein paar schöne Anwendungsfälle

Den ersten habe ich seit gestern realisiert, in einem Raum regelt FHEM nun über PID20 und einen 0-10V-Stellantrieb die Temperatur. Die dazugehörige Elektronik ist noch etwas provisorisch...der Wert 4,4 zeigt die ausgegebene Spannung, die auch direkt die Ventilstellung in Prozent darstellt. Läuft.

Eigentlich der falsche Thread. Diskussionen hierzu und weiteren Anwendungsfällen würde ich eher hier führen wollen.

Viele Grüße
Uwe

[ntruchsess]

Irgendwann schmeiße ich den ganzen Müll wieder heraus...

Wenn dir der 'Müll' nicht passt, wieso verteilst Du Ihn dann selber?  (Damit meine ich jetzt explizit meine Beiträge an den OWX-dateien, die Du hier verlinkt hast. Und ich hab explizit gar nix dagengen, dass Du das tust...)

Zur Abstimmung gehören halt immer zwei. Ich würde mal sagen, dass ist beiderseitig ins Stocken geraten, ich habe seit etwa 1 Jahr ja auch nicht mehr so viel Freizeit übrig seitdem ich nebenbei 2 Fremdsprachen lerne.

[Prof. Dr. Peter Henning]

Sieh an, er lebt noch ... 

Das wird so lange weiter verteilt, wie es noch irgendwie läuft. Macht allerdings zum Einen bei vielen Usern Probleme (und Du bist eben nicht mehr verfügbar gewesen), und ist zweitens wegen der "Protothreads" immer noch keine sehr gut wartbare Lösung.

Tja, und den Wettbewerb, wer von uns beiden mehr Zeit hat, den sollten wir nicht beginnen.

LG

pah

[ntruchsess]

@pah: apropos Müll: bevor ich da jetzt unnötige Arbeit reinstecke (mit der 'alten' OWX-version kann ich OWVAR ja starten): kann es sein, dass Du Deine OWX-version nur mit 11_OWX_TCP.pm testest? mit 11_OWX_SER.pm läuft die nicht mehr zusammen, da gibt's dann einen Fehler wg. nicht existierender OWX_Read-funktion.

zurück zum Thema:

Ich bastel grad an einem Arduinobasierten DS2890-klon rum (basierend auf OneWireArduinoSlave-library). Ist komplett interruptgesteuert die lib - damit ist es echt einfach 1-Wire devices zu implementieren  . Wenns stabil läuft häng ich den Sketch hier rein.

[UweH]

mit 11_OWX_SER.pm läuft die nicht mehr zusammen,

Würde das erklären, warum die neue OWX-Version bei mir nicht mit dem USB-Interface läuft? Nur mit dem LAN-Interface klappt es, sobald ich zusammen mit dem USB-Stick starte, hängt FHEM in einer Endloschleife fest.

Ich bastel grad an einem Arduinobasierten DS2890-klon rum

Auch nicht schlecht, das würde ja einiges vereinfachen.

[Prof. Dr. Peter Henning]

Sicher nicht - ich habe vier USB-Interfaces in Betrieb.

Was steht in Zeile 53 (version) des 11_OWX_SER ?

LG

pah

[UweH]

Das:

Code Auswählen Erweitern

version => "6.0alpha2"

Gruß
Uwe

[Prof. Dr. Peter Henning]

Mal nen "downgrade" zur angehängten Version

LG

pah

[UweH]

Dat löppt, wie man hier sagen würde 
Danke

btw...zweiter (14) und dritter (15) Screenshot. Das sind zwei LAN-Interfaces und die def von einem. Der State ist frag(ezeichen)würdig

Gruß
Uwe

[ntruchsess]

bei mir auch:

Code Auswählen Erweitern

version => "6.0alpha2"

Mal nen "downgrade" zur angehängten Version

danke, mit der (version 6.0) geht dein OWX.

Gruß,

Norbert

[ntruchsess]

Ich bastel grad an einem Arduinobasierten DS2890-klon rum

Auch nicht schlecht, das würde ja einiges vereinfachen.

Und im Prinzip geht der auch schon fast (natürlich erst mal mit PWM-out, angedacht ist aber darüber bis zu 4 'echte' digitale Potentiometer per I2C anzusteuern).
Beim Wert-setzen gibts aber ein Mismatch zwischen Datenblatt und OWVAR:

Im Datenblatt (relevante Seite angehängt) sieht das so aus:
Reset => select ROMID => '0F' => <wert schreiben> => <wert lesen> => <wenn Wert richtig dann per '96' bestätigen> => <antwort lesen> => <wenn '0' dann ok>

also in einem Rutsch Wert schreiben, prüfen, bestätigen, Bestätigung prüfen.

OWVAR macht aber:
Reset => ROM => '0F' => <wert schreiben> => <wert lesen> => <Wert richtig?> => Reset => select ROMID => '96' => <antwort lesen> => <wenn 'o' dann ok>

also Wert schreiben und prüfen, dann abbrechen, das Device neu addressieren und dann erst den Wert bestätigen:

Code Auswählen Erweitern

  my $select=sprintf("\x0F%c",$pos);
  OWX_Reset($master);
  my $res=OWX_Complex($master,$owx_dev,$select,1);
  return "OWXVAR: Device $owx_dev not accessible"
     if( $res eq 0 );
  my $rv=ord(substr($res,11,1));
  return "OWXVAR: Set failed with return value $rv from set value $pos"
     if($rv ne $pos);
  my $res2=OWX_Complex($master,$owx_dev,"\x96",1);
  my $rv2=ord(substr($res2,11,1));
  return "OWXVAR: Set failed with return value $rv2 from release value"
     if($rv2 ne 0);
  OWX_Reset($master);


Wer kann mir jetzt sagen, was die echten DS2890 tatsächlich implementieren? Verstehen die beides? Weil laut Datenblatt müsste die Logic (siehe Raute in der Mitte 'Position byte OK') bei einem Bus-Reset den Part, der den Releasecode prüft und den vorher übermittelten Wert dann tatsächlich setzt, einfach überspringen.

[Prof. Dr. Peter Henning]

Wieso sollte denn dazwischen ein Busreset erfolgen ? Bei mir kommt er jedenfalls nicht vor, und der DS2890 gehorcht auch brav und setzt den Wert.

LG

pah

[ntruchsess]

äh ja, Du hast Recht, da ist kein BusReset dazwischen - da hab ich das Log nicht richtig interpretiert. Da ist kein Reset dazwischen, aber die Search-Rom-Sequenze wird noch mal geschickt:

Code Auswählen Erweitern


2016.02.21 19:58:52 3: OWX: Sending out        0xe3 0xc5
-> Command Mode: e3
-> Reset:        c5
2016.02.21 19:58:52 3: OWX: Receiving in loop no. 1 0xcd
<- Presense det. cd
2016.02.21 19:58:52 3: OWX: Sending out        0xe1 0x55 0x2c 0x00 0x00 0x00 0x00 0x00 0x02 0x56 0x0f 0x00 0xff
-> Data Mode:    e1
-> Match ROM:    55
-> ROMID:        2c 00 00 00 00 00 00 02 56
-> Write Pos:    0f
-> Wert hin:     00
-> Byte lesen:   ff
2016.02.21 19:58:52 3: OWX: Receiving in loop no. 1 0x55 0x2c 0x00 0x00 0x00 0x00 0x00 0x02 0x56 0x0f 0x00 0x00 (beachte hier, dass kein 'e1' zurück kommt. Dieses Byte schaltet den DS2480 in den Data-mode)
<- Match ROM:    55
<- ROMID:        2c 00 00 00 00 00 00 02 56
<- Write Pos:    0f
<- Wert hin:     00
<- Wert zurück:  00
2016.02.21 19:58:52 3: OWX: Sending out        0xe1 0x55 0x2c 0x00 0x00 0x00 0x00 0x00 0x02 0x56 0x96 0xff
-> hier sollte eigentlich zur Bestätigung, dass der Wert korrekt zurückgesendet wurde der Wert '96' (RELEASE-code) zur Bestätigung kommen, tatsächlich kommt aber 'e1' + ROMID und dann erst '96' 'ff' (der DS2480 ist hier ja schon im Data-mode, also schreibt er auch das 'e1' raus auf den Bus...)
2016.02.21 19:58:52 3: OWX: Receiving in loop no. 1 0xe1 0x55 0x2c 0x00 0x00 0x00 0x00 0x00 0x02 0x56 0x96 0xff
<- Die Gegenseite antwortet ab hier nur noch mit 1-Bits (damit sind alle Antwort-bits gleich den rausgeschriebenen Werten, inklusive(!) des 'e1'-Werts)


(die letzten 4 Zeilen dieses Logs sind die wichtigen...).

ändere ich in 11_OWVAR.pm die Zeile 817 von

  my $res2=OWX_Complex($master,$owx_dev,"\x96",1);

auf

  my $res2=OWX_Complex($master,undef,"\x96",1);

Wird die zweite Match-Rom-sequenze nicht mehr gesendet:

Code Auswählen Erweitern


2016.02.21 20:05:56 3: OWX: Sending out        0xe3 0xc5
2016.02.21 20:05:56 3: OWX: Receiving in loop no. 1 0xcd
2016.02.21 20:05:56 3: OWX: Sending out        0xe1 0x55 0x2c 0x00 0x00 0x00 0x00 0x00 0x02 0x56 0x0f 0x00 0xff
2016.02.21 20:05:56 3: OWX: Receiving in loop no. 1 0x55 0x2c 0x00 0x00 0x00 0x00 0x00 0x02 0x56 0x0f 0x00 0x00 (ohne führendes 'e1', dieses wird vom DS2480 nicht auf den Bus weitergegeben)
2016.02.21 20:05:56 3: OWX: Sending out        0xe1 0x96 0xff
2016.02.21 20:05:56 3: OWX: Receiving in loop no. 1 0xe1 0x96 0xff (mit führendem 'e1', weil der DS2480 schon im Data-mode ist und daher das 'e1' auf den Bus ausgibt)


aber das 'e1'-Byte vor dem '96' bleibt drin, daher wird der Wert vom meinem selbstimplementierten DS2890 nicht übernommen (schickt 'ff') zurück. (Das 'E1'-Byte kommt von OWX_Block_DS2480 (altes OWX) bzw. in 11_OWX_SER.pm aus der analogen Methode Block_DS2480, an der Stelle verhalten sich beide Implementierungen gleich).

@pah: kannst Du mir mal einen analogen Log-auszug von Dir schicken? Ist ja möglich, dass die China-DS2890 dieses Handshake intern gar nicht wirklich machen, sondern den Wert nach dem WritePosition-command '0f' einfach so ohne ReleaseKommand '96' übernehmen und daher schon auf das 'e1' mit '00' antworten.

[Prof. Dr. Peter Henning]

Aktuell habe ich meinen einzelnen DS2890 gar nicht in Betrieb, wird sicher übermorgen.

LG

pah

[UweH]

Ich habe zwei in Betrieb. Wenn Du mir sagst, wie ich an die Daten komme, kann ich sie Dir zur Verfügung stellen.

Gruß
Uwe

[ntruchsess]

@Pah: kein Stress
@UweH: das ist nett von Dir. Wenn Du vor übermorgen dazu kommst: Einfach im 00_OWX.pm die Variable $owx_debug=3 setzen. In der Version von Pah (6.0alpha3) ist das in Zeile 126, in der aktuellen 'offiziellen' SVN-Version in Zeile 100.

Dann fhem einfach mit OWX und OWVAR starten, am OWVAR-device ein 'get <owvardevice> value' absetzen, fhem wieder runterfahren und log hier anhängen.

Gruß,

Norbert

[UweH]

Mach ich, wird aber leider erst heute Abend...

[UweH]

Tja...
Also entweder muss ich noch an einer anderen Schraube drehen oder ich hab mal wieder den Sonderfall erwischt...im Log taucht aber auch so gar nichts auf.

[ntruchsess]

@UweH: Du, mach Dir nix draus wenn das mit dem Log nicht hinhaut. Wenn Dein DS2890 in den nächsten Tagen hier ist (danke schon mal für die schnelle Aktion) kann ich selber ja genug damit rumspielen.

Meine OWX-Async-anpassung von OWVAR redet jedenfalls schon erfolgreich mit dem (streng nach Datenblatt implementierten) Arduino-basierten DS2890-clon. Bin gespannt, ob sie mit dem 'original' aus China auch tut:

21_OWVAR.pm
00_OWX_ASYNC.pm
OWX_DS2480.pm

wer das mal ausprobieren will: Um das im Datenblatt des DS2890 beschriebene (und im vorherigen Post bemängelte) Handshake beim Set-position sauber umzusetzen musste ich das OWX_ASYNC etwas umbauen, es ist daher inkompatibel mit den bisherigen Device-modulen. Die habe ich der Vollständigkeit halber auch schon mal auf dieses Refaktoring angepasst, aber (außer OWTHERM) noch nicht selber getestet (auch sonst bisher auch nur mit einem USB-basiertem DS2480 Busmaster, Firmata etc... kommt dann noch):

21_OWAD.pm
21_OWCOUNT.pm
21_OWLCD.pm
21_OWMULTI.pm
21_OWSWITCH.pm
21_OWTHERM.pm

Ich denke, ich werde die Firmware mit einer Ansteuerung für bis zu 4 I2C-basierte digitale Potis versehen (das sieht das DS2890-protokol so vor) und das ganze noch auf einen ATTiny85 anpassen. Fehlt eigentlich nur noch jemand, der dann eine Platine für den Clon entwirft

Ach ja, hier noch der Arduino-sketch mit zugehöriger Lib (Prototyp, erst mal nur das Protokol, noch keine Ansteuerung eines externen Potis)
DS2890.ino
OneWireSlave.h
OneWireSlave.cpp

Gruß,

Norbert

[Prof. Dr. Peter Henning]

@Norbert:

Bitte keine Änderungen an den älteren Modulen einchecken, ohne dass ich die mit meinen laufenden Modifikationen abgeglichen habe.

LG

pah

[ntruchsess]

@Pah: Keine Sorge, ich fass da aktuell eh nur den OWX_ASYNC-teil an, das sollte sich schmerzlos mergen lassen. Liegen Deine aktuellen Arbeitsversionen in Deinem SVN? Dann würde ich vor einem Commit ins FHEM-svn selbstverständlich erst mal gegenchecken.

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Nein, wir haben unser SVN im Rahmen meines letzten EU-Forschungsprojektes auf einen komplett anderen Server umgezogen.

Schick mir einfach Deine fertigen Versionen,

LG

pah

[UweH]

Fehlt eigentlich nur noch jemand, der dann eine Platine für den Clon entwirft

Ich fühle mich ein bisschen angesprochen... 
Tiny85 ist sicher oder könnte sich das noch ändern? Hast Du schon ein spezielles Poti-IC im Auge? Im Prinzip eignet sich ja jedes I²C-fähige Poti mit 256 Schritten, z.B. MCP4552 oder AD5243 (Dual)...usw.

Gruß
Uwe

[ntruchsess]

100% sicher ist das mit dem ATiny85 noch nicht. Das Teil hat keinen Hardware-I2C hat und der 1-Wire-Slave ist sehr Timekritisch. Werde mir erst mal die I2C-libs zu gemüte führen, ob sich das zu sehr in die Quere kommt. Wobei sich das grundsätzlich schon lösen lassen sollte - der I2C ist in dem Fall ja Master und muss daher (im Gegensatz zum 1-Wire Slave) nur beschränkt echtzeittauglich sein.
Und in die 8K muss es natürlich auch noch reinpassen - der hex-file für den DS2890 auf ATmega328p ist ohne Ansteuerung eines Potis aktuell schon etwas über 4kb groß. Man wird sehen, muss mir erst mal ein paar digitale Potis bestellen.

[ntruchsess]

so, der Arduino-clon macht Fortschritte: DS2890.ino.

Der sketch kann digitale Potis aus der MCP455x-serie über I2C ansteuern. Z.B. können 2 MCP4651 mit jeweils 2 Potis am Arduino hängen, der sich gegenüber dem 1-Wire wie ein DS2890 mit 4 Potis verhält. Um auch andere Chips zu unterstützen implementiert die mcp455x-klasse ein generisches Potentiometer-interface. Damit sind im DS2890.ino-sketch selbst nur ein paar Zeilen zu ändern um eine anderen Chip dranzuhängen.

Auf der FHEM-seite wird das unter OWX_ASYNC auch mehr oder weniger voll unterstützt (Download siehe Links in vorherigem Post). Mit einem original (china)-DS2890 (danke noch mal an UweH!) funktioniert auch alles (natürlich nur 1 Poti im Chip...). Braucht nur noch etwas 'Feinschliff', dann kann ich das einchecken.

@UweH: das mit dem ATiny bin ich noch nicht praktisch angegangen, denke aber das könnte schon funktionieren. Und falls nicht, kann man immer noch auf ATmega88 oder 168 gehen, damit geht's auf jeden fall. So viel teurer sind die ja auch net.

Gruß,

Norbert

[UweH]

Moin Norbert,

ich habe mal versucht, den Sketch zu kompilieren, kriege aber viele Fehlermeldungen. Ich hoffe, die Wire.h und die Arduino.h, die ich gefunden habe, sind korrekt. Vielleicht kannst Du Deine Versionen mal mit anhängen.

Gruß
Uwe

[ntruchsess]

Hm, ich benutze seit ein paar Wochen Eclipse (mit dem Plugin von http://eclipse.baeyens.it/). Da sind die Libraries von der 1.6.9er Arduino-IDE dabei. Habs grade noch mal mit ner junfräulichen 1.6.5er IDE probiert (alles auf Linux), damit compilierts auch fehlerfrei. An der Wire-lib ist ja eigentlich auch schon ewig nix geändert worden?

Was gibt's denn für Fehler?

Gruß,

Norbert

[UweH]

Ich benutze die 1.6.7 auf Linux. Die Dateien liegen alle im gleichen Ordner.
So sieht's aus:

Code Auswählen Erweitern

Arduino: 1.6.7 (Linux), Board: "Arduino Nano, ATmega328"

OneWireIO:7: error: redefinition of 'Pin oneWireData'
Pin oneWireData(2);
                ^
DS2890:37: error: 'Pin oneWireData' previously declared here
Pin oneWireData(2);
     ^
OneWireIO:12: error: redefinition of 'const byte owROM [7]'
const byte owROM[7] = { 0x28, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 };
                   ^
DS2890:45: error: 'const byte owROM [7]' previously defined here
const byte owROM[7] = { 0x2C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 };
            ^
OneWireIO:22: error: multiple definition of 'enum DeviceState'
enum DeviceState
      ^
DS2890:71: error: previous definition here
enum DeviceState {
      ^
OneWireIO:29: error: redefinition of 'volatile DeviceState state'
volatile DeviceState state = DS_WaitingReset;
                      ^
DS2890:80: error: 'volatile DeviceState state' previously defined here
volatile DeviceState state = DS_WaitingReset;
                      ^
/home/uwe/Arduino/OneWireArduinoSlave-DS2890/DS2890/OneWireIO.ino: In function 'void setup()':
OneWireIO:39: error: redefinition of 'void setup()'
void setup()
      ^
DS2890:98: error: 'void setup()' previously defined here
void setup() {
      ^
/home/uwe/Arduino/OneWireArduinoSlave-DS2890/DS2890/OneWireIO.ino: In function 'void loop()':
OneWireIO:49: error: redefinition of 'void loop()'
void loop()
      ^
DS2890:109: error: 'void loop()' previously defined here
void loop() {
      ^
OneWireIO:60: error: 'DS_ConvertingTemperature' was not declared in this scope
  if (localState == DS_ConvertingTemperature && millis() > localConversionStartTime + 750)
                    ^
OneWireIO:74: error: 'DS_TemperatureConverted' was not declared in this scope
   state = DS_TemperatureConverted;
           ^
/home/uwe/Arduino/OneWireArduinoSlave-DS2890/DS2890/OneWireIO.ino: In function 'void owReceive(OneWireSlave::ReceiveEvent, byte)':
OneWireIO:80: error: redefinition of 'void owReceive(OneWireSlave::ReceiveEvent, byte)'
void owReceive(OneWireSlave::ReceiveEvent evt, byte data)
      ^
DS2890:124: error: 'void owReceive(OneWireSlave::ReceiveEvent, byte)' previously defined here
void owReceive(OneWireSlave::ReceiveEvent evt, byte data) {
      ^
OneWireIO:91: error: 'DS_ConvertingTemperature' was not declared in this scope
     state = DS_ConvertingTemperature;
             ^
exit status 1
redefinition of 'Pin oneWireData'


[ntruchsess]

Die Dateien liegen alle im gleichen Ordner.

Code Auswählen Erweitern


OneWireIO:7: error: redefinition of 'Pin oneWireData'
Pin oneWireData(2);


Lösch die OneWireIO.ino, die liegt da fälschlicherweise noch mit drin. Das ist der Beispielssketch, der mit der OneWireArduinoSlave-library mitkommt.

[UweH]

OK, das war's aber noch nicht ganz. Da sind noch einige Abhängigkeiten, z.B. sam.h, hab ich gefunden, jetzt will er noch "adc.h" haben...

Code Auswählen Erweitern


In file included from sketch/Arduino.h:26:0,
                 from sketch/OneWireSlave.h:28,
                 from sketch/OneWireSlave.cpp:25:
sketch/chip.h:44:25: fatal error: include/adc.h: No such file or directory
#include "include/adc.h"

[UweH]

Wenn ich mir die ganzen includes ansehe...da fehlt noch mehr, das sieht nach einer kompletten library aus

[ntruchsess]

sam.h

irgendwie scheint mir Dein Include-pfad wo ganz anders hin zu zeigen
Hast Du denn eine ATmega328p-basiertes Board (Uno, Nano oder Mini) ausgewählt? sam.h klingt mir eher nach Due

[UweH]

Ich habe den Nano ausgewählt...

[ntruchsess]

Für mich sieht das danach aus, dass die IDE nicht dir richtigen Includes benutzt (sondern welche, die ein anderes Packet mitbringt). Man kann in den Einstellungen der Arduino-ide einstellen, dass man den kompletten Compiler-output zu sehen bekommt. Dann sieht man was von woher(!) inkludiert wird (und ob das überhaupt zur IDE gehört).

[UweH]

Ich habe das jetzt mal unter Windows probiert und da läuft's. Das war leider vergeudete Zeit, aber so weiß ich wenigstens, wo der Fehler war.
Danke erstmal.

Du hast Pin2 als 1-Wire-Port definiert, es sollte also ein 1-Wire-Device beim Suchlauf gefunden werden...oder?

Gruß
Uwe

[UweH]

Soooo...er tut es 
Merkwürdigerweise klappt das Hochladen nicht per USB, bricht mit Fehlern ab. Hochladen per Programmer (AVRISP mkII) dagegen läuft durch.
Das Setzen eines value quittiert OWVAR so:

Code Auswählen Erweitern

OWVAR: Could not set device OWX_2C_000000000002, reason: OWXVAR: Set failed with return value 255 from release value

Edit: *aufdiestirnklatsch* Verdammt, ich muss die OWX-Dateien noch anpassen, kann nicht funktionieren...

[ntruchsess]

Soooo...er tut es 

kaum macht man's richtig, schon geht's 

Das Setzen eines value quittiert OWVAR so:

Code Auswählen Erweitern

OWVAR: Could not set device OWX_2C_000000000002, reason: OWXVAR: Set failed with return value 255 from release value

das ist zu erwarten, wenn Du noch nicht:

Edit: *aufdiestirnklatsch* Verdammt, ich muss die OWX-Dateien noch anpassen, kann nicht funktionieren...

-> auf OWX_ASYNC (vor vorher hier angehängt) mit DS2480 (über USB oder Ethernet...) - alles andere geht (noch) net.

Viel Erfolg!

Gruß,

Norbert

[UweH]

kaum macht man's richtig, schon geht's 

Ja...immer das Gleiche...das größte Problem ist 30cm vor dem Bildschirm 

Aber jetzt läuft's und die MCP4651 sind auch schon geordert. Den MAX4162 habe ich mittlerweile hier, aber wahrscheinlich in der Woche eher weniger Zeit, mich damit zu befassen.

Gruß
Uwe

[ntruchsess]

Ja...immer das Gleiche...das größte Problem ist 30cm vor dem Bildschirm 

ein sogenannter pebkac  (problem exists between keyboard and chair)

und die MCP4651 sind auch schon geordert

Auf die warte ich auch noch. Und weil ich nicht solange warten wollte habe ich mir einfach einem mit einem 2. Arduino emuliert

[UweH]

habe ich mir einfach einem mit einem 2. Arduino emuliert

Na toll  ...ich bastele und scheitere seit Tagen an einem Arduino-Anfängerproblem und Du knotest eine Poti-Emulation zusammen...Neid 

Gruß
Uwe

[UweH]

Hallo Norbert,

ich habe jetzt die MCP4651 hier und möchte mal ein bisschen spielen...ist der Arduino schon dafür fit und wenn ja, welche Pins hast Du für SDL und SCA definiert? Finde ich im Sketch nicht...

Gruß
Uwe

[UweH]

Ich bekomme den "set"-Button nicht mehr angezeigt, was fehlt da? 

[ntruchsess]

welche Pins hast Du für SDL und SCA definiert? Finde ich im Sketch nicht...

Sorry, hatte ein paar Tage keine Zeit mich mit dem Thema zu befassen...

SCA und SDL sind durch die Hardware festgelegt und lassen sich nicht konfigurieren. Auf einem Uno beispielsweise: 'TWI: A4 or SDA pin and A5 or SCL pin. Support TWI communication using the Wire library.'

der code in meinem Branch DS2890 sollte soweit funktionieren. Im DS2890.ino musst Du ggf. die Zahl der angesteuerten MCP455x und die Zahl der darin befindlichen Potis anpassen (da sind aktuell 2 hinterlegt, die I2C-addresse des 2. wäre um 1 größer als die des ersten. Je MCP455x wären 2 Potis implementiert, macht zusammen 4 Stück - siehe Array 'wiperPositions[4]'.

Wenn man poti[] und wiperPositions anpasst, muss man natürlich schleifen in setup und loop entsprechend anpassen...

[UweH]

ggf. die Zahl der angesteuerten MCP455x und die Zahl der darin befindlichen Potis anpassen (da sind aktuell 2 hinterlegt, die I2C-addresse des 2. wäre um 1 größer als die des ersten. Je MCP455x wären 2 Potis implementiert, macht zusammen 4 Stück - siehe Array 'wiperPositions[4]'.

Wenn man poti[] und wiperPositions anpasst, muss man natürlich schleifen in setup und loop entsprechend anpassen...

Aha...??
Gelesen, aber keinen Deut schlauer. Wenn die Sonne in den nächsten Tagen mein Gehirn wärmt, verstehe ich es vielleicht auch 

Gruß
Uwe

[Prof. Dr. Peter Henning]

Mein Gehirn ist vor Sonne geschützt. Ist auch besser so, die Chips sind empfindlich.

LG

pah