Demnächst in diesem Theater:
UniPi (http://unipi.technology/)
Mal schauen, was sich damit anstellen lässt.
Hier werde ich jeweils den aktuellen Status der Implementierung bereitstellen.
UniPi Hardware: working out-of-the-box, when connected to RaspberryPi
apt-get install i2c-tools libi2c-dev
# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- 6f
Connecting UniPi to fhem - working out-of-the box
define i2c RPII2C 1
(http://up.picr.de/20123689pf.png)
Available i2c-devices
(http://up.picr.de/20123521xj.png)
to be checked: are there really two devices on address 0x57?
Hardware Clock: working in operation system, no need to be implemented in fhem.
# echo mcp7941x 0x6f > /sys/bus/i2c/devices/i2c-1/new_device
# hwclock -r
Mo 01 Jan 2001 01:00:02 CET -0.512983 seconds
# hwclock -w
# hwclock -r
Fr 14 Nov 2014 19:33:58 CET -0.512091 seconds
#
Relay via MCP23008 - working
New module 52_I2C_MCP23008 released 2014-11-18.
define relais I2C_MCP23008 32
attr relais IODev i2c
attr relais OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
attr relais comment A0=Relay8 A1=Relay7 A2=Relay6 A3=Relay5 A4=Relay4 A5=Relay3 A6=Relay2 A7=Relay1
(http://up.picr.de/20342550zv.jpg)
1-wire - working with owfs
1. Install debian packages for owfs
dpkg -i owserver_2.8p17-1_armhf.deb libow-2.8-17_2.8p17-1_armhf.deb owfs-common_2.8p17-1_all.deb owhttpd_2.8p17-1_armhf.deb
2. Modify configuration file /etc/owfs.conf
server: device = /dev/i2c-1
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
Celsius
3. define 1-wire Master in fhem
define OWSERVER OWServer localhost:4304
4. check for available devices
get OWSERVER devices
Result: 28.DB9453060000 DS18B20
5. define 1-wire Device in fhem
define sensor OWDevice 28.DB9453060000 60
Result:
(http://up.picr.de/20237554bx.png)
Das Ding gibt es aber schon länger...
Allerdings scheinen alle meine Browser den Seitenquelltext nicht zu verstehen. Ich kann mit keinem Scrollen.
--edit--
Ok, mein Fehler. Hatte das Designelement "Scrollbar" nicht gefunden...
Ich hab ja nicht gesagt, dass das Board neu ist. Aber nun geht es darum, hier in der Community ein möglichst vollständiges fhem Modul dafür zu bauen.
Das stimmt allerdings. Ich bin ehrlich gesagt aber doch ein Stück verwundert, dass sich bislang noch keiner dieses Boards angenommen hat.
Wenn das Ding noch eine Art CSM on-board hätte, wär's nahe an der eierlegenden Wollmilchsau. Ich vermute nämlich, dass bei Hutschieneneinbau nicht genug Platz im E-Kasten ist, um einen Stick an die USB-Ports anzustecken...
Nun ja, vielleicht geht's ja über den eingebauten UART-Port...
Zitat von: tomster am 10 November 2014, 20:34:17
verwundert, dass sich bislang noch keiner dieses Boards angenommen hat.
Vermutlich eine Preisfrage.
Zitat von: tomster am 10 November 2014, 20:34:17
Wenn das Ding noch eine Art CSM on-board hätte,
...
Nun ja, vielleicht geht's ja über den eingebauten UART-Port...
Willst Du testen? => email hier über das Forum (http://forum.fhem.de/index.php?action=emailuser;sa=email;msg=217885) an mich schicken.
Trari trara, die Post ist da...
Das Ding ist ja echt riesengroß...
(http://up.picr.de/20120979po.jpg)
(http://up.picr.de/20120980xq.jpg)
(http://up.picr.de/20120981vc.jpg)
Ganz schöner Koffer...
Ich bin gespannt, müsste die nächsten Tage auch kommen...
im Moment suche ich grade ein Netzteil mit passendem Stecker... Warum konnte man statt der Buchse nicht einfach noch zwei weitere Schraubklemmen auf das Board montieren *grummel*
Zitat von: betateilchen am 14 November 2014, 16:10:55
im Moment suche ich grade ein Netzteil mit passendem Stecker... Warum konnte man statt der Buchse nicht einfach noch zwei weitere Schraubklemmen auf das Board montieren *grummel*
Was schneidest Du auch immer die Stecker ab 8)
Wird das Pi eigentlich mit über das Board versorgt?
Ich hab keinen Stecker abgeschnitten.
Die Spannungsversorgung kann man per Jumper einstellen. Das UniPi kann den Raspi mit versorgen.
Meins ist auch da.
Jetzt weisst ich, was Du meinst. Ich habe nur 12V Netzteile mit Stecker :-\
out-of-the-box:
# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- 6f
alles gefunden, was auf dem Board drauf ist 8)
(http://up.picr.de/20123521xj.png)
@Klaus: Wichtiger Hinweis: mach erst die CR2032 auf das Board, bevor Du Spannung anlegst.
root@raspberrypi:/home/udo# echo mcp7941x 0x6f > /sys/bus/i2c/devices/i2c-1/new_device
root@raspberrypi:/home/udo# hwclock -r
Mo 01 Jan 2001 01:00:02 CET -0.512983 seconds
root@raspberrypi:/home/udo# hwclock -w
root@raspberrypi:/home/udo# hwclock -r
Fr 14 Nov 2014 19:33:58 CET -0.512091 seconds
root@raspberrypi:/home/udo#
Die RTC scheint schonmal zu laufen...
(http://up.picr.de/20123689pf.png)
Sieht auch schon gut aus.
Klaus, ich hab noch ausser dem BMP180 noch nie weiter mit I2C auf dem Raspi beschäftigt. Gibt es schon was, das ich jetzt sinnvoll testen könnte?
Zitat von: betateilchen am 14 November 2014, 19:40:54
Sieht auch schon gut aus.
Klaus, ich hab noch ausser dem BMP180 noch nie weiter mit I2C auf dem Raspi beschäftigt. Gibt es schon was, das ich jetzt sinnvoll testen könnte?
Jo, das läuft würde ich sagen.
Mhh, ich bin unterwegs kann also nicht testen.
Du kannst mit dem RPII2C Modul über set und get testweise mit den I2C IC's kommunizieren.
Schau mal ins Datenblatt von MCP23016 und 23008. Wenn die Register kompatibel sind könntest Du das 52_MCP23016 auch für den 23008 verwenden.
Die RTC würde ich nicht in FHEM sondern auf Systemebene einbinden.
Den 1Wire Treiber kannst Du meines Wissens über owfs einbinden, aber Norbert hat schon mal begonnen, sein 1-wire Modul zu erweitern, das sich auch RPII2C als physical nutzen lässt. Dann währe owfs hinfällig. (Ohne 1-wire Geräte bringt Dir das aber sowieso nix)
Für den EEPROM und A/D Wandler habe ich noch nix. A/D Wandler werde ich als nächstes beginnen. Um den EEPROM sinnvoll einzubinden fehlt mir noch die zündende Idee.
Zitat von: klausw am 14 November 2014, 20:05:01
Du kannst mit dem RPII2C Modul über set und get testweise mit den I2C IC's kommunizieren.
Schau mal ins Datenblatt von MCP23016 und 23008. Wenn die Register kompatibel sind könntest Du das 52_MCP23016 auch für den 23008 verwenden.
Ja, ich befasse mich mal damit. 52_MCP23016 finde ich nicht, nur MCP23017. Damit konnte ich testweise keine Relais schalten.
Zitat von: klausw am 14 November 2014, 20:05:01
Die RTC würde ich nicht in FHEM sondern auf Systemebene einbinden.
Das sehe ich auch so.
Zitat von: klausw am 14 November 2014, 20:05:01
Den 1Wire Treiber kannst Du meines Wissens über owfs einbinden, aber Norbert hat schon mal begonnen, sein 1-wire Modul zu erweitern, das sich auch RPII2C als physical nutzen lässt. Dann währe owfs hinfällig. (Ohne 1-wire Geräte bringt Dir das aber sowieso nix)
Mit 1Wire hab ich noch nie was gemacht. Die Variante über RPII2C wäre natürlich charmant.
Zitat von: klausw am 14 November 2014, 20:05:01
Für den EEPROM und A/D Wandler habe ich noch nix. A/D Wandler werde ich als nächstes beginnen. Um den EEPROM sinnvoll einzubinden fehlt mir noch die zündende Idee.
Da wird sich sicher noch was finden lassen.
Die Register sind komplett anders, da der MCP23008 nur einmal 8 ports besitzt. Sieht so aus, als müsste man aus dem 52_I2C_MCP23017 ein 52_I2C_MCP23008 ableiten.
Zitat von: betateilchen am 14 November 2014, 20:10:51
Ja, ich befasse mich mal damit. 52_MCP23016 finde ich nicht, nur MCP23017. Damit konnte ich testweise keine Relais schalten.
Äh, das meinte ich auch. Ok, dann gibts ein neues Modul dafür. Schaffe ich denke ich dieses Wochenende.
Zitat von: betateilchen am 14 November 2014, 20:24:43
Die Register sind komplett anders, da der MCP23008 nur einmal 8 ports besitzt. Sieht so aus, als müsste man aus dem 52_I2C_MCP23017 ein 52_I2C_MCP23008 ableiten.
Genau
Zitat von: betateilchen am 14 November 2014, 20:10:51
Mit 1Wire hab ich noch nie was gemacht. Die Variante über RPII2C wäre natürlich charmant.
Eben, das spart jede Menge Aufwand bei der Installation. Wenn Du Lust hast, kannst du mal Norbert anhauen, der ist für Unterstützung sicher dankbar.
Ich hab das 52_I2C_MCP23008 fast fertig :) Die %register wurden angepaßt, und schon kann ich die acht Relais schalten:
(http://up.picr.de/20124441of.png)
Was am Modul noch gemacht werden müsste: Es werden readings für portB erzeugt, die natürlich keinen Sinn machen.
Ich schick Dir meine Modulversion per email. Es ist eine Kopie der MCP23017 mit folgenden Änderungen:
- alle Vorkommen von MCP23017 durch MCP23008 ersetzt
- Register angepaßt
define relais I2C_MCP23008 32
attr relais IODev i2c
attr relais OutputPorts A0,A1,A2
Hier die Vorabversion des Moduls, um die Relais anzusteuern
Hui, Jungs. Ihr seid schneller als die Feuerwehr!
Jetzt müsst ich bloß noch eine Hutschiene haben, dann würd ich auf den Zug aufspringen...
Monatagetipps für diverse Boards - Achtung: Beaglebone kann verwendet werden, wird aber offiziell (noch) nicht unterstützt.
(http://up.picr.de/20187723ad.jpg)
Inzwischen sind hier auch ein 1wire-Temperatursensor und eine Montageplatte für den Verteilerschrankeinbau auf Hutschiene angekommen. Mal schauen, wie ich mit dem Sensor weiterkomme. 1wire ist bisher komplett an mir vorbeigegangen - damit hatte ich noch nie was zu tun.
Zitat von: betateilchen am 27 November 2014, 13:51:02
Inzwischen sind hier auch ein 1wire-Temperatursensor und eine Montageplatte für den Verteilerschrankeinbau auf Hutschiene angekommen. Mal schauen, wie ich mit dem Sensor weiterkomme. 1wire ist bisher komplett an mir vorbeigegangen - damit hatte ich noch nie was zu tun.
Da hast du mur was vorraus, ich habe noch keine passenden 1wire Teile 8).
Da hatte sich Norbert schonmal rangesetzt (https://github.com/ntruchsess/fhem-mirror/blob/owx_ds2482/fhem/FHEM/OWX_DS2482.pm) (OWX Modul -> RPII2C Modul). Ist aber noch nicht fertig.
Diese Lösung hätte den Vorteil, das man keine zusätzlichen Module/Server/Programme installieren muss.
Für das Notizbuch...
1. Pakete installieren:
dpkg -i owserver_2.8p17-1_armhf.deb libow-2.8-17_2.8p17-1_armhf.deb owfs-common_2.8p17-1_all.deb owhttpd_2.8p17-1_armhf.deb
2. Datei /etc/owfs.conf bearbeiten:
server: device = /dev/i2c-1
http: port = 2121
ftp: port = 2120
server: port = localhost:4304
Celsius
3. fhem device anlegen:
define OWSERVER OWServer localhost:4304
4. die erste Abfrage
get OWSERVER devices
Ergebnis: 28.DB9453060000 DS18B20
so weit, so gut. Jetzt mal schauen, wie ich da die tatsächliche Temperatur rausbekomme.
och, das war ja völlig unspektakulär...
define sensor OWDevice 28.DB9453060000 60
(http://up.picr.de/20237554bx.png)
Die Lösung über OWX und RPII2C wäre natürlich genial. Aber um da mitzuhelfen, hab ich zu wenig Ahnung von I2C.
Zitat von: betateilchen am 27 November 2014, 15:37:36
Die Lösung über OWX und RPII2C wäre natürlich genial. Aber um da mitzuhelfen, hab ich zu wenig Ahnung von I2C.
Von I2C musst du keine große Ahnung haben, das macht das Modul RPII2C. Es müssen nur noch die Register richtig befüllt werden ::)
Im Moment finde ich die Lösung per owfs sogar sehr praktisch, weil ich damit den 1wire-Sensor auf dem UniPi einfach per Netzwerkverbindung in meinem Produktiv-fhem nutzen kann. Die Lösung per RPII2C würde - nach meinem Verständnis - ja voraussetzen, dass fhem auf dem gleichen Raspi läuft, an dem auch das Unipi angeschlossen ist.
Zitat von: betateilchen am 27 November 2014, 16:05:32
Im Moment finde ich die Lösung per owfs sogar sehr praktisch, weil ich damit den 1wire-Sensor auf dem UniPi einfach per Netzwerkverbindung in meinem Produktiv-fhem nutzen kann. Die Lösung per RPII2C würde - nach meinem Verständnis - ja voraussetzen, dass fhem auf dem gleichen Raspi läuft, an dem auch das Unipi angeschlossen ist.
Gute Frage. Müsste das nicht auch mit FHEM2FHEM funktionieren? Damit habe ich mich noch nicht befasst. Evtl. muss in das RPII2C Modul nochwas eingebaut werden. Aber FHEM muss auf jeden fall laufen, da hast du Recht.
Wenn ich es schaffe, dann checke ich heute Abend das I2C_EEPROM Modul ein. Es funktioniert soweit fehlerfrei.
Hast du dir inzwischen mal den A/D Converter angeschaut?
FHEM2FHEM ist gruslig, das setze ich schon lange nicht mehr ein. Davon abgesehen ist f2f ja - soweit ich mich erinnere - unidirektional, ich kann also keine get und set dorthin schicken.
Die Lösung mit dem owfs finde ich inzwischen ziemlich prima.
Modul 52_I2C_EEPROM.pm ist im SVN.
Super :)
Wegen A/D Wandler: da bin ich noch nicht weitergekommen, und in den nächsten Tagen habe ich da auch wenig Zeit zum Experimentieren.
Zitat von: klausw am 27 November 2014, 23:13:54
Modul 52_I2C_EEPROM.pm ist im SVN.
Spontan sind mir folgende Dinge aufgefallen:
- set und get buttons im Frontend nicht verfügbar
- nach einem set wird die Detailansicht verlassen und zur Raumübersicht gewechselt.
- man kann zwar mit set sowohl Dezimal- als auch Hex-Werte setzen, bei einem Wert kommt aber immer Hex zurück, was bei einem Rückgabewert von "80" nicht eindeutig erkennbar ist. Man sollte Hexwerte mit 0x80 darstellen und bei der Bitabfrage ggf. auch eine Kennzeichnung vorsehen.
Wird es eine Möglichkeit geben, ein get direkt auf dem Device auszuführen und nicht nur aus dem Reading?
Zitat von: betateilchen am 28 November 2014, 10:40:05
set und get buttons im Frontend nicht verfügbar
nach einem set wird die Detailansicht verlassen und zur Raumübersicht gewechselt.
Das ist sicher ein und dasselbe...
set und get gibts nur bei dropdown Menü, richtig?
Ich könnte sowas in der Art machen:
(set|get) (byte|bit|word|dword|qword) [0...7] <adresse> [hex|dec|bin](byte|bit|word|dword|qword) ist dann das Dropdown Menü und bei Bit erscheint ein Zweites.
Die Frage ist ob sich der Aufwand lohnt und das jemand nutzt 8)
Zitat von: betateilchen am 28 November 2014, 10:40:05
man kann zwar mit set sowohl Dezimal- als auch Hex-Werte setzen, bei einem Wert kommt aber immer Hex zurück, was bei einem Rückgabewert von "80" nicht eindeutig erkennbar ist. Man sollte Hexwerte mit 0x80 darstellen und bei der Bitabfrage ggf. auch eine Kennzeichnung vorsehen.
stimmt, 0x baue ich noch ein, werde auch noch die option zum dezimalen abfragen einbauen. Bei Bitabfragen macht es keinen Sinn 1 ist 1 in Binär, Dezimal oder Hex.
Zitat von: betateilchen am 28 November 2014, 10:40:05
Wird es eine Möglichkeit geben, ein get direkt auf dem Device auszuführen und nicht nur aus dem Reading?
Hatte ich drüber nachgedacht. Das Problem bei den 2 level Ansätzen ist der asynchrone Ansatz. Das get wird im Prinzip nur angestoßen und das entsprechende Reading nach Rückmeldung vom physikal. Modul aktualisiert. Wenn man auch die Rückmeldung wartet dann ist in dieser Zeit das System blockiert.
Ist aber auch nicht notwendig, wenn der EEPROM nur aus FHEM angesprochen wird bildet das Reading immer den EEPROM Inhalt dar.
Zitat von: klausw am 28 November 2014, 22:58:49
Das ist sicher ein und dasselbe...
set und get gibts nur bei dropdown Menü, richtig?
hm, ich hab grade verstanden, was Du meinst.
Eigentlich würde mir sowas reichen:
(http://up.picr.de/20255611sq.png)
Hierfür reichen zwei Zeilen:
sub I2C_EEPROM_Set($@) {
my ($hash, @a) = @_;
my $name =$a[0];
my $cmd = $a[1];
my $val = $a[2];
my $msg = undef;
my $setList = " ";
return "Unknown argument, choose one of $setList" if(defined($a[1]) && $a[1] eq '?');
(analog auch in _Get)
naja, schön isses meiner Meinung nach nicht
Aber ich habs erstmal eingebaut, bis mir was besseres einfällt.
Schön isses nicht. Es ist vom dummy-Modul abgeschrieben und sorgt zumindest dafür, dass überhaupt ein Eingabefeld kommt.
Man könnte die setList per Attribut definierbar machen, dann kann man in der Dropdownliste tatsächlich die Adressen auswählen, wenn man das möchte. Fest ins Modul einbauen würde ich das jedenfalls nicht wollen.
(http://up.picr.de/20260983fd.png)
my $setList = AttrVal($name, "setList", " ");
return "Unknown argument, choose one of $setList" if(defined($a[1]) && $a[1] eq '?');
(http://up.picr.de/20261009dw.png)
Das wäre ne Option. Bei dem 2K EEPROM würde die Liste auch bisschen lang werden.
Den beiden ADC konnte ich irgendwie noch nix entlocken. Aber vermutlich bin ich nur zu doof, den MCP3422 richtig anzusprechen.
Die analogen Ausgänge und die digitalen Eingänge stehen auch noch auf der ToDo-Liste. Aber ich denke, das sind "einfache" I/O ports (von denen ich aber auch nicht so viel Ahnung habe)
Die digitalen Eingänge sind einfach auf die GPIOs gelegt. Da kannste das RPI_GPIO Modul nutzen.
Der analoge Ausgang, ist leider nur SW PWM vom GPIO18 oder so. Da habe ich noch nix implementiert. Ein PWM I2C IC währe da die bessere Lösung gewesen...
Ok dann sind wir beide zu doof den MCP3422 anzusprechen 8)
Ich bekomme nur nullen raus. Oder das Datenblatt ist falsch.
Meinst du es macht Sinn ein UniPi Modul zu bauen, das per Autocreate alle notwendigen defines macht? Oder ist das übertrieben?
Zitat von: klausw am 02 Dezember 2014, 17:10:30
Ok dann sind wir beide zu doof den MCP3422 anzusprechen 8)
Ich bekomme nur nullen raus. Oder das Datenblatt ist falsch.
Dann müssen wir vielleicht mal in die offizielle Api von UniPi schauen...
Zitat von: klausw am 02 Dezember 2014, 17:10:30
Meinst du es macht Sinn ein UniPi Modul zu bauen, das per Autocreate alle notwendigen defines macht? Oder ist das übertrieben?
Ich glaube, so ein Modul braucht man nicht wirklich, das wäre ja nur ein Wrapper für bereits bestehende Module. Und nicht jeder User braucht tatsächlich alles, was das UniPi bietet.
Zitat von: betateilchen am 02 Dezember 2014, 19:08:14
Ich glaube, so ein Modul braucht man nicht wirklich, das wäre ja nur ein Wrapper für bereits bestehende Module. Und nicht jeder User braucht tatsächlich alles, was das UniPi bietet.
Von meiner Sicht aus auch nicht. Es sollte sich sowieso jeder etwas mit der Materie befassen, bevor er loslegt.
Den MCP3422 bekomme ich inzwischen ausgelesen. Es ist erforderlich die Daten (3-4 Byte) am Stück auszulesen. Nach jedem Lesevorgang geht es wieder bei Null los. i2cget unterstützt das schonmal nicht. Auch Device::SMBbus scheint es nicht zu können.
Mit dem der ioctl Funktion habe ich es hinbekommen.
Es erforderte weitreichende Änderungen im RPII2C Modul. Allerdings geht es im Moment nur, wenn über ioctl gegangen wird.
Ich muss noch ein bisschen testen, bevor ich es einchecke
Klingt gut :) Viel Erfolg!
Für Februar 2015 ist eine Nachfolgeversion des UniPi geplant, da soll dann vermutlich auch ein I2C Chip für den PWM analog out angedacht sein.
Zitat von: betateilchen am 08 Dezember 2014, 10:57:53
Klingt gut :) Viel Erfolg!
Ebenfalls 8) Habe es gerade eingechecked.
Ich hoffe das ich im RPII2C nix übersehen habe...
Zitat von: betateilchen am 08 Dezember 2014, 10:57:53
Für Februar 2015 ist eine Nachfolgeversion des UniPi geplant, da soll dann vermutlich auch ein I2C Chip für den PWM analog out angedacht sein.
Ich hatte schon meine Verbesserungsvorschläge hingeschickt. Mal sehen, ob eine Antwort kommt ::)
Zitat von: klausw am 09 Dezember 2014, 00:27:22
Ich hatte schon meine Verbesserungsvorschläge hingeschickt. Mal sehen, ob eine Antwort kommt ::)
Ich auch, und mein oben geschriebener Hinweis auf die nächste Generation war aus der Antwort, die ich erhalten habe.
Ich habe heute mein UniPi Board erhalten.
Bei der Installation bin ich gemäß der Anleitung vom Hersteller (http://unipi.technology/wiki/Installing_required_software (http://unipi.technology/wiki/Installing_required_software)) vorgegangen.
Nach der Aktivierung von i2C sieht es bei mir so aus:
i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- 6f
70: -- -- -- -- -- -- -- --
Danach habe ich PIGPIO installiert. Das hat soweit geklappt.
0x57 wird bei mir leider nicht gefunden. Woran könnte das liegen?
Warum gehst Du nicht so vor, wie es hier im Forum beschrieben wird?
0x57 ist nicht dramatisch. 0x51-0x56 werden bei Dir ja auch nicht angezeigt.
Hast Du die hwclock getestet? Wenn die funktioniert, ist alles ok.
Ich bin Anfänger und war froh um eine relativ ausführliche Anleitung.
Diese beiden Codezeilen haben nicht funktioniert. Die Fehlermeldung sagte irgendwas wegen fehlender Berechtigung:
echo rtc-mcp7941x >> /etc/modules
echo mcp7941x 0x6f > /sys/bus/i2c/devices/i2c-1/new_device
Ich habe jeweils "sudo" vorgestellt, das machte aber leider keinen Unterschied.
Soll ich am besten alles nochmal neu aufsetzen?
d.h.
1. Raspbian nochmal neue auf die SD-Karte inkl. raspi-config
2. sudo apt-get update && sudo apt-get upgrade
3. i2c aktivieren
4. HWClock prüfen
5. 1-wire über OWFS installieren
6. Perl für fhem installieren
7. fhem installieren
8. Geräte des UniPi in fhem definieren
Bei der Aktivierung von i2c bin ich lt. der Anleitung von UniPi vorgegangen: http://unipi.technology/wiki/Enable_I2C
Auf die Installation von PIGPIO und Evok kann ich verzichten?
Zitat von: PEPITO82 am 23 Dezember 2014, 07:43:13
Auf die Installation von PIGPIO und Evok kann ich verzichten?
Ja. Für fhem brauchst Du die Komponenten nicht. Warum Du nochmal neu anfangen willst, verstehe ich allerdings noch nicht.
Deine I2C Devices sind doch alle vorhanden - was genau funktioniert denn jetzt bei Dir nicht?
Und hey - in der Anleitung am Anfang dieses Threads steht doch eigentlich alles drin, was man tun muss :)
# echo mcp7941x 0x6f > /sys/bus/i2c/devices/i2c-1/new_device
# hwclock -r
Das hat nun geklappt, nachdem ich mich als root angemeldet habe. "sudo" war scheinbar nicht ausreichend...
Der OWServer läuft und mein 1-wire Temperaturfühler zeigt die Temperatur an.
Was mich noch besonders interessiert ist der analoge Ausgang 0-10V.
Wie kann dieser angesprochen werden?
Zitat von: PEPITO82 am 23 Dezember 2014, 19:19:18
Was mich noch besonders interessiert ist der analoge Ausgang 0-10V.
Wie kann dieser angesprochen werden?
Dafür existiert kein Fhem Modul.
Du müsstest dazu die Bibliothek wie auf der HiPi Seite beschrieben installieren und das Ganze über einen Dummy ansteuern.
Wenn der I2C Chip für den PWM analog out kommt, würde der analoge Ausgang dann out of the Box mit fhem funktionieren?
Zitat von: PEPITO82 am 24 Dezember 2014, 14:45:40
Wenn der I2C Chip für den PWM analog out kommt, würde der analoge Ausgang dann out of the Box mit fhem funktionieren?
Jap, jedenfalls sobald es ein Modul für den entspechenden Chip gibt.
Hallo zusammen,
habe mir gerade das UniPi angeschaut. Wißt ihr, wie man die Verbindung zwischen Raspberry Pi B P5 und dem UniPi Board macht? Ich habe die vorläufige Dokumentation bzw. das Wiki angeschaut, aber bin leider nicht fündig geworden.
Gruß PeMue
Zitat von: PeMue am 29 Dezember 2014, 10:41:15
habe mir gerade das UniPi angeschaut. Wißt ihr, wie man die Verbindung zwischen Raspberry Pi B P5 und dem UniPi Board macht?
Da ist in der Nähe des 1wire Verbinders ein Pfostenstecker. Der müsste es sein.
Auf dem UniPi gibt es einen gleichnamigen Header P5, der genau dafür gedacht ist.
(http://up.picr.de/20531380lt.png)
Hallo,
Bin neu hier im Forum, auch relativ neu im Bereich raspberry und unipi. Möchte mit dem System meine komplette Hausautomation umsetzen. Hab alle Schritte bis define i2c durchgeführt, kann aber relais mcp23008 nicht definieren. Ich glaube es hakt noch irgendwo bei i2c. Dazu meine frage, werden die available i2c Devices normalerweise automatisch angezeigt?
Danke schon mal und viele grüße.
Chris
Hi Chris,
Du musst jedes I2C Device einzeln anlegen. Adressen findest du in der UniPi Beschreibung. Module sind in der Commandref beschrieben.
Zitat von: Chris UniPi am 26 März 2015, 08:29:59
Hab alle Schritte bis define i2c durchgeführt, kann aber relais mcp23008 nicht definieren.
Schau mal in den ersten Beitrag dieses Threads, da ist eigentlich alles beschrieben.
Wie ist der Status des definierte I2C Bus in fhem?
Was liefert i2cdetect - wie im Beitrag zu sehen - ? Werden dort alle Komponenten angezeigt?
Hallo,
i2c detect und Status in Fhem sieht bei mir momentan so aus:
Hi everybody!
First of all, I like the concept of fhem and I'm gonna build my new home electric installation on it.
But I have a little problem with german language as I don't understand it at all :-O
I need to setup my raspberry with 2x unipi boards to get 16 relays and 24 inputs (wall switches), however I haven't found any info about digital inputs. How can I read them? Does it support interrupts like RPI GPIO inputs?
Thank you very much for answer in english language ;-) (or czech as I'm from Czech republic)
Regards!
The UniPi use Raspberrys GPIO Pins directly. So you will have 12 Inputs, no matter how much UniPis you connect.
And every Input will have interrupt functionality.
Hallo,
Hab die Relais jetzt zum laufen bekommen. Schon mal ein Teilerfolg. :D Hab aber jetzt ein neues Problem, habe mir direkt von der UniPi Seite einen Temperatursensor bestellt, ist ein DS18S20. Bin nach der Anleitung vorgegangen, hat so weit auch alles geklappt. Nur liefert er mir total schwankende Werte, von 9 bis 90 Grad ca. Hat jemand eine Ahnung, wo der Fehler liegen könnte? Ein Screenshot ist im Anhang.
Danke schon mal und viele Grüße
Chris
Zitat von: PEPITO82 am 23 Dezember 2014, 19:19:18
# echo mcp7941x 0x6f > /sys/bus/i2c/devices/i2c-1/new_device
# hwclock -r
Das hat nun geklappt, nachdem ich mich als root angemeldet habe. "sudo" war scheinbar nicht ausreichend...
Der OWServer läuft und mein 1-wire Temperaturfühler zeigt die Temperatur an.
Was mich noch besonders interessiert ist der analoge Ausgang 0-10V.
Wie kann dieser angesprochen werden?
How to control UniPi's PWM 0-10V via Fhem
-pre-condition1: WiringPi libraries with gpio binary installed
-pre-condition2: following has to be set before fhem starts (you can use rc.local)
# set the 18 (BCM style numbering) GPIO pin to mode pwm
gpio -g mode 18 pwm
# set PWM mode to mark:space ratio (traditional)
gpio pwm-ms
# set PWM freq to 400Hz
gpio pwmc 48
# set PWM range to 0-1000
gpio pwmr 1000
then you are ready for the Fhem part
-add following lines to the .cfg
define PWM dummy
attr PWM setList state:slider,0,1,10
attr PWM webCmd state
define n_pwm notify PWM { system("gpio -g pwm 18 ".(10-%)*100) }
-control dummy device using slider in the FHEMWEB instance
IMPORTANT NOTE: this part of the definition "...(10-%)*100..." is valid only for boards Unipi 1.0, where the PWM output values via GPIO are not inverted yet - when we need 10V, we need to put value 0 to the pin 18, to have 0V we need to put value 1000. In the v1.1 of the Unipi there is no need to do (10-%) anymore.
Hallo zusammen
Habe eine "Raspberry Pi Relay Board v1.0"
http://www.seeedstudio.com/wiki/Raspberry_Pi_Relay_Board_v1.0#Hardware_Installation
mit "i2cdetect -y 1" sehe ich das Board
pi@pi-garage ~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
mit "define i2c RPII2C 1" habe ich das IO Device angelegt.
mit set i2c writeBlock 0x20 0x6 0xFD
und set i2c writeBlock 0x20 0x6 0xFF kann ich Relais schalten.
Den Block kann ich mit "get i2c readBlock 0x20 0x6" lesen.
Habe mal das Relais auf gut Glück angelegt.
define relais I2C_MCP23008 32
attr relais IODev i2c
attr relais OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
Kann aber über das Device die Relais nicht ansteuern.
Kann mir jemand einen Tipp geben wo ich ansetzen muss.
Danke schon mal für eure Hilfe
Zitat von: mixman am 15 April 2015, 12:45:53
define n_pwm notify PWM { system("gpio -g pwm 18 ".(10-%)*100) }
IMPORTANT NOTE: ... In the v1.1 of the Unipi there is no need to do (10-%) anymore.
Ich habe mir ein Unipi Board 1.1 gekauft und versuche gerade den analogen Ausgang in Betrieb zu nehmen.
Leider kann ich an der Klemme "AO" leider keine Spannung messen, obwohl bei "AOV" 12V anliegen und der Schieber des Dummys auf 10 steht.
Das Notify geht auf die Bretter. Ich habe verschiedene Varianten ausprobiert, aber alle Varianten produzierten Fehler im Log:
2015.06.24 17:40:04 3: n_pwm return value: -1
2015.06.24 17:44:49 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 1123) line 1.
2015.06.24 17:44:49 3: eval: {system("gpio -g pwm 18".(6)*100)}
2015.06.24 17:44:49 3: n_pwm return value: -1
2015.06.24 18:01:20 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:02:17 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:02:21 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:04:51 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:06:33 3: n_pwm return value: Unknown command {, try help.Aktuell sieht das define des Notify so aus:
PWM {system("gpio -g pwm 18 (%*100)")}
Im Log steht immer "n_pwm return value: -1". Was bedeutet das?
Wie muss das Notify aussehen?
Ergänzung: Die in Raspian festgelegte Spannung wird mittlerweile einwandfrei auf dem Unipi Board gesetzt, nachdem ich die rc.local korrigiert habe.
Nun hapert es nur noch am Notify.
Hallo,
Zitat von: mv am 06 Juni 2015, 23:34:38
Hallo zusammen
Habe eine "Raspberry Pi Relay Board v1.0"
http://www.seeedstudio.com/wiki/Raspberry_Pi_Relay_Board_v1.0#Hardware_Installation
mit "i2cdetect -y 1" sehe ich das Board
pi@pi-garage ~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
mit "define i2c RPII2C 1" habe ich das IO Device angelegt.
mit set i2c writeBlock 0x20 0x6 0xFD
und set i2c writeBlock 0x20 0x6 0xFF kann ich Relais schalten.
Den Block kann ich mit "get i2c readBlock 0x20 0x6" lesen.
Habe mal das Relais auf gut Glück angelegt.
define relais I2C_MCP23008 32
attr relais IODev i2c
attr relais OutputPorts A0,A1,A2,A3,A4,A5,A6,A7
Kann aber über das Device die Relais nicht ansteuern.
Kann mir jemand einen Tipp geben wo ich ansetzen muss.
Danke schon mal für eure Hilfe
habe es leider erst jetzt gelesen.
Die Definition ist korrekt.
Hast du die aktuelle FHEM Version drauf?
Was steht im Logfile?
Zitat von: PEPITO82 am 24 Juni 2015, 18:11:19
Ich habe mir ein Unipi Board 1.1 gekauft und versuche gerade den analogen Ausgang in Betrieb zu nehmen.
Leider kann ich an der Klemme "AO" leider keine Spannung messen, obwohl bei "AOV" 12V anliegen und der Schieber des Dummys auf 10 steht.
Das Notify geht auf die Bretter. Ich habe verschiedene Varianten ausprobiert, aber alle Varianten produzierten Fehler im Log:
2015.06.24 17:40:04 3: n_pwm return value: -1
2015.06.24 17:44:49 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 1123) line 1.
2015.06.24 17:44:49 3: eval: {system("gpio -g pwm 18".(6)*100)}
2015.06.24 17:44:49 3: n_pwm return value: -1
2015.06.24 18:01:20 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:02:17 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:02:21 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:04:51 3: n_pwm return value: Unknown command {, try help.
2015.06.24 18:06:33 3: n_pwm return value: Unknown command {, try help.
Aktuell sieht das define des Notify so aus:
PWM {system("gpio -g pwm 18 (%*100)")}
Im Log steht immer "n_pwm return value: -1". Was bedeutet das?
Wie muss das Notify aussehen?
Ergänzung: Die in Raspian festgelegte Spannung wird mittlerweile einwandfrei auf dem Unipi Board gesetzt, nachdem ich die rc.local korrigiert habe.
Nun hapert es nur noch am Notify.
Funktioniert es denn, wenn du
{system("gpio -g pwm 18 1023")} oben in der Eingabezeile von FHEM eingibst?
Ich vermute du musst im notify erstmal den Wert berechnen.
Das % Zeichen wird zwar von Value ersetzt, aber an dieser Stelle wird nichts ausgerechnet.
Ausserdem würde ich %EVENT anstelle von % nehmen. % wir irgendwann nicht mehr funktionieren.
Wenn ich das in die Kommandozeile eingebe, erhalte ich auch ein "-1" zurück.
Der User fhem ist der Gruppe gpio zugeordnet:
gpio:x:1003:pi,fhem
i2c:x:110:pi,fhem
In Raspbian selbst ist mir nun aufgefallen, dass ich dort die Spannung auch nicht setzen kann, obwohl in der rc.local das Coding lt. mixman aufgenommen habe.
Nachdem ich die Zeilen händisch eingebe, kann ich die 10V Spannung am analogen Ausgang des unipi boards messen:
pi@raspberrypi ~ $ gpio -g mode 18 pwm
pi@raspberrypi ~ $ gpio pwm-ms
pi@raspberrypi ~ $ gpio pwmc 48
pi@raspberrypi ~ $ gpio pwmr 1000
pi@raspberrypi ~ $ gpio -g pwm 18 1000
Die rc.local scheint beim Booten nicht ausgeführt zu werden.
Lt. file Kommando ist die datei ausführbar:
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# Steuerung analoger Ausgang Unipi Board
# set the 18 (BCM style numbering) GPIO pin to mode pwm
gpio -g mode 18 pwm
# set PWM mode to mark:space ratio (traditional)
gpio pwm-ms
# set PWM freq to 400Hz
gpio pwmc 48
# set PWM range to 0-1000
gpio pwmr 1000
# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
exit 0
Zitat von: PEPITO82 am 25 Juni 2015, 09:25:50
Wenn ich das in die Kommandozeile eingebe, erhalte ich auch ein "-1" zurück.
{system("...")} gibt meines Wissens immer -1 zurück
Beispiel:
{system("ls -l /opt/fhem")} gibt -1 zurück
{`ls -l /opt/fhem`} gibt den Verzeichnisinhalt zurück
das -1 bedeutet also nicht, das der Befehl fehlerhaft war
Zitat von: PEPITO82 am 25 Juni 2015, 09:25:50
In Raspbian selbst ist mir nun aufgefallen, dass ich dort die Spannung auch nicht setzen kann, obwohl in der rc.local das Coding lt. mixman aufgenommen habe.
Nachdem ich die Zeilen händisch eingebe, kann ich die 10V Spannung am analogen Ausgang des unipi boards messen:
pi@raspberrypi ~ $ gpio -g mode 18 pwm
pi@raspberrypi ~ $ gpio pwm-ms
pi@raspberrypi ~ $ gpio pwmc 48
pi@raspberrypi ~ $ gpio pwmr 1000
pi@raspberrypi ~ $ gpio -g pwm 18 1000
jetzt bist du an einem Punkt, wo du mit
pi@raspberrypi ~ $ gpio -g pwm 18 1000
pi@raspberrypi ~ $ gpio -g pwm 18 0Den Ausgang auf 10V bzw. 0 schalten kannst.
Probiere jetzt mal
{system("gpio -g pwm 18 1000")}
{system("gpio -g pwm 18 0")}
oder
{`gpio -g pwm 18 1000`}
...
in Fhem
Zitat von: PEPITO82 am 25 Juni 2015, 09:25:50
Die rc.local scheint beim Booten nicht ausgeführt zu werden.
Lt. file Kommando ist die datei ausführbar:
versuche es mal mit der kompletten Pfadangabe für gpio
Ich habe wieder alle in Raspbian vorbereitet und konnte dort schalten.
In FHEM erhalte ich aber leider folgende Log-Einträge:
2015.06.25 14:51:58 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 40764) line 1.
2015.06.25 14:51:58 3: eval: {system("gpio -g pwm 18 0")}
2015.06.25 14:53:49 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 40992) line 1.
2015.06.25 14:53:49 3: eval: {`gpio -g pwm 18 0`}
2015.06.25 14:56:52 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 41367) line 1.
2015.06.25 14:56:52 3: eval: {system("gpio -g pwm 18 1000")}
2015.06.25 14:57:58 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 41501) line 1.
2015.06.25 14:57:58 3: eval: {`gpio -g pwm 18 1000`}
2015.06.25 14:58:09 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 41524) line 1.
2015.06.25 14:58:09 3: eval: {`gpio -g pwm 18 1000`}
Bei der Version mit den Anführungszeichen oben erhielt ich jeweils den Return Value -1.
Zitat von: PEPITO82 am 25 Juni 2015, 15:03:23
Ich habe wieder alle in Raspbian vorbereitet und konnte dort schalten.
In FHEM erhalte ich aber leider folgende Log-Einträge:
2015.06.25 14:51:58 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 40764) line 1.
2015.06.25 14:51:58 3: eval: {system("gpio -g pwm 18 0")}
2015.06.25 14:53:49 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 40992) line 1.
2015.06.25 14:53:49 3: eval: {`gpio -g pwm 18 0`}
2015.06.25 14:56:52 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 41367) line 1.
2015.06.25 14:56:52 3: eval: {system("gpio -g pwm 18 1000")}
2015.06.25 14:57:58 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 41501) line 1.
2015.06.25 14:57:58 3: eval: {`gpio -g pwm 18 1000`}
2015.06.25 14:58:09 1: PERL WARNING: Can't exec "gpio": No such file or directory at (eval 41524) line 1.
2015.06.25 14:58:09 3: eval: {`gpio -g pwm 18 1000`}
Bei der Version mit den Anführungszeichen oben erhielt ich jeweils den Return Value -1.
versuche es einmal mit komplettem Pfad
Zitat von: klausw am 25 Juni 2015, 15:07:20
versuche es einmal mit komplettem Pfad
Danke klausw.
Mit dem kompletten Pfad funtkioniert sowohl die rc.local als auch die direkte Eingabe in der FHEM Kommandozeile. :D
Die Einträge in der rc.local sehen nun so aus:
# set the 18 (BCM style numbering) GPIO pin to mode pwm
/usr/local/bin/gpio -g mode 18 pwm
# set PWM mode to mark:space ratio (traditional)
/usr/local/bin/gpio pwm-ms
# set PWM freq to 400Hz
/usr/local/bin/gpio pwmc 48
# set PWM range to 0-1000
/usr/local/bin/gpio pwmr 1000
Das Notify habe ich auch angepasst, aber es funktioniert bisher leider noch nicht:
PWM {system("/usr/local/bin/gpio -g pwm 18 (%EVENT*100)")}
kann mir da jemand weiterhelfen,
Hilfeaufruf: bekomme beim Ansprechen der Relays folgende Fehlermeldung zurück:
from jsonrpclib import Server
s=Server("http://localhost/rpc")
s.relay_set(1,1)
bisher allses bestens, aber dann Fehlermeldung:
TypeError: 'NoneType' object has no attribute '__getitem__'
ceid
Ich hab noch eine Frage hinsichtlich der digitalen Eingänge.
Hab die Einstellungen der UniPi FHEM Distribution übernommen:
define i01 RPI_GPIO 4
attr i01 active_low yes
attr i01 direction input
attr i01 interrupt both
attr i01 pud_resistor up
attr i01 room UniPi
Am digitalen Eingang 1 ist der KWL-Meldekontakt meines Zentralstaubsaugers angeschlossen.
Im Aus-Zustand ist das state-reading "on".
Sobald der Staubsauger angeschaltet wird, wird dieses "off".
Ich hätte das gerne genau andersherum.
Wie lässt sich das bewerkstelligen?
Zitat von: PEPITO82 am 26 Juli 2015, 17:00:14
attr i01 active_low yes
Dieses Attribut invertiert den Eingang.
Also auf no setzen oder löschen.
Zitat von: PEPITO82 am 26 Juli 2015, 17:00:14
attr i01 active_low yes
Dieses Attribut invertiert den Eingang.
Also auf no setzen oder löschen.
Das Löschen hat leider keine Auswirkung.
Beim Versuch zuvor es auf "No" zu ändern, hatte ich folgenden Log-Eintrag: Can't open file: i01, active_low
Die Änderung der Berechtigungen lies zwar die Log-Einträge verschwinden, hat aber leider keine Auswirkungen auf das State.
Scheinbar war es doch ein Berechtigungsthema. Wenn ich jetzt meinen digitalen Eingang 1 auf active_low = yes setze, dann findet die Invertierung statt und das Pinlevel ist statt high jetzt low.
Zitat von: PEPITO82 lCan't open file: i01, active_low
Bedeutet das FHEM keine Schreibrechte auf die Datei hat.ink=topic=28953.msg316959#msg316959 date=1438065318
Scheinbar war es doch ein Berechtigungsthema. Wenn ich jetzt meinen digitalen Eingang 1 auf active_low = yes setze, dann findet die Invertierung statt und das Pinlevel ist statt high jetzt low.
Es ist mit hoher Wahrscheinlichkeit ein Berechtigungsthema.
Can't open file: i01, active_low
Bedeutet das FHEM keine Schreibrechte auf die Datei hat.
Aber es sollte dann bei allen Gpios nicht funktionieren.
Hast du die aktuellste raspbian Version?
Möglichst ohne wiringpi.
Ich habe das neueste Raspbian, jedoch mit WiringPi.
WiringPi habe ich installiert, da es als Voraussetzung im UniPi Wiki für den analogen Ausgang angegeben ist.
Zitat von: PEPITO82 am 28 Juli 2015, 14:24:56
Ich habe das neueste Raspbian, jedoch mit WiringPi.
WiringPi habe ich installiert, da es als Voraussetzung im UniPi Wiki für den analogen Ausgang angegeben ist.
Ahso, aber den User fhem hast du der Gruppe gpio hinzugefügt?
User fhem habe ich der Gruppe gpio hinzugefügt.
Mittlerweile bin ich den Weg gegangen, das von UniPi zur Verfügung gestellte FHEM image zu benutzen.
Es gibt von UniPi sogar einen Wiki-Eintrag zu FHEM: http://unipi.technology/wiki/Fhem_%26_UniPi
Das Einzige was für mich bei unipian_fhem v0.2 nicht funktioniert ist der analoge Ausgang.
Es wird in Kürze aber ein neues Image geben, bei dem das gefixt werden soll.
Außerdem soll es eine Korrektur hinsichtlich der RTC geben.
Es gibt nun ein neues Image: unipian_fhem v0.3 rpi
Hiermit funktioniert nun auch der analoge Ausgang, wie er sollte. :)
Das neue Image hat direkt auch den notify für den analogen Ausgang im Bauch.
Wenn ich den Wert ändere, erhalte ich immer einen Logfile Eintrag:
2015.08.13 07:38:47 3: n_pwm_unipi1.1 return value: -1
Gibt es die Möglichkeit gezielt diese Logeinträge zu unterdrücken?
The analog output works in the unipian_fhem v0.3 RPI image.
But the I2C analog output expansion board is not yet supported in fhem.
Apparently, a driver for the IC that is controlling the expansion board (PCA9685) is required. Does anyone have any idea on how to supply this in fhem?
Seit heute funktioniert leider der analoge Ausgang in FHEM nicht mehr.
Ich habe regelmäßig die FHEM Updates installiert und anschließend FHEM neugestartet.
Heute musste ich allerdings auch das Linux neustarten, da der Luftqualitätssensor nicht mehr funktionieren wollte.
Nach dem Komplettneustart erhalte ich folgenden Logeintrag:
2015.12.14 19:46:55 1: PERL WARNING: Number found where operator expected at (eval 7881) line 1, near "%*100"
2015.12.14 19:46:55 3: eval: my $EVTPART0='5.0';my $TYPE='dummy';my $SELF='n_pwm_unipi1.1';my $EVENT='5.0';my $NAME='PWM_UniPi1.1';{ system("/usr/local/bin/gpioset.sh ".%*100) }
Weiß jemand woran das liegen könnte?
Wenn ich folgendes in die FHEM-Kommandozeile eingebe, wird die Spannung am analogen Ausgang auf 6 V verändert:
{system("/usr/local/bin/gpioset.sh 600")}
Das define zum notify auf den Slider-Dummy sieht so aus:
PWM_UniPi1.1 { system("/usr/local/bin/gpioset.sh ".%*100) }
Viele Grüße
Peter
tja, wieder mal jemand, der die Ankündigungen und Anpassungshinweise zu fhem 5.7 (oben rechts in rot auf jeder Seite zu finden!) nicht gelesen hat...
Danke für den Hinweis... :o
Mit $EVENT statt % funktioniert nun wieder alles.
Ich habe nun einen Luftqualitätsfühler mit analogem Ausgang (0-10V) an den analogen Eingang 1 (AI1+) verbunden.
In FHEM sind die analogen Eingänge als I2C_MCP342x angelegt.
Dort erhalte ich für Kanal 1 einen Wert von z.B. 404718.750 angezeigt.
Wie erhalte ich von diesem Wert eine übliche Spannungsangabe, z.B. 5,43 V ?
In der technischen Dokumentation des Unipi wird ein Korrekturfaktor von ca. 5.56 erwähnt.
Ich habe das gleiche Problem mit den UniPi-Relay's.
Die Relay konnten monatelang problemlos über FHEM gesetzt werden.
Ja, ich habe mittlerweile die Infos zu 5.7 gelesen und bekomme es trotzdem nicht hin..
Grundlage ist das Image von UniPi: unipian_fhem v0.3 rpi
Log seit 5.7:
set relays0 PortA3 % : wrong value: % for "set relays0 PortA3" use one of: off,on
n_Relay5 return value: wrong value: % for "set relays0 PortA3" use one of: off,on
Ich habe dann in der Zeile define n_Relay4 notify Relay4 {fhem("set relays0 PortA4 %")}
das % durch %EVENT bzw. $EVENT ersetzt (Unterschied?).
Dies bringt aber auch wieder einen Fehler:
set relays0 PortA3 %EVENT : wrong value: %EVENT for "set relays0 PortA3" use one of: off,on
Wo liegt den da mein Denkfehler????
Gruß
Bernd
Zitat von: bemilic am 28 Dezember 2015, 21:39:57
Ich habe das gleiche Problem mit den UniPi-Relay's.
Die Relay konnten monatelang problemlos über FHEM gesetzt werden.
Ja, ich habe mittlerweile die Infos zu 5.7 gelesen und bekomme es trotzdem nicht hin..
Grundlage ist das Image von UniPi: unipian_fhem v0.3 rpi
Log seit 5.7:
set relays0 PortA3 % : wrong value: % for "set relays0 PortA3" use one of: off,on
n_Relay5 return value: wrong value: % for "set relays0 PortA3" use one of: off,on
Ich habe dann in der Zeile define n_Relay4 notify Relay4 {fhem("set relays0 PortA4 %")}
das % durch %EVENT bzw. $EVENT ersetzt (Unterschied?).
Dies bringt aber auch wieder einen Fehler:
set relays0 PortA3 %EVENT : wrong value: %EVENT for "set relays0 PortA3" use one of: off,on
Es funktionert nur noch $EVENT, das sollte anstelle des alten % funktionieren.
das bezieht sich natürlich nur auf notify und nicht auf das Eingabefeld
Guten Tag,
kann mir jemand bitte zeigen wie ich den I2C_MCP342x mit dem UNIPI verbinde, bei mir funktioniert das nicht.
Danke
Bobo
Die eckigen Klammern haben im DEF nix zu suchen
Das habe ich übersehen, in der Beschreibung war das so angegeben.
Es funktioniert,
Danke
Bobo
Zitat von: bobo am 05 Januar 2016, 08:01:08
Das habe ich übersehen, in der Beschreibung war das so angegeben.
Es funktioniert,
Danke
Bitte
Eckige Klammern geben optionale Parameter an.
Hallo clausw,
du hast recht, ich habe wohl zu schnell gelesen.
Danke für deine Hilfe
Zitat von: reginald.d am 13 August 2015, 17:31:40
The analog output works in the unipian_fhem v0.3 RPI image.
But the I2C analog output expansion board is not yet supported in fhem.
Apparently, a driver for the IC that is controlling the expansion board (PCA9685) is required. Does anyone have any idea on how to supply this in fhem?
PCA9685 ist now supported in FHEM
Nachdem ich jetzt endlich erfolgreich den OWServer mit FHEM zum laufen gebracht habe, wollte ich euch an meinem Erfolg teilhaben lassen ;)
In dem configuration file /etc/owfs.conf sollte folgende Anpassung gemacht werden:
! server: server = 4304
server: port = 4304
siehe: http://forum.fhem.de/index.php/topic,24413.msg178565.html#msg178565
@betateilchen: Vielleicht könntest du ja den ersten Beitrag anpassen.
Bei mir hängen an den analogen Eingängen zwei Luftgütesensoren.
Leider kommt es immer wieder dazu, dass im Log keine Werte geschrieben werden - eigentlich sollte jede Minute ein Wert abgelegt werden:
2016-03-08_22:42:36 rg_dummy_airquality_state ai.Channel1: 450
2016-03-08_22:42:37 rg_dummy_airquality_state ai.Channel2: 475
2016-03-08_22:43:37 rg_dummy_airquality_state ai.Channel1: 459
2016-03-08_22:43:37 rg_dummy_airquality_state ai.Channel2: 485
2016-03-09_06:33:14 rg_dummy_airquality_state ai.Channel1: 567
2016-03-09_06:33:14 rg_dummy_airquality_state ai.Channel2: 469
2016-03-09_06:34:15 rg_dummy_airquality_state ai.Channel1: 564
2016-03-09_06:34:15 rg_dummy_airquality_state ai.Channel2: 467
Gegen 6:33h habe ich mit heute in FHEMWEB angemeldet. Erst nach Zugriff auf die Weboberfläche scheinen die Werte wieder gelesen bzw. geloggt zu werden.
Das passiert mittlerweile leider regelmäßig.
Meine Konfiguration sieht so aus:
# --- UniPi analog inputs
define ai I2C_MCP342x 104
attr ai IODev rpi2c
attr ai ch1factor 0.0011129362
attr ai ch1resolution 18
attr ai ch1roundDecimal 0
attr ai ch2factor 0.001112798
attr ai ch2resolution 18
attr ai ch2roundDecimal 0
attr ai poll_interval 1
attr ai room Luftqualität,UniPi
Woran könnte das liegen, dass die Werte nicht zuverlässig durchgehend gelesen werden?
gibt es Fehlermeldungen im Log?
Wenn nicht, das Loglevel mal höhersetzen.
Bisher keine Fehlermeldungen im Log.
Habe verbose für die analogen Eingänge nun auf 5 gesetzt.
Vermutlich werden die Messwerte heute Nacht wieder einschlafen.
Es hat länger gedauert, bis ich wieder einen langen Ausfall Messwerte zu beklagen habe:
2016-03-17_21:03:18 rg_dummy_airquality_state ai.Channel1: 848
2016-03-17_21:03:18 rg_dummy_airquality_state ai.Channel2: 771
2016-03-17_21:04:19 rg_dummy_airquality_state ai.Channel1: 846
2016-03-17_21:04:19 rg_dummy_airquality_state ai.Channel2: 779
2016-03-18_06:25:55 rg_dummy_airquality_state ai.Channel1: 636
2016-03-18_06:25:55 rg_dummy_airquality_state ai.Channel2: 598
2016-03-18_07:19:54 rg_dummy_airquality_state ai.Channel1: 608
2016-03-18_07:19:54 rg_dummy_airquality_state ai.Channel2: 731
2016-03-18_07:21:57 rg_dummy_airquality_state ai.Channel1: 616
2016-03-18_07:21:57 rg_dummy_airquality_state ai.Channel2: 745
Heute Früh 6:25h hab ich in Fhemweb reingeschaut --> keine Werte für den heutigen Tag.
Da hat es dann je Kanal einen Wert geloggt. Und jetzt das nächste Mal habe ich mich um 7:19h nachgeschaut.
Nun hat es zwei Datenpaare geloggt - aber seit ca. 8 Minuten auch schon wieder keine Wert.
Im Log steht dazu gar nichts, obwohl ich verbose auf 5 gesetzt habe.
komisch, das es bei dir überhaupt lief
das Modul hat die init Routine eigentlich abgebrochen, sobald man eim define Argumente angegeben hat.
Das ist jetzt gefixt.
Evtl. löst das auch dein Problem.
Danke für den Hinweis. Ich habe gleich geupdated und werde es weiterhin beobachten.
Hallo,
Habe seit kurzem auch eine UniPi samt einem 1wire Erweiterungsmodul mit dem DS2408 Chip drauf
Da ich in fhem auch neu bin, habe ich mir die fhem Installation vom Unipi Server geladen und installiert.
Nun mache ich mich dran alles zu verstehen.
Fhem erkennt auch die Zusatzmodule. Habe auch einen Temperatursensor DS18B20 am 1wire Bus hängen.
Dazu habe ich folgende Fragen, wo bzw wie ich das definiere von Geräten, Relais usw lernen kann.
Wollte mit dem definieren der 4 relais am Zusatzmodul beginnen.
Fehm hat das Modul als DS2408_98CF1A000000 erkannt.
es werden
Zitatsensed.0: 1 sensed.1: 1 sensed.2: 1 sensed.3: 1 sensed.4: 1 sensed.5: 1 sensed.6: 1 sensed.7: 1 alarm: 0
erkannt.
Das Modul hat jedoch 4 Relais und 4 Eingänge.
Wie kann ich beginnen?
Ersuche um Unterstützung und Hilfe.
so richtig werde ich nicht schlau, aber wenn es ein 1wire Modul mit 4 ein/ausgängen ist dann solltest du im 1wire Forum suchen/fragen
Zitat von: klausw am 06 Juli 2016, 21:35:56
so richtig werde ich nicht schlau, aber wenn es ein 1wire Modul mit 4 ein/ausgängen ist dann solltest du im 1wire Forum suchen/fragen
Da habe ich bereits gesucht. Wenn das Symcon Forum als 1wire Forum zu bezeichnen ist.
Da gelten andere Voraussetzungen.
Ich will den Chip ,der über den OWS Server erkannt wird, in Fhem ansteuern.
Der DS2408 wird in FHEM ja unterstützt, also musst es auch etwas geben wie ich ihn ansprechen kann.
Nur finde nichts dazu.
Zitat von: maci am 07 Juli 2016, 06:37:51
Ich will den Chip ,der über den OWS Server erkannt wird, in Fhem ansteuern.
Der DS2408 wird in FHEM ja unterstützt, also musst es auch etwas geben wie ich ihn ansprechen kann.
Nur finde nichts dazu.
Ich meinte das Unterforum 1-wire klick (https://forum.fhem.de/index.php/board,26.0.html)
Das unipi ist ja nur eine Kombination aus verschiedenen Komponenten die jede für sich in FHEM unterstützt wird.
Hast du schon in der commandref (http://fhem.de/commandref.html) nachgeschaut?
Zitat von: klausw am 07 Juli 2016, 09:45:07
Ich meinte das Unterforum 1-wire klick (https://forum.fhem.de/index.php/board,26.0.html)
Das unipi ist ja nur eine Kombination aus verschiedenen Komponenten die jede für sich in FHEM unterstützt wird.
Hast du schon in der commandref (http://fhem.de/commandref.html) nachgeschaut?
Danke für den Tipp.
Das hat mir geholfen.
Habe es nun geschafft dass ich diese 4 Relais steuern kann.
Es sind zwar meine ersten Gehversuche in FHEM. Aber haben trotzdem schon einen gewisse Herausforderung. Denn im Gegensatz zu den wirklich einfachen Bespielen der Einführungen, ist hier schon etwas gefragt.
Geholfen hat mir auch das ansehen der bereits fertigen Schalter von Unipi.
Diese setzen zwar auf cfg Files, aber trotzdem leicht zu verstehen.
Nun versuche ich den nächsten Schritt: Die 4 Eingänge abzufragen.
Komme noch nicht so wirklich klar damit.
habe zwar versucht mit get die sensed.x abzufragen bekomme aber überall eine 1.
egal ob etwas an opto-isolierten Eingängen hängt oder nicht.
auch bei den latch.x ist es das gleiche.
Versuche es mal weiter und berichte wieder
Hallo zusammen,
gerne würde ich meine Combo RPI3 plus Unipi Board um ein weiteres Unipi Board erweitern, um zusätzliche analoge Eingänge plus einen zusätzlichen 1-Wire Master zu erhalten.
Das zusätzliche Board habe ich einfach mit dem i2c-Port verbunden.
Danach haben die bisherigen analogen Eingänge keine Werte mehr angezeigt.
Welche Schritte muss ich durchführen, um das zweite Board generell in FHEM zum Laufen zu bekommen?
Muss ein zweiter i2c Bus definiert werden?
Viele Grüße
PEPITO82
Hallo zusammen,
ich in neu bei der UniPi Geschichte - habe mich aber bisher relativ gut eingelesen und einige Sachen ausprobiert.
Habe viel hier im Forum gefunden - vielen Dank!
Ich habe Fhem mit dem UniPi soweit am Laufen, die Relais können geschalten werden.
Ich suche nun nach einer Tabelle, wo ich die Inputs des UniPi Boards finde mit den dazu gehörigen GPIO Ports und wie ich sie definiere.
In einem Beitrag weiter vorne habe ich gelesen, wie i01 definiert wird.
Leider läuft bei mir die unipian fhem version nicht, kann davon nicht booten, sonst hätte ich mir die daten da auslesen können.
Hat jemand einen Link oder einen Hinweis, wo ich weitere Infos finde?
Vielen Dank an die Community,
Sebastian
Du betreibst das Unipi Board auf einem Rpi3?
Das unipian Image ist schon so alt, dass zunächst eine Aktualisierung durchgeführt werden muss.
Einfach zuerst auf nem Rpi1 oder 2 booten und aktualisieren.
Danach läuft es auch auf dem Rpi3.
Hatte vor langem schon mal ne Aktualisierung des unipian Images angefragt, aber das wird wohl eher nicht mehr kommen...
Ich habe auch das Image von der UniPi Seite geladen.
Jetzt wollte ich das Image mal updaten, damit es in meinem neuen Neuron L203 (Raspberry 3)auch startet.
Habe einen Raspberry Version 2 zum starten genommen.
FHEM ist kein Problem über die Update Funktion
Aber das Image an sich... der Standard Zugang pi und Passwort raspberry gehen nicht.
Hat jemand einen Tipp?
Schöne Grüße aus dem Münsterland
Ralf
Groß/Kleinschreibung bei USer/Passwort beachtet?
Kommst Du mit irgendeinem User auf den Pi?
Für den "Notfall"; Hast Du einen Linux-Rechner zur Verfügung?
Zitat von: rabbitlman am 16 April 2017, 17:59:22
Ich habe auch das Image von der UniPi Seite geladen.
Jetzt wollte ich das Image mal updaten, damit es in meinem neuen Neuron L203 (Raspberry 3)auch startet.
Habe einen Raspberry Version 2 zum starten genommen.
FHEM ist kein Problem über die Update Funktion
Aber das Image an sich... der Standard Zugang pi und Passwort raspberry gehen nicht.
Hat jemand einen Tipp?
Schöne Grüße aus dem Münsterland
Ralf
Das Unipi Fhem image hat keinen User pi.
Login als "root" mit Passwort "unipi"
Das steht irgendwo in der Beschreibung.
Seit den neue Neuron Produkten sind viele ältere Dinge von der Homepage einfach verschwunden.
Mein Eindruck ist weiters, dass Unipi Fhem nicht mehr wirklich unterstützen will. Dadurch fehlt auch schon etwas.
Vorsicht, beim Update: Zuerst das System Updaten, dann fhem.
Die Relais funktionieren nach dem Update von fhem nicht mehr, weil in der Definition dafür, die sich nicht in der fhem.cfg befindet, noch die alte Art drinnen ist. Die Definition beinhaltetet noch nicht die Art mit "$EVENT".
Das fhem Image dort ist noch auf die Unipi 1.1 ausgelegt und nicht auf die Neuron Produkte.
Ich habe die Unipi 1.1, habe mir aber alles selbst erstellt. Habe das Image zum Nachsehen genommen, wie alles definiert wurde.
Danke, maci
für die Zugangsdaten.
Es ist schon arm von UniPi, wenn man Hardware für ca. 500€ kauft und sich dann seine zum Betrieb notwendige Software selbst "zusammenbauen" muss.
Fakt ist zur Zeit, dass das Image unipian_fhem-v0.3-rpi.zip auf der aktuellen Hardware NICHT mehr läuft :-[.
Du hast auch recht mit der Aussage, dass auf der Homepage die Unterstützung für FHEM nicht mehr zu finden ist. Alle Links laufen ins leere.
Ich muss mir im Moment erst mal schwer überlegen, ob ich diese "Firmenpolitik" unterstütze, oder Amazon sei Dank, die Hardware wieder zurücksende.
...oder hat jemand ein laufendes Jessy mit FHEM Image zur Verfügung?
Schöne Grüße aus dem Münsterland
Ralf
Hallo Ralf,
hast du die 1 Wire Thermometer über http angesteuert, wenn ja wie? Ich bekomme da einfach den value nicht angezeigt.
cu spaci76
Hallo zusammen,
ich habe hier ein UniPi V1.1, welches ich mit meinem Pi3 (aktuelles Jessie) verbunden ist.
Nach der Anleitung von Seite 1 habe ich die Definitionen vorgenommen, über das definierte "Relais" Dummy kann ich auch die 8 Relais schalten.
Einzig der One-Wire Bus macht nicht wirklich etwas.
Ich kann über das Read des OWSERVER nichts finden.
Über i2cscan von der Linux Konsole kann ich aber meine Sensoren samt Adressen finden.
Hat hierzu jemand einen Rat für mich?
Oder wäre freundlicherweise jemand bereit einem absoluten Neuling diesbezüglich per Team Viewer o.ä. unter die Arme zu greifen?
Besten Dank & Gruß,
Markus
Hallo Zusammen,
ich kämpfe zur Zeit mit dem Unipi board.
i2c Bibliothek ist geladen, jedoch kommt nach dem #i2cdetect -y 1 keine Antwort, auch keine Fehlermeldung.
update und Neustart schon gemacht.
woran kann das liegen?
Danke für Hilfe
Dirk
Zitat von: origami am 16 März 2019, 16:42:50
Hallo Zusammen,
ich kämpfe zur Zeit mit dem Unipi board.
i2c Bibliothek ist geladen, jedoch kommt nach dem #i2cdetect -y 1 keine Antwort, auch keine Fehlermeldung.
update und Neustart schon gemacht.
woran kann das liegen?
Danke für Hilfe
Dirk
na, hast das Problem schon gefunden?
Ich kann mir gut vorstellen das du die I2C Packete nicht installiert hast.
Gruß
Guten Morgen,
habe mich nach langem Zögern für das Unipi 1.1 Board entschieden und gestern meine ersten Versuche damit unternommen. Leider gibt es dazu, bis auf diesen Thread, nicht besonders viele Infos. Nun ja, konnte alles soweit einbinden und die Relais kann ich auch schalten. Mir ist aber leider überhaupt nicht klar, wie ich die digitalen Eingänge lesen kann... Aus der Commandref wurde ich diesbezüglich auch nicht schlauer. Könnt ihr mir einen Tipp geben?
Danke und Gruß
Achim
Hallo Achim,
die Eingänge gehen auf die GPIOs des Pi.
Dafür kannst du das Modul RPI_GPIO nutzen.
Die GPIO Nummern solltest du in der UniPi Doku finden
Klaus
Danke, das hat geholfen. Dachte zunächst das wäre auf über I2C ansprechbar.
Zitat von: devien am 22 August 2019, 16:28:52
na, hast das Problem schon gefunden?
Ich kann mir gut vorstellen das du die I2C Packete nicht installiert hast.
Gruß
hab anscheinend auch das Problem.
wollte wie auf Seite 1 vorgehen, nach apt-get install i2c-tools libi2c-dev und jetzt i2cdetect -y 1 folgende Meldung :
Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory
jemand eine Idee, suche schon seit Stunden :-[
10 min nach dem geschriebenen hab ich es dann doch noch gefunden. Musste erst in sudo raspi-config --> interface option --> i2c einschalten
Hallo,
ich wärme diesen Thread auf daer am passendsten ist und ich vermeiden möchte das zu viele über das gleiche Thema entstehen.
Vorabinfo: Ich habe seid 10 Jahren einen Unipi1.1 für meine Hausautomatisierung im Betrieb, vor ein par Jahren habe ich den RaspberryPi2 gegen RaspberryPi3 ersetzt. Die SD Karte habe ich vor ein par Tagen erneuern müssen da die alte offenbar wieder das Zeitliche gesegnet hatte. Habe dabei gleich die neueste Raspbian Version installiert
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
I2C läuft (I2C_MCP23008 schaltet meine Relays)
1Wire läuft (ich kann die Daten der DS18b20 Sensoren abfragen)
Fhem ist als User in den entsprechenden Gruppen hinterlegt
dialout:x:20:pi,fhem
sudo:x:27:pi,fhem
users:x:100:pi,fhem
input:x:102:pi,fhem
spi:x:995:pi,fhem
i2c:x:994:pi,fhem
gpio:x:993:pi,fhem
Nun zu meinem Problem: Ich habe einen Counter der eigentlich bei einer Umdrehung meines Volumenstromzählers der Solaranlage um 1 hochzählen sollte was dann wiederum andere Sachen macht..siehe def:
defmod i03 RPI_GPIO 27
attr i03 DbLogExclude Counter,Dblclick,Pinlevel,Toggle,d_volumen,solargesamtertrag,solarjahresertrag,solarmonatsertrag,state,volumenstrom
attr i03 active_low no
attr i03 alias Solarzähler
attr i03 ctsperm3 1000
attr i03 dichte 1042
attr i03 direction input
attr i03 event-on-change-reading 1
attr i03 event-on-update-reading Counter,volumenstrom,d_volumen,solarleistung,solartagesertrag,solargesamtertrag, state
attr i03 fp_Solar 59,203,0,i01
attr i03 icon sani_solar
attr i03 interrupt falling
attr i03 offset 860
attr i03 poll_interval 5
attr i03 restoreOnStartup yes
attr i03 room Solarsteuerung,UniPi
attr i03 stateFormat {sprintf("V: %.2fm3",solarzaehlerstand("i03","Counter",0)).sprintf(" E: %.2fkWh",ReadingsVal("i03","solartagesertrag",0)).sprintf(" P: %.2f kW",ReadingsVal("i03","solarleistung",0));;}
attr i03 userReadings volumenstrom:Counter.* differential {solarzaehlerstand('i03', 'Counter');;}, d_volumen:Counter.* difference {solarzaehlerstand('i03', 'Counter');;}, solarleistung:volumenstrom.* { get_solarleistung('i03', 'DS18B20_Vorlauf_S', 'DS18B20_Ruecklauf_S');;}, solargesamtertrag {get_solarertrag('i03','DS18B20_Vorlauf_S', 'DS18B20_Ruecklauf_S');; }, solartagesertrag { get_d_solarertrag('i03', 'D_SOLARCNTATMIDNIGHT');;}, solarmonatsertrag { get_d_solarertrag('i03', 'D_SOLARCNTAT1STDAYOFMONTH');;}, solarjahresertrag { get_d_solarertrag('i03','D_SOLARCNTAT1STDAYOFYEAR');;}
attr i03 verbose 5
attr i03 waermekapazitaet 3.8
Leider zählt der RPI_GPIO nicht hoch, ich habe diesmal kein wiringpi installiert und das pudresistor Atribut entsprechend entfernt.
Also hab ich weiter geschaut ob sich der Status des GPIO am Raspbian selbst überhapt ändert.
/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio27/value ändert sich nicht, seit dem letzten Neustart des Systems.
also kommen die Zählimpulse die am unipi (per LED des Unipi I03 = GPIO27) ankommen nicht bis in die Datei "/sys/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio27/value".
Aber warum? Vor dem Kartencrash hat es noch sauber funktioniert, nun muss also etwas anders sein, aber was habe ich übersehen, bzw was hat sich evtl seit buster geändert?
Im Normalfall schaue ich in die Systemlogs, aber offensichtlich werden diese mit journalctl nicht mehr so schön erstellt und ich hab noch nicht gepeilt wie man die bei journalctl ausliest. Allerdings glaube ich fast das sich dort hierzu nichts finden wird.
Kann mir jemand weiterhelfen?
niemand einen Schimmer an welcher ecke es liegt?
Bei bookworm scheint sich einiges an Treibern geändert zu haben.
Bei mir klappt z.B. ein Display nicht mehr.
Versuch es spaßeshalber mal mit der Vorgängerversion.
Zitat von: devien am 18 Dezember 2023, 13:59:40niemand einen Schimmer an welcher ecke es liegt?
Ich habe gerade mal ein Testsystem mit Bookworm aufgesetzt.
Das Anlegen eines GPIO als Input und mit Interrupt war erstmal unauffällig.
Der GPIO wird im Dateisystem angelegt und auch die entsprechenden Dateien haben den korrekten Inhalt:
pi@pi4:~ $ sudo ls -lh /sys/class/gpio/
insgesamt 0
--w--w---- 1 root gpio 4,0K 15. Jan 23:18 export
lrwxrwxrwx 1 root root 0 15. Jan 23:18 gpio25 -> ../../devices/platform/soc/fe200000.gpio/gpiochip0/gpio/gpio25
lrwxrwxrwx 1 root gpio 0 15. Jan 00:31 gpiochip0 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 15. Jan 00:31 gpiochip504 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip504
--w--w---- 1 root gpio 4,0K 15. Jan 00:31 unexport
pi@pi4:~ $ sudo ls -lh /sys/class/gpio/gpio25/
insgesamt 0
-rw-rw---- 1 root gpio 4,0K 15. Jan 23:18 active_low
lrwxrwxrwx 1 root gpio 0 15. Jan 23:18 device -> ../../../gpiochip0
-rw-rw---- 1 root gpio 4,0K 15. Jan 23:20 direction
-rw-rw---- 1 root gpio 4,0K 15. Jan 23:21 edge
drwxrwxr-x 2 root gpio 0 15. Jan 23:18 power
lrwxrwxrwx 1 root gpio 0 15. Jan 23:18 subsystem -> ../../../../../../../class/gpio
-rw-rw-r-- 1 root gpio 4,0K 15. Jan 23:18 uevent
-rw-rw---- 1 root gpio 4,0K 15. Jan 23:18 value
pi@pi4:~ $ sudo cat /sys/class/gpio/gpio25/value
0
pi@pi4:~ $ sudo cat /sys/class/gpio/gpio25/direction
in
pi@pi4:~ $ sudo cat /sys/class/gpio/gpio25/edge
rising
Wobei das Modul nach wie vor über das Verzeichnis /sys/class/gpio geht
Elektrisch testen versuch ich morgen mal. Ich erwarte aber das es funktionieren wird.
Das Attribut restoreOnStartup ist nutzlos, da es nur für Outputs die Zustände wiedergerstellt.
Das Attribut poll_interval macht bei gleichzeitiger Nutzung von interrupt auch nicht wirklich Sinn.
Wenn du den Pinlevel live sehen willst dann setze Interrupt auf both
Was liefert den
sudo cat /sys/class/gpio/gpio25/value wenn du Spannung an diesem Input anlegst? Dann müsste sich der Wert von 0 auf 1 ändern.
Im Define wirst du allerdings keine Änderung des Pinlevel sehen. Das Atribut "interrupt falling" sorgt nur für ein neues Event bei jedem Pegelwechsel in der Value Datei auf 0. Wenn das UniPi eine invertierte Logik hat, dann entspricht Low Pegel am UniPi Pin einem High Pegel am Raspberry Pin.
Auf einem Raspberry Pi 4 mit frisch installiertem Raspberry OS Bookworm funktioniert das Modul wie erwartet.
Die Zuordnung passt.