DS2890 wird nicht korrekt erkannt

[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