AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

papa

Zitat von: neumann am 13 Oktober 2018, 22:06:06
Hey!
Ich habe es nun geschafft, einen 32 Bit Wert zu senden und zu empfangen, mit dem unten angeführten Sketch.
Der Befehl, um an das Gateway zu senden ist ein Action Command: ++A011F0F0F0FA327180021234567803
Wie schaffe ich nun, das aus FHEM heraus zu senden mit Fehlererkennung (Ack) (zum testen ging es über set raw bei der VCCU, allerdings ohne Erkennung des zurückkommenden Acks)?
Am besten so einfach wie möglich.
Wie schon geschrieben, fällt mir da nur der Umweg über "set pct ..." ein.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Zitat von: papa am 16 Oktober 2018, 12:57:26
Und gibt es schon Bilder ?

Von der Platine oder der defekten Ätzmaschine :-( Ich hab Lochraster genommen, bis der neue Luftschlauch kommt dauert es mir zu lange ;-)
Es läuft aber tadellos! Danke nochmal.

/Daniel


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

sentinel1

Zitat von: papa am 11 Oktober 2018, 22:46:12
Ich habe ein neues Geräte im GitHub eingecheckt. HB-IBUT-8 - ein 8 Kanal iButton Gerät. Damit es erfolgreich in FHEM angelernt werden kann, muss die HMConfig_AskSinPPCustom.pm aktualisiert werden.
Nach dem Anlernen sind 8 Kanäle Id_01 - Id_08 verfügbar.  Jedem Kanal kann ein iButton zugeordnet werden. Dazu ist der entsprechende Kanal mit
set DEVICE_Id_Kanalnummer on
in den Anlernmodus zu versetzen. Dieser ist für 1 Minute aktiv. Der aktive Anlernmodus wird durch abwechselndes Blinken der beiden Leds angezeigt. Wird jetzt ein iButton an den Leser gehalten, wird die entsprechende Id im Kanal gespeichert. Das Speichern wird mit der grünen Led bestätigt. Von nun an wird ein Remote-Event ausgelöst, wenn der entsprechende iButton gelesen wird.


Hallo,

ich habe mir einen HB-IBUT-8 gebaut auf Basis von Papas HM Universalsensor von hier https://forum.fhem.de/index.php/topic,73954.0.html.Ich bekomme aber keinen IButton angelernt und weiß eigentlich nicht wo ich ansetzen soll.

Muss ich am Sketch etwas ändern?Ich habe da nichts geändert,der I-Reader ist an Gnd und B1 angeschlossen.
Ansonsten scheint alles zu funktionieren auch das anlernen und anlegen in FHEM hat problemlos funktioniert.

Ich versorge die Platine von einen Breadboard mit 3,3V.Ist das vielleicht zu wenig für den I-Button Reader?

Vielleicht hat jemand eine Idee und kann mir helfen.

Gruß,
Claudiu

ext23

3,3V reicht vollkommen aus. Hast du ein PullUp von 4,7k auf dem Datenport? Die IButtons arbeiten nur Parasitär.

Was meinst du eigentlich mit "I-Button Reader", diese Kontaktfläche oder wie?

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

sentinel1

Zitat von: ext23 am 19 Oktober 2018, 20:09:05
3,3V reicht vollkommen aus. Hast du ein PullUp von 4,7k auf dem Datenport? Die IButtons arbeiten nur Parasitär.

Was meinst du eigentlich mit "I-Button Reader", diese Kontaktfläche oder wie?

/Daniel

4,7K Pullup habe ich nicht,werde ich gleich probieren.

ja,mit iButon Reader meine ich die Kontaktfläche wo mann den iButton dranhält.

ext23

Zitat von: sentinel1 am 19 Oktober 2018, 20:43:48
4,7K Pullup habe ich nicht,werde ich gleich probieren.

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

sentinel1


Klaus0815

Hallo Tom,

Zitatjp112sdl hat einen Sensor mit Taster in seinen Beispielen, aber wahrsch. ohne FHEM Unterstützung, bin nicht sicher.

welchen meinst Du da genau? sind so viele auf der Seite :-)
Denke auch dass das in FHEM nicht funktioniert, schade das da die Homematic-Jungs so viel weiter sind

Zitat
Zufällig habe ich gerade den Bedarf, Daten eines extra Schalters/Inputs am Unisensor zu benötigen, der dann auch bei Änderung sofort senden soll, ich versuche das die nächsten Tage im HB-UNI-Sensor1 als Option nachzuziehen.

Bin gespannt, würde mich sehr freuen wenn das klappt

Viele Grüße

Klaus

Tom Major

Zitat von: Klaus0815 am 22 Oktober 2018, 20:38:04
Bin gespannt, würde mich sehr freuen wenn das klappt
Viele Grüße
Klaus
Hallo Klaus,
ja der digitale Eingang mit Sendeinterrupt läuft mittlerweile in meinem Unisensor, mache gerade noch etwas Feintuning an den HomeMatic AddOn Scripten dafür, zum Glück habe ich da mit jp112sdl einen sehr kompetenten Ansprechpartner  :)
Bei FHEM ist die Integration leicht da nur 1 Byte in der payload message dazugekommen ist..
Stelle ich die nächsten Tage online.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: Klaus0815 am 22 Oktober 2018, 20:38:04
Bin gespannt, würde mich sehr freuen wenn das klappt
Viele Grüße
Klaus

