AskSin++ Library

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

Vorheriges Thema - Nächstes Thema

papa

#825
Es gibt in examples/custom/HB-GEN-SENS einen generischen Sensor, der Temperatur & Luftfeuchtigkeit sendet. Damit er in FHEM funktioniert, muss das Module HMConfig_AskSinPPCustom.pm installiert werden - einfach in das FHEM Verzeichnis kopieren.
Nach dem Pairing muss noch dem FHEM-Device mitgeteilt werden, wie die Nachrichten zu interpretieren sind. Dazu muss das Custom-Attribute valueformat angelegt werden:
attr DEVICE userattr valuesformat
attr DEVICE valuesformat SPEC1 SPEC2

Dabei ist für jeden gesendeten Wert eine Spezifikation durch Freizeichen getrennt anzugeben. Die SPEC besteht aus 3 Teilen, wobei nur der erste zwingend notwendig ist:
Anzahl Bytes - 1, 2 oder 4 - gefolgt von einem 's' wenn vorzeichenbehaftet
Name des Reading - wenn angegeben wird der Wert in dieses Reading gespeichert - default valueX
Faktor - empfangener Wert wird durch den Faktor geteilt - default 1

Für das Beispiel ist folgende Spezifikation zu verwenden:
2s:temperature:10 1:humidity
Also die Temperatur wird mit 2 Byte übertragen. Der Wert ist um den Faktor 10 erweitert. Das erzeugte Reading wird temperature heißen. Der zweite Wert ist ein Byte lang und nur positiv. Er wird im Reading humidity gespeichert. Je nachdem, was gesendet wird, muss der Formatstring im Device angelegt werden.
Ich hoffe mal, das kann man irgendwie verstehen. Es gibt auch noch ein paar Vorbereitungen, um einfach neue Devices mit unterschiedlichen Channels "einfach" in FHEM anzumelden. Das versuche ich demnächst nochmal zu erklären.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Ich habe mal nen neuen V3 Branch gemacht. Dieser sollte jetzt für aktuelle Projekte verwendet werden. Im Master wird wahrscheinlich neue Hardwareunterstützung dazu kommen. Dabei könnte sich auch was an den APIs ändern.
Außerdem habe ich mal ein paar Links zu Hardwareprojekten in die erste Seite eingefügt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Hat denn mittlerweile schon mal jemand ein 2 Kabel Counter zum laufen gebracht?

/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)

papa

Zitat von: ext23 am 21 Mai 2018, 15:55:24
Hat denn mittlerweile schon mal jemand ein 2 Kabel Counter zum laufen gebracht?

Probiere doch mal den generischen Sensor. Da kannst Du Deine 2 Zählerwerte einfach mit einer Nachricht an FHEM senden. Der Umbau auf 2 Zähler sollte auch nicht so dramatisch sein.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Zitat von: papa am 22 Mai 2018, 11:30:30
Der Umbau auf 2 Zähler sollte auch nicht so dramatisch sein.

Das habe ich bei der "Kopie" des HM-ES-TX-WM auch gedacht ^^
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

jp112sdl

Zitat von: Franki am 19 Mai 2018, 06:28:10
Hallo Papa,

Exzellente Arbeit!!
Kopplung des WDS100 klappte auf Anhieb. Leider sind die Werte fixiert. Temperatur, Feuchte Licht sehe ich nicht als Problem, sollte analog zu anderen Beispielen implemtierbar sein.
Als wesentlich schwieriger sehe ich die Implementierung des Regenmengenmessers oder auch des Windmessers (2 Counter?, Stromverbrauch?)
Hier habe ich leider zuwenig Kentnisse diese zu implementieren.
Alternativ: externe Zähler?
Hast Du vor diese zu implementieren oder irgendwer im Forum eine Lösung?

LG
Frank

Ich versuche mich auch gerade daran, einen Wind- und Regenmesser zu integrieren.
Zwar nicht bei dem WDS100, aber bei einem eigenen Sketch.
Stromtechnisch bin ich da entspannt, da die Schaltung von einem Netzteil versorgt wird.

