Bekomme von der installierten RTC immer das gleiche Datum und Uhrzeit angezeigt.
Siehe Anhang.
Die Aufrufe auf der Console zeigen aber das das Modul funktioniert.
i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Die Config unter FEHM sieht so aus.
#####################################
### INPUT I2C Bus 1 ###
#####################################
define RPiI2C_1 RPII2C 1
attr RPiI2C_1 alias I²C Schnittstelle
attr RPiI2C_1 devStateIcon Ok:it_net@green initialized:it_net@yellow disconnected:it_net@red error:it_net@red
attr RPiI2C_1 group Schnittstellen I2C
attr RPiI2C_1 icon it_net
attr RPiI2C_1 room _RxTx
### RTC
define RTC I2C_DS1307 0x68
attr RTC IODev RPiI2C_1
attr RTC alias Echtzeituhr
attr RTC devStateIcon Ok:it_net@green Initialized:it_net@yellow Disconnected:it_net@red Error:it_net@red
attr RTC icon icoUhr
attr RTC room _Timer
attr RTC stateFormat datetime
Ist hier noch etwas zu ergänzen was unter FHEMWIKI und Commandref nicht angeführt ist damit die RTC auch richtig funktioniert?
Ergänzend noch die LOG Einträge.
2016.08.27 16:41:32 1: PERL WARNING: Argument "0x68" isn't numeric in sprintf at ./FHEM/00_RPII2C.pm line 432.
2016.08.27 16:41:32 3: RPiI2C_1: HWaccess blockweise von 0x00 lesen, Reg: 0x00 -> syswrite failure: Eingabe-/Ausgabefehler
2016.08.27 16:41:32 1: PERL WARNING: Exiting subroutine via last at ./FHEM/00_RPII2C.pm line 510.
2016.08.27 16:41:32 1: PERL WARNING: Exiting eval via last at ./FHEM/00_RPII2C.pm line 510.
Muss für das RTC Modul die Adresse anders geschrieben werden?
scheinbar verarbeitet das Modul den Hexwert nicht. Versuche mal die Dezimalversion von 0x68 -> 104
Das dürfte wirklich so sein, dass hier der Dezimalwert eingetragen werden muss.
Sollte eigentlich im Commandref usw. angeführt werden wie die Eingabe der Adresse erfolgen soll.
Mit dem dezimal Eintrag wurde jetzt ein Datum mit Uhrzeit von 1922-10-11 20:28:24 ausgeben.
Vorher war es 1970-01-01 01:00:00.
Aber irgendwie passt hier trotzdem etwas anderes auch noch nicht.
Das set datetime und now wird auch nicht übernommen trotz richtiger schreibweise.
Egal was ich ausführe erscheint immer als Antwort diese Zeitangabe 1970-01-01 01:00:00.
Zitat von: Burny4600 am 29 August 2016, 16:05:43
Das dürfte wirklich so sein, dass hier der Dezimalwert eingetragen werden muss.
Sollte eigentlich im Commandref usw. angeführt werden wie die Eingabe der Adresse erfolgen soll.
Mit dem dezimal Eintrag wurde jetzt ein Datum mit Uhrzeit von 1922-10-11 20:28:24 ausgeben.
Vorher war es 1970-01-01 01:00:00.
Aber irgendwie passt hier trotzdem etwas anderes auch noch nicht.
Das set datetime und now wird auch nicht übernommen trotz richtiger schreibweise.
Egal was ich ausführe erscheint immer als Antwort diese Zeitangabe 1970-01-01 01:00:00.
Das Logfile sieht normal aus?
Kannst du den DS1307 in der Shell korrekt setzen und zurücklesen? Wenn ja, was gibt in diesem Fall FHEM aus?
Ich habe das Modul nie getestet (kann es, mangels Hardware auch nicht).
Allerdings hatte Norbert das nur zum testen geschrieben. Vermutlich hat er das auch getestet... aber dann nur im Zusammenhang mit FRM.
Über welches physikalische Device nutzt du das Modul?
In der Shell habe ich mit dem Modul ohne Probleme die Zeit auslesen können.
Eingebunden mit echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
Mit hwclock -r die Uhrzeit korrekt ausgelesen.
date war auch richtig und mit hwclock -w ändern war auch kein Problem.
Im Commandref kann dieser Eintrag so auch nicht stimmen.
Set
set <name> datetime; set DS1307 time. Format is JJJJ-MM-DD HH:MM:SSdisplayed>
Ein time gibt es nicht, und SSdisplayed> hätte auch etwas anderes wahrscheinlich darstellen sollen.
Ist etwas schwierig aus der Ferne...
Das "displayed" muss du dir wahrscheinlich wegdenken....
Ich habe in den Code reingeschaut. JJJJ-MM-DD HH:MM:SS sollte funktionieren, zumindest bei "set datetime"
Bei set time scheint eher die Unixzeit gemeint zu sein.
ändert sich was an Datum/Uhrzeit, wenn du diese Über die Konsole änderst?
Was kommt denn mit einem verbose 5 beim lesen/schreiben der Uhrzeit?
In der Shell läst sich die Zeit ohne Probleme setzten.
sudo hwclock --set --date="MM/TT/JJJJ HH:MM:SS"
LOG der RTC
2016.08.30 11:10:04 5: im init client fuer RTC
2016.08.30 11:10:39 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/52_I2C_DS1307.pm line 179.
2016.08.30 11:10:39 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/52_I2C_DS1307.pm line 320.
2016.08.30 11:10:39 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/52_I2C_DS1307.pm line 282.
Uhrzeit mit datetime unter FHEM setzten.
2016.08.30 12:24:02 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/52_I2C_DS1307.pm line 326.
2016.08.30 12:24:02 3: RPiI2C_1: HWaccess (0x68) ioctl failure: Das Gerät oder die Ressource ist belegt
Zitat von: Burny4600 am 30 August 2016, 12:17:27
Uhrzeit mit datetime unter FHEM setzten.
2016.08.30 12:24:02 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/52_I2C_DS1307.pm line 326.
2016.08.30 12:24:02 3: RPiI2C_1: HWaccess (0x68) ioctl failure: Das Gerät oder die Ressource ist belegt
Die letzte Zeile sagt doch recht viel aus...
Es ist kein Zugriff auf die I2C Bus Adresse 0x68 möglich
Im Modul wird das vermutlich nicht abgefangen und als 0 interpretiert ... und das ist in unix Zeit der 1.1.70
evtl. ist sie nach "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device" blockiert
funktioniert denn i2cread noch auf die Adresse 0x68?
Sollte man die Uhrzeit einer Hardwareplattform ohnehin nicht besser auf der Betriebssystemebene verwalten, anstatt solche Krämpfe innerhalb einer High-Level-Applikation wie fhem zu versuchen?
Eine Uhrzeit auf der Hardware innerhalb von fhem zu verändern, kann ohnehin sehr unerwünschte Nebeneffekte haben, weil der Zeitpunkt dafür eigentlich viel zu spät ist / sein kann.
Eigentlich sollte fhem erst gestartet werden, wenn die Uhrzeitfrage der Hardware eindeutig geklärt ist.
@klausw
Du hast recht. Die RTC war durch den Shell Test blockert.
Zeitangabe nochmals unter Fhem mit zugehörigen Verbos 5 LOG.
2016.08.30 13:43:55 5: im init client fuer RTC
2016.08.30 13:44:55 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/52_I2C_DS1307.pm line 179.
2016.08.30 13:44:55 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/52_I2C_DS1307.pm line 320.
2016.08.30 13:44:55 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/52_I2C_DS1307.pm line 282.
Vielleicht liegt der Fehler bei der Adressauswertung in der pm Datei wo dezimal und hex vertauscht ist.
@betateilchen
Da gebe ich dir Recht.
Nur das Modul wurde für FHEM schon einmal erstellt, darum wollte ich das Modul bei mir in Fhem einbinden.
Zitat von: Burny4600 am 30 August 2016, 13:51:20
@klausw
Du hast recht. Die RTC war durch den Shell Test blockert.
Zeitangabe nochmals unter Fhem mit zugehörigen Verbos 5 LOG.
2016.08.30 13:43:55 5: im init client fuer RTC
2016.08.30 13:44:55 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/52_I2C_DS1307.pm line 179.
2016.08.30 13:44:55 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/52_I2C_DS1307.pm line 320.
2016.08.30 13:44:55 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/52_I2C_DS1307.pm line 282.
Vielleicht liegt der Fehler bei der Adressauswertung in der pm Datei wo dezimal und hex vertauscht ist.
Was hat zu dem oben gelisteten Logauszug geführt?
Wie ich das sehe, werden keine Daten angefordert.
Versuche mal noch ein get <name>
Die Zeile
2016.08.30 12:24:02 3: RPiI2C_1: HWaccess (0x68) ioctl failure: Das Gerät oder die Ressource ist belegt
zeigt, das die I2C Adresse korrekt ist (ich rechne hier in Hex um).
Zugegebenermaßen ist die Adressangabe in diesem Fall nicht so ganz konsistent.
Get Befehle sind nicht inkludiert für das I2C_DS1307.
Es gibt nur zwei set Möglichkeiten unter FHEM.
set <RTC> datetime
und
set <RTC> now Zitat2016.08.30 12:24:02 3: RPiI2C_1: HWaccess (0x68) ioctl failure: Das Gerät oder die Ressource ist belegt
Dieser Eintrag entstand weil ich keinen reboot nach den Shelltests gemacht hatte.
Zitat von: Burny4600 am 30 August 2016, 13:51:20
Nur das Modul wurde für FHEM schon einmal erstellt, darum wollte ich das Modul bei mir in Fhem einbinden.
Die bloße Existenz eines Moduls ist noch lange kein Grund, es auch tatsächlich zu benutzen.
Es gibt eine ganze Reihe von fhem-Modulen, die man besser ungeschehen machen sollte. Und selbst mir als Modulentwickler ist es schon passiert, dass ich ein Modul erstellt (und veröffentlicht) habe, dessen tatsächliche Sinnlosigkeit mir im Laufe seiner Benutzung klar wurde - was dazu führte, dass ich das Modul wieder komplett aus dem Funktionsumfang von fhem entfernt habe.
Zitat von: betateilchen am 30 August 2016, 16:16:31
Die bloße Existenz eines Moduls ist noch lange kein Grund, es auch tatsächlich zu benutzen.
wie wahr 8)
Das I2C_DS1307 war auch nur eine Demonstration die Norbert schnell zusammengebaut hat
Zitat von: Burny4600 am 30 August 2016, 16:07:19
Get Befehle sind nicht inkludiert für das I2C_DS1307.
Hmm, hast du einen poll_interval als Attribut gesetzt?
Irgendwie muss die Zeit ja ausgelesen werden.
Und wenn Befehle zum auslesen der Zeit abgesetzt werden, sollte im verbose 5 das RPII2C Modul einiges ausspucken...Ebenso bei set.
poll_interval ist mit 300 und Verbose mit 5 definiert.
Dennoch nicht mehr Einträge im LOG als schon mitgeteilt.
Zitat von: Burny4600 am 30 August 2016, 17:03:30
poll_interval ist mit 300 und Verbose mit 5 definiert.
Dennoch nicht mehr Einträge im LOG als schon mitgeteilt.
Dann scheint das Modul überhaupt keine Daten vom I2C abzufragen. Jetzt weiß ich auch nicht mehr weiter.
Ich habe gerade mal meinen rpi3 mit aufmontiertem DS1307 rausgekramt - das Verhalten ist absolut identisch zum hier beschriebenen Fehlerbild.
Allerdings gibt es "set <name> time" überhaupt nicht, sondern nur datetime und now als set-Parameter. Das zitierte "set <name> time" dürfte die Beschreibung für den set-Befehl selbst sein.
Soweit ich herausgefunden habe gibt es unter Shell nur eine Definition wo man eine Uhrzeit eingeben kann und das ist inklusive Datum.
Das set now hätte wahrscheinlich ein get now werden sollen um die Zeit der RTC abzufragen.
Alles andere sollte automatisch im Hintergrund ablaufen angestossen vom Polling.
Das Modul war wahrscheinlich noch nie fertig getestet worden.
Zitat von: Burny4600 am 30 August 2016, 19:24:57
Das set now hätte wahrscheinlich ein get now werden sollen um die Zeit der RTC abzufragen.
Nein. Das set now hat (im Modul) eigentlich die Aufgabe, die aktuelle Uhrzeit zu ermitteln und diese in die RTC zu schreiben.
$command eq "now" and do {
$ds1307->setTime(time());
...
Eine Frage noch.
Wird sich bei diesem Modul noch etwas ändern oder ist dieses Modul unter FHEM für die Zukunft zu vergessen?
Gibt es wirklich keine Lösung für eine RTC Aktivierung die so zu konfigurieren, dass die RTC unter Shell funktionsfähig aktiviert wird ohne den I2C für FHEM zu blockieren.
Es kann doch nicht sein das die RTC weder unter FHEM funktionsfähig einzubinden möglich ist, noch unter Shell ohne den I2C für FHEM zu blockieren.
Derzeit seiht es so aus, auf die RTC zu verzichten oder diese zu aktivieren aber dafür unter FHEM keine I2C Geräte zu verwenden, da I2C durch die aktive RTC blockiert wird.