Ein digitaler Eingang ist jetzt als zusätzlicher "Sensor" im HB-UNI-Sensor1 aktivierbar.
Aktuell wird der interne pull-up an diesem pin aktiviert, es reicht also ein Schalter gegen Masse. Bei jeder Statusänderung am Eingang wird ein Telegramm übertragen (unabhängig vom eingestellten Sendeintervall).

Die Scripte für HM CCU und FHEM sind auch angepasst, bei HM getestet, bei FHEM nicht (da HM bei mir zur Zeit nur auf RaspberryMatic läuft).
Falls etwas bei FHEM nicht passt melde dich einfach.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Klaus0815

Hallo Tom,

habs gleich mal getestet, funktioniert :-)

Im FHEM Script ist noch ein kleiner Fehler:
Die jetzt neue Zeile "Digital Input" wird nicht aktualisiert
(Bei state, wo alle Werte angezeigt werden, sieht man aber die Änderung)

Viele Grüße

Klaus



der-pw

Hallo,

ich muss mal ganz blöd fragen. Mit meinen rudimentären Arduinokenntnissen wollte ich dem HM-LC-SW1-BA-PCB-Beispiel einen fade-in (und später auch fade-out) Effekt beibringen.
Ich habe vor, einen kleinen LED-Strip damit zu schalten, jedoch soll der etwas schicker an und aus gehen.

Im Modul Switch.h habe ich folgende Änderung vorgenommen.
  virtual void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate,__attribute__((unused)) uint32_t delay) {
    if( newstate == AS_CM_JT_ON ) {
      i = 0;
      while (i < 255) {
        analogWrite(pin, i);
        i++;
        delayMicroseconds(10000);
      }
      digitalWrite(pin,lowact ? LOW : HIGH);
     
    }
    else if ( newstate == AS_CM_JT_OFF ) {
      digitalWrite(pin,lowact ? HIGH : LOW);
    }
    BaseChannel::changed(true);
  }


Wenn newstate == AS_CM_JT_ON dreht er also die Whileschleife dimmt hoch und macht danach den üblichen Aufruf "digitalWrite(pin,lowact ? LOW : HIGH);"
Das funktioniert auch, aber leider nur nach jedem Neustart genau einmal. beim zweiten Mal anschalten, schaltet die Lampe wieder "hart" an. Seltsamerweise muss die Schleife aber trotzdem irgendwie durchlaufen, denn das Feedback, dass die Lampe nun an ist kommt in FHEM mit genau der Verzögerung an die dem Delta ebenmeiner Schleife entspricht.
Ich hoffe ich habe das halbwegs verständlich wiedergegeben. In der Hoffnung auf eine Lösung. ;-)

i wird am Anfag auch als "unsigned int i = 0;" deklariert.

Schöne Grüße,
Patrick

btw: ja, ich weiß dass es unter Examples auch den Dimmer gibt. Das einfache An- und Ausschalten sollte einfach nur schicker gemacht werden, und da erschien mir "HM-LC-SW1-BA-PCB" perfekt zu. Zudem will ich ja noch was lernen dabei. ;-)

Tom Major

Zitat von: Klaus0815 am 25 Oktober 2018, 19:46:37
Hallo Tom,

habs gleich mal getestet, funktioniert :-)

Im FHEM Script ist noch ein kleiner Fehler:
Die jetzt neue Zeile "Digital Input" wird nicht aktualisiert
(Bei state, wo alle Werte angezeigt werden, sieht man aber die Änderung)

Viele Grüße

Klaus

Hallo Klaus,
der neue "Digital Input" wird genau so in die event queue gepusht wie auch die anderen Daten
push (@events, [$shash, 1, 'digital input:' . $digInput0]);
deswegen wüsste ich auf die Schnelle nicht woran das liegt.
Am besten du meldest dich mal per PM, ich möchte hier diesen Thread nicht damit belasten da dieses Problem doch etwas off-topic ist.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: Tom Major am 26 Oktober 2018, 19:32:14
Hallo Klaus,
der neue "Digital Input" wird genau so in die event queue gepusht wie auch die anderen Daten
push (@events, [$shash, 1, 'digital input:' . $digInput0]);
deswegen wüsste ich auf die Schnelle nicht woran das liegt.
Am besten du meldest dich mal per PM, ich möchte hier diesen Thread nicht damit belasten da dieses Problem doch etwas off-topic ist.

Nachtrag, vielleicht hilft es noch jemanden:
Die Aktualisierung des neuen Readings "Digital Input" funktioniert jetzt bei Klaus0815 auch in FHEM.
Der Fehler war das im Perl script an dieser Stelle
push (@events, [$shash, 1, 'digital input:' . $digInput0]);
kein Leerzeichen im Reading Namen 'digital input:' sein darf, der state (wo alle Werte drin sind) wird korrekt aktualisiert, nur halt das Reading selbst nicht. Ohne Leerzeichen alles Bestens.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

kpwg

#1079
Zitat von: Tom Major am 30 Oktober 2018, 23:39:52
Nachtrag, vielleicht hilft es noch jemanden:
Die Aktualisierung des neuen Readings "Digital Input" funktioniert jetzt bei Klaus0815 auch in FHEM.

Hier in meiner Testumgebung klappt es auch wie gewünscht. Das Reading wird bei jedem Tastendruck aktualisiert. Eine sehr gut geignete Funktion, um einen Tür- oder Fensterkontakt zu gestalten.

Viele Grüße,

Ricardo