Ich würde nicht auf einen externen Zähler zurückgreifen wollen, sondern den 328P die beiden Dinger mitzählen lassen.
Meine Idee wäre, 2 Interrupthandler anzulegen, die jeweils einen (Regen-/Wind-)Counter hochzählen.

Bei Regenmesser ist es m.M. eh nicht zeitkritisch.
Wenn z.B. ein Impuls kommt, während gerade gesendet wird, dann wird er halt bei der nächsten Aussendung mit übertragen.

Beim Windmesser sehe ich da eher das Problem, da man die Anzahl der Impulse in einem festgelegten Zeitraum zählen muss, die Geschwindigkeit zu berechnen.
Ich werde mal ein paar Versuche machen, sobald ich das Anemometer gedruckt habe.
Mir schwebt vor, eine AlarmClock anzulegen, die dann alle 5 Sekunden die Windgeschwindigkeit ermittelt.
Ist aber alles noch ein Gedankenspiel... mal schauen, wie es sich dann in der Praxis verhält.

Vielleicht hat ja papa noch einen Einwurf bzw. Denkanstoß. :)

papa

Zitat von: jp112sdl am 22 Mai 2018, 15:59:47
Vielleicht hat ja papa noch einen Einwurf bzw. Denkanstoß. :)

Hab ich - der Windmesser sollte direkt mit einem Hardware-Counter verbunden werden, da  ich hier doch sehr viele Impulse erwarten würde. Gegebenenfalls müsste noch per Hardware entprellt werden. Leider ist der 16bit-Counter schon weg. Bleibt also nur ein 8bit-Counter. Da müsste man mal überlegen/ausmessen, wie oft man den Wert lesen und zurücksetzen muss, damit man bei Orkan (bis 200km/h) noch keinen Überlauf kriegt. Alternativ müsse man noch nen ISR für den Überlauf vorsehen. Das Auslesen könnte über die sysclock mit einem Alarm mit async(true) erfolgen. Dabei dürfte aber nur der Wert umkopiert werden, da man direkt im ISR ausgeführt wird. Beim zyklischen Senden kann man dann ganz in Ruhe die erfassten Werte verarbeiten.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

jp112sdl

Zitat von: papa am 22 Mai 2018, 16:15:20
Hab ich - der Windmesser sollte direkt mit einem Hardware-Counter verbunden werden, da  ich hier doch sehr viele Impulse erwarten würde.
Den DS2423 gibts ja nirgends mehr oder nur zu utopischen Preisen.
Ich habe was vom ATTiny als Ersatz gelesen (https://wiki.fhem.de/wiki/1-Wire_Emulation_per_ATTiny#ATtiny25), aber das scheint auch nicht ganz trivial zu sein.
Gibts noch andere Alternativen?

Zitat von: papa am 22 Mai 2018, 16:15:20
Leider ist der 16bit-Counter schon weg. Bleibt also nur ein 8bit-Counter. Da müsste man mal überlegen/ausmessen, wie oft man den Wert lesen und zurücksetzen muss, damit man bei Orkan (bis 200km/h) noch keinen Überlauf kriegt. Alternativ müsse man noch nen ISR für den Überlauf vorsehen.
Versteh ich noch nicht ganz.
Kann ich nicht
volatile uint32_t cnt = 0;
deklarieren und cnt dann inkrementieren?

Wenn ich mich nicht verrechnet habe, komme ich bei 200km/h auf ~84 Imp./Sekunde.
Zu viel für den ISR?


Zitat von: papa am 22 Mai 2018, 16:15:20
Das Auslesen könnte über die sysclock mit einem Alarm mit async(true) erfolgen. Dabei dürfte aber nur der Wert umkopiert werden, da man direkt im ISR ausgeführt wird. Beim zyklischen Senden kann man dann ganz in Ruhe die erfassten Werte verarbeiten.
Das leuchtet ein. :)

papa

Zitat von: jp112sdl am 22 Mai 2018, 17:02:43
Versteh ich noch nicht ganz.

Die Hardware Timer sind nur Counter, die mit dem Takt verbunden sind. Der Takt kann auch von einem externen Pin kommen. Dann werden die Impulse vom Pin gezählt. Für Timer0 ist das T0 = PB0. Und für Timer2 ist das T1 = PB1.
Aber 84 Impulse pro Sekunde sollten auch noch mit einem ISR machbar sein.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: Klaus0815 am 20 Mai 2018, 11:36:10
Hallo Tom,

hatte Deinen Post damals übersehen, eigentlich genau das was ich suche

2 Fragen:
- Funktioniert es mittlerweile mit FHEM, hat es jemand getestet? Kann man auch in FHEM die Devices konfigurieren?
- wie schwierig / einfach wäre es, zusätzlich einen Taster einzubauen?

Ich habe noch einige MySensors-Teile am laufen, mehr schlecht als recht, will diese ersetzen.
Aber an fast allen habe ich entweder einen Bewegungsmelder oder einen Taster zum Licht schalten o.ä. dran.

Viele Grüße
Klaus

Den FHEM Perl code habe ich nach besten Wissen und Gewissen an das Nachrichtenlayout von meinem HB-UNI-Sensor1 Beispiel angepasst, kann es aber nicht testen da ich momentan Homematic devices mit RaspberryMatic getrennt von FHEM aufsetze. Ich könnte aber bezüglich des FHEM script unterstützen falls es mit einem Messwert in FHEM noch klemmen sollte..

Für den Taster würde ich mittels EnableInterrupt Lib diesen so programmieren dass er den AVR aufwecken kann und dann den Zustand des Taster in einem weiteren Byte/Bit der message übertragen, d.h. die message ein Byte länger machen. Nur eine Idee, Möglichkeiten gibt es viele.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: jp112sdl am 22 Mai 2018, 17:02:43
Den DS2423 gibts ja nirgends mehr oder nur zu utopischen Preisen.
Ich habe was vom ATTiny als Ersatz gelesen (https://wiki.fhem.de/wiki/1-Wire_Emulation_per_ATTiny#ATtiny25), aber das scheint auch nicht ganz trivial zu sein.
Gibts noch andere Alternativen?

Die DS2423 ATtiny Emulation geht übrigens super. Habe die an diversen S0 Stromzählern über OWserver angebunden, läuft seit mehreren Jahren problemlos.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: papa am 22 Mai 2018, 17:19:40
Die Hardware Timer sind nur Counter, die mit dem Takt verbunden sind. Der Takt kann auch von einem externen Pin kommen. Dann werden die Impulse vom Pin gezählt. Für Timer0 ist das T0 = PB0. Und für Timer2 ist das T1 = PB1.
Aber 84 Impulse pro Sekunde sollten auch noch mit einem ISR machbar sein.

Sind die Zähler Eingangspins nicht eher T0=PD4, T1=PD5 beim mega328P?
Ist mir jetzt fast unangenehm den Meister zu berichtigen. duck und weg..
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

ext23

Das ist übrigens ein entscheidender Vorteil gegenüber dem ESP, der kann das nämlich nicht, einen Counter über einen externen Takt zu bedienen. Da muss man immer über den Int weg gehen, der aber bei hohen Frequenzen schnell in die Knie geht, wo der AVR erst anfängt warm zu laufen...

/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)

Tom Major

Zitat von: papa am 22 Mai 2018, 16:15:20
Hab ich - der Windmesser sollte direkt mit einem Hardware-Counter verbunden werden, da  ich hier doch sehr viele Impulse erwarten würde. Gegebenenfalls müsste noch per Hardware entprellt werden. Leider ist der 16bit-Counter schon weg. Bleibt also nur ein 8bit-Counter. Da müsste man mal überlegen/ausmessen, wie oft man den Wert lesen und zurücksetzen muss, damit man bei Orkan (bis 200km/h) noch keinen Überlauf kriegt.

Wenn man für diverse Zwecke doch noch 16bit counter braucht kann man übrigens den ATmega328PB nehmen.
Der hat neben weiteren Erweiterungen (z.B. eine zweite SPI) zwei zusätzliche 16bit timer/counter T3 und T4 die über die Pins PE3 und PE1 zählen können.

Eine geeignete HW dafür wäre z.B. der Pololu A-Star 328PB Micro
https://www.pololu.com/category/239/a-star-328pb-micro
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker