Hallo Zusammen,
In diesem Thread geht es um die Entwicklung einer Arduino Library um mit Homematic Geräten kommunizieren zu können.
Ziel der Library soll es sein, eigene Homematic kompatible Geräte entwickeln zu können, oder bestehende Geräte um Funktionen zu erweitern.
Die Library soll möglichst viele Funktionen des Protokolls abdecken so das man sich auf die eigentliche Funktionalität des Devices konzentrieren kann.
Die Library soll möglichst universell sein, so das man Schalter, Sensoren und Aktuatoren erstellen kann.
Aufbau der Library:
Derzeit besteht die Library aus 3 Teilen:
1. Der Userbereich in "sketch_aug05a.ino" (am 5. August habe ich damit begonnen)
Hier wird die eigentliche Funktionalität programmiert. Dazu werden alle relevanten Protokollfunktionen zur Verfügung gestellt.
2. Der Registerbereich in "register.h"
Hier wird das Gerät konfiguriert. Im oberen Bereich werden Dinge wie Seriennummer, HM ID, etc. festgelegt.
Danach folgt die Registerkonfiguration, also über welche Register das Gerät verfügt und wo diese im EEprom abgelegt sind.
Recht weit unten gibt es eine Funktion um default Werte ins EEprom zu schreiben (ist nicht schön und ich werde mir da
auch noch etwas Anderes einfallen lassen)
Zur Definition der Register arbeitet Martin an einem Perl Script das die Definition sehr einfach macht.
3. Der Library Bereich mit "AskSin.cpp" und "AskSin.h".
Das ist die eigentliche Library, hier wird alles Protokoll spezifische gesteuert. Im wesentlichen beruht hier alles auf
einer Poll-Funktion die in der Main Loop im Userbereich aufgerufen wird.
Register und Konfigurationsanfragen der Zentrale werden von der Library eigenständig beantwortet.
Commands von der Zentrale und Events von angelernten Peers werden dem Userbereich über einen Jumptable zur
Verfügung gestellt. Events und Commands können aus dem Userbereich per Funktionsaufruf genutzt werden.
Es gibt auch Dank Rohan bereits ein Wiki: http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library (http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library)
Im Wiki findet ihr weitere Infos, verwendete Hardware, etc.
Ich würde mich freuen wenn ich hier möglichst viele Mitstreiter finden könnte. Zum Programmieren, Testen,
Ideen austauschen, Hardware entwickeln, etc...
Die Library kann jeder nutzen und weiter entwickeln solange er seine Ergebnisse der Allgemeinheit wieder zur
Verfügung stellt und keine wirtschaftlichen Nutzen daraus zieht!
Die Library liegt ab sofort hier: https://github.com/trilu2000/AskSin
Viele Grüße und viel Spass beim Testen
Horst
Hi,
Anfangen muss man sicher mit der kommunikation und daten-organisation. HM-devices ist weitgehend "identisch"und folgen einem (ziemlich) strikten Muster. Dies sollte (muss) man nachbauen.
Als Ziel stelle ich mir vor eine Platform zu haben in die man einfach eigene Sensoren erstellen kann, mit beliebiger Anzahl Kanäle oder Parameter. Der User kann am "Sensor" die Messwerte in einen Format pressen und diese am User-ende in den Readings wiederfinden und bearbeiten. damit lassen sich evtl einfach und billige temperatur-sensoren verdrahten (onwire kosten nur 1-2€...). Wenn man einen Raum mit Heizung ausmessen will braucht man min 3 Sensoren. Heizung vorlauf/rücklauf und min einen Raumfühler. das addiert sich...
also erst einmal die Grundlagen, dann die Spass-Elemente
Gruß Martin
Ok, dann fangen wir mal an :-)
Pairen, wie geht das?
Ich vermute mal, das setzen des pairen parameters in FHEM schaltet den CUL in irgendeinen "lausch Modus".
Das drücken des Tasters am HM Device sendet einen String mit DeviceID ins Blaue und lauscht dann auf eine korrekte Antwort.
FHEM empfängt den gesendeten String und schickt die fhemID zurück.
Stimmt das so?
Ach ja, wie lang ist max die DeviceID?
Vielleicht kann Martin hier ein wenig anhand von Beispielen erklären?
Hallo trilu,
interesant. Ein ähnliches Projekt hatten wir hier auch vor. Das liegt hier aber schon eine Weile rum. Ggf. könnte man da was zusammen.
Als Funkmodul benutze ich die hier:
http://www.aliexpress.com/item/CC1101-Wireless-Module/452721042.html (//www.aliexpress.com/item/CC1101-Wireless-Module/452721042.html)
Gruß
Dirk
Zitat von: martinp876 schrieb am Di, 06 August 2013 11:12Als Ziel stelle ich mir vor eine Platform zu haben in die man einfach eigene Sensoren erstellen kann, mit beliebiger Anzahl Kanäle oder Parameter.
auja... :)
Zitat von: Dirk schrieb am Di, 06 August 2013 13:02Als Funkmodul benutze ich die hier:
433MHz dürfte aber bei Homematic schwierig werden...
Hi betateilchen,
der CC1101 wird per Register auf die passende Frequenz eingestellt.
Zugegeben die Antennenanpassung ist dann nicht optimal, aber hier in der Wohnung funkt das Teil auf 868Mhz ohne Probleme.
Und bei dem Preis kann man fast nix falsch machen.
Gruß
Dirk
Man kann die Frequenz beim cc1100 ja einstellen - ist wie beim CUL.
Geht aber auf Kosten der Reichweite, da Spulensetup und Kondensatoren falsch dimensioniert.
Zum testen reicht es aber allemal.
Vom Preis Leistungsverhältnis ist die panStamp nicht zu toppen.
Billigstes TRX868 Modul dürfte aus einem MAX Fensterkontakt sein - Kostet als Bausatz 14 Euro.
Dazu ein Arduino Mini Pro Modul aus Fernost kostet etwa 6 Euro.
Für 18 Dollar + MwSt. bekommt man eine panStamp....
könnte man eigentlich auch ein Sendemodul aus einem FS20 Gerät verwenden?
Bei ELV gibts grade einen Bausatz (//www.elv.de/2-4-kanal-sendemodul-s4m-komplettbausatz.html) in dem ein Sender steckt für 9,95 Euro.
Zitatkönnte man eigentlich auch ein Sendemodul aus einem FS20 Gerät verwenden?
Leider nicht, da diese ausschliesslich "AM" senden. Homematic sendet mit FSK (wenn ich mich recht erinnere). Und den CC1101 kann man entsprechend Konfigurieren. Daher kann der CUL auch FS20 oder Homematic.
Gruß
Dirk
schade,
aber das hier (//www.elv.de/homematic-schaltaktor-fuer-batteriebetrieb-komplettbausatz.html) müsste passen :) Sowas habe ich noch hier rumliegen.
geht noch billiger :-)
http://www.elv.de/max-fensterkontakt-arr.html (//www.elv.de/max-fensterkontakt-arr.html)
aber nicht, wenn der erstgenannte Bausatz sowieso ungenutzt rumliegt :o)
Zitataber das hier müsste passen :) Sowas habe ich noch hier rumliegen.
Ja, der funktioniert.
Eigentlich sollte man bei ELV mal anfragen ob die die TRX868-Module auch einzeln verkaufen.
Die Sender und Empfänger für FS20 gibts ja auch einzeln.
Gruß
Dirk
noch billiger (//de.rs-online.com/web/p/low-power-funkmodule/7312789/) und mit Stiftleiste ideal zum Experimentieren.
Gibts natürlich auch zum Löten (//de.rs-online.com/web/p/low-power-funkmodule/7312798/)
Die RFM12-Teile gibts auch bei Pollin und Co für knapp nen 5er. Hab aber noch keinen gesehen, der es erfolgreich geschafft hat FS20 oder Homematic damit zu Schalten. Der CC1101 nat auch noch den Vorteil extremst energiesparend zu sein, und auch im Empfang mit Batterie, Monate lang im Standby zu bleiben.
Daher bevorzuge ich derzeit die CC1101 Module.
Von den Dingern hab ich auch noch welche hier liegen.
Gruß
Dirk
na dann bauen wir uns doch ein Arduino-Shield damit: klick (//de.rs-online.com/web/p/hf-transceiver/0459594/)
in der lib hier https://github.com/glueckkanja/AvrHmLibrary (//github.com/glueckkanja/AvrHmLibrary) die ich in dem anderen thread schon mal verlinkt hatte geht angeblich das pairen und der code fuer einen hm dimmer ist da auch schon drin.
gruss
andre
Das hatte ich tatsächlich schon mal überlegt.
Aber bisher aus Zeitgründen noch nicht umgesetzt.
Die CC1101 bekommt man sicher noch etwas günstiger.
Allerdings hätte ich hier gerne ein Shield um den HF-Teil gehabt. So wie bei den ELV-Teilen.
Und da habe ich bisher keine Quelle gefunden.
Und selber biegen macht nicht so viel Spass.
Gruß
Dirk
@andre - das habe ich ja gesehen, aber ganz ehrlich - ich kann mir die funktion aus dem dort liegenden code
nicht zusammen basteln.
meine hoffnung ist es, das protokoll zu verstehen und eigene wege zu finden.
komischerweise hab ich schon viele threads gelesen in denen leute nach einer arduino lib fragen, aber keiner hat sie bisher gebastelt...
und das projekt auf der seite steht auch seit einem jahr mit folgenden offenen punkten:
ACK/NACK handling
peers/parameter handling
mir ist es aber wichtig das peers handling zu haben, folglich muss ich selber ran!
Zitatkomischerweise hab ich schon viele threads gelesen...
ja. das stimmt. auch bei langem suchen ist fast nichts zu finden. deswegen wundert es mich das in dieser lib angeblich schon einiges geht.
klasse das es jemand angeht. und das es eventuell auf den panstamps läuft :)
gruss
andre
Das Einzige bei den panStamps könnte die Interrupt Zuordnung sein - ich habe noch nicht nachgeschaut wie die GDO_0 und GDO_2 bei panStamp verdrahtet sind.
Vielleicht findet sich ja jemand der das mal testen könnte.
laut schaltplan ist GDO2 nicht verbunden und GDO0 geht nach PD2(INT0/PCINT18).
gruss
andre
Dann muss folgendes in AskSin.cpp geändert werden:
In Funktion - void cc1100_init(void)
von:
static const uint8_t conf[] = { // config settings
0x00, 0x07, // IOCFG2: packet CRC ok
0x02, 0x2E, // IOCFG0:
nach:
static const uint8_t conf[] = { // config settings
0x00, 0x2E, // IOCFG2:
0x02, 0x07, // IOCFG0: packet CRC ok
und weiter unten in uint8_t cc1100_recvDone() {
von:
uint8_t status = 0;
if (GDO_PIN & (1 << GDO_2)) {
nach:
uint8_t status = 0;
if (GDO_PIN & (1 << GDO_0)) {
Sketch schon mal geändert und meine HW gleich mit - sollte jetzt auch auf den panStamps laufen.
Ich habe mal angefangen mit load und save config und eine serielle console zum konfigurieren (läuft aber noch nicht!)
geil :) das erste mal etwas zu sehen...
ein HM-LC-Sw1PBU-FM ein und wieder aus geschaltet:
start AskSin sketch
SPI_init done
cc1100_init:1234.......................5..........6
cc1100_init done
-> 15 A0 11 F1 00 00 1A EC C9 02 01 C8 00 00 (14)
-> 16 A0 11 F1 00 00 1A EC C9 02 01 00 00 00 (14)
gruss
andre
ps: die zweite änderung war nicht nötig. die zeile sah schon so aus...
@andre - ist das jetzt auf einem panStamp?
ja. das ist auf einem panstamp.
ich weiss noch nicht ob die nachricht sinn macht aber es ist das erste mal überhaupt etwas zu sehen. ich hatte die rf paramter für fs20 und fur hm schon mal probiert aber nie daten gesehen.
gruss
andre
Das weiss ich leider auch nicht - ich muss mich jetzt mal mit den byte-folgen beschäftigen.
Vielleicht kannst du mal mitloggen was beim pairen so hin und her geschickt wird...
ich kann dir alles loggen was du magst...
die beiden zeilen von oben schauen mir noch etwas kurz aus.
der gleiche ausschaltvorgang mit einem cul und einem hmlan schaut so aus:cul2_RAWMSG A0E1680021AECC9F10000010100002D39
hmlan_RAWMSG E1AECC9,0000,0A9B5C3B,FF,FFA9,1680021AECC9F10000010100002D
die HMid ist aber schon mal identisch: 1AECC9
ich versuche nachher auch noch mal den sketch aus der anderen lib.
Zitat von: Dirk schrieb am Di, 06 August 2013 16:38Allerdings hätte ich hier gerne ein Shield um den HF-Teil gehabt.
Kannst Du mir mal bitte die Maße von so einem Teil geben?
Keine Ahnung was ich gedrückt habe, aber jetzt kommen auch längere Strings :-)
Available commands:
<nnn> i - set device ID (3 bytes)
l - load configuration from EEPROM
w - write configuration to EEPROM
-> DA A2 40 1F A6 5C 63 19 63 01 A5 (11)
-> DA A0 03 1F A6 5C 63 19 63 BF 24 3A 37 3E 14 05 EB B4 68 47 C1 38 C7 84 62 (25)
-> DA 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> DB A0 02 63 19 63 1F A6 5C 04 95 03 A5 EB 8A B7 02 (17)
-> DB 80 02 63 19 63 1F A6 5C 00 81 DD DE 9F (14)
-> DC A2 40 1F A6 5C 63 19 63 01 A7 (11)
-> DC A0 03 1F A6 5C 63 19 63 72 28 0C DE A2 9D 67 3B 10 0A B7 3C C0 64 8F 9C (25)
-> DC 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> DD A0 02 63 19 63 1F A6 5C 04 9C 0A AC E2 83 BE 02 (17)
-> DD 80 02 63 19 63 1F A6 5C 00 89 94 68 A0 (14)
-> DE A2 40 1F A6 5C 63 19 63 01 A9 (11)
-> DE A0 03 1F A6 5C 63 19 63 5E 93 DC 7B 9F 2D 46 D3 3D 55 6E E4 CF 25 85 65 (25)
-> DE 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> DF A0 02 63 19 63 1F A6 5C 04 84 12 B4 FA 9B A6 02 (17)
-> DF 80 02 63 19 63 1F A6 5C 00 01 49 C7 D4 (14)
-> E0 A2 40 1F A6 5C 63 19 63 01 AB (11)
-> E0 A0 03 1F A6 5C 63 19 63 31 FE B8 7F 10 3A FE C6 9C 8E 5D 3B 1F 0B 46 AC (25)
-> E0 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> E1 A0 02 63 19 63 1F A6 5C 04 8C 1A BC F2 93 AE 02 (17)
-> E1 80 02 63 19 63 1F A6 5C 00 A9 99 4F 33 (14)
-> E2 A2 40 1F A6 5C 63 19 63 01 AD (11)
-> E2 A0 03 1F A6 5C 63 19 63 85 A6 31 E2 C8 88 80 4C DA 4C 0E F7 94 C5 A4 BB (25)
-> E2 80 02 63 19 63 1F A6 5C 01 01 C8 00 (13)
-> E3 A0 02 63 19 63 1F A6 5C 04 85 13 B5 FB 9A A7 02 (17)
-> E3 80 02 63 19 63 1F A6 5C 00 C0 A3 45 46 (14)
Ich versuche gerade den Empfang auf Interrupt basiert umzubiegen und komm in den Wald.
Vielleicht hat ja jemand Lust und Zeit sich auch einmal daran zu versuchen.
mir ist jetzt der Aufbau nicht klar (muss evtl noch einmal den Thread lesen?)
1FA65C sendet einen trigger an 631963 sowie einen AES reply hinterher.
631963 schaltet "ein" und sendet einen AES request. Dann auch noch eine Quittung an sich selbst - mit einem etwas seltsamen Status.
Wird der Code aus Panstamp erzeugt? Mit welcher SW? Wo hast du gedrückt?
Gruss Martin
nein, musst du nicht lesen :-)
ich habe heute noch ein paar verbesserungen an der empfangsroutine gemacht, war noch buggy - jetzt läuft sie stabil und ich bekomme alle messages mit. jetzt würde ich gerne mit dem pairing anfangen.
ich habe jetzt mal testweise die pairing taste von einem 6 tasten wandsender aufgezeichnet, der string sieht so aus:
-> 2C A2 00 1F A6 5C 63 19 63 11 00 A9 4B 45 51 30 33 31 38 38 31 30 40 06 00 A2 (26)
jetzt bräuchte ich deine hilfe bei der interpretation. was ich verstanden habe ist
2C - Messagecounter
A2 - ??
00 - Message type, 00 heisst pairing?
1F A6 5C - eigene DeviceID
63 19 63 - zu pairende DeviceID, wäre nach einem Reset leer?
11 00 A9 4B 45 51 30 33 31 38 38 31 30 40 06 - keine ahnung
00 - channel?
A2 - weiss nicht?
kannst du hier ein wenig licht ins dunkel bringen?
muss ich den AES Key speichern?
2C - Messagecounter
A2 - Bitfeld - flags für die Message. Hier: message an die Zentrale (2), ACK angefordert (20) und message (80)
00 - Message type, 00 heisst pairing? - kann man so sagen
1FA65C - sourceID
631963 - destination ID. 000000 ist broadcast. Bei dieser message kann es immer 000000 sein,
11 FW version
00A9 Model identify
4B 45 51 30 33 31 38 38 31 30 Seriennummer Ascii kodiert: KEQ0318810
40 Klasse, Subtype identify
06 Anzahl Kanäle (ist aber nicht immer so!!!)
00A2 unklar - sagt wahrscheinlich etwas über Kommunikations-modi aus.
Den Key musst du nicht speichern. Der gesendete String aendert sich immer, sonst wäre es zu einfach, es zu knacken. Der Key wird m.e. zu einem anderen Zeitpunkt ausgetauscht.
Du hast also den panstamp als IO device laufen. Kann man machen. Sortieren wir einmal:
Wenn du einen Panstamp als IO-device nutzen willst musst to keinerlei HM messages dekodieren. Du schickst sie einfach an CUL_HM. Wir müssen hierfür nur ein neues IO modul bauen, dann haben wir noch eine alternative zu HMLAN und CUL/CUNO,...
Der schritt, der mich interessiert ist,den Panstamp als Aktor oder Sensor zu nutzen. Das wird wohl der nächste Schritt. Ich werde einmal ein paar messages ausarbeiten, die der Panstamp schicken muss. Wird der so etwas wie eine Anlerntaste haben?
Gruss Martin
Vielen Dank!
Meine HW läuft zur Zeit als Scanner :-)
Er belauscht einfach nur die Kommunikation. Ich will auch keinen CUL nachbilden, sondern eine Plattform für eigene Devices. Egal ob Aktoren oder Reaktoren. Blödes Wort!
Natürlich soll man damit auch Sensorwerte übertragen können.
Ich möchte nur als nächstes das pairen einbauen. Sonst bekommen wir das Device ja nicht sauber ins HM Netzwerk. Deshalb ja auch die Frage nach dem letzten String. Das ist ja dann der String den meine HW senden muss, so dass ein CUL oder HMLan darauf antworten kann.
Zur Frage nach der Anlerntaste. Ja werden wir wohl brauchen. Für den Anfang und zum Entwickeln werde ich die Taste aber über die serielle Konsole machen. Das macht das Leben leichter beim Testen...
Vielleicht kannst du mir auch schon die Antwort auf den pairing String erklären?
Noch eine Frage, der Messagecounter zählt einfach nur bis 255 und startet wieder bei 0. Bezieht sich der Counter auf Tx, oder zählt er auch bei Rx hoch?
Das ist ja mal ein Plan !
Der Portabilität zuliebe plädiere ich für *eine* platform. Ob RFM12B auf HM geht weiß ich nicht (theoretisch müsste das aber gehen) - wenn ja wären die jeelinks / nodes eine passende Platform. Panstamp mit den ccxx sicher die andere Alternative wobei ich der Meinung bin das die jeelinks das größere Angebot an "shields" haben (temp, hum, druck, piri, licht, led). Da bin ich aber nicht mehr auf dem laufenden, kann mittlerweile bei den PAN Stamps ja genauso gut aussehen.
Grüße
Jörg
Mein Vorhaben basiert auf dem cc1100 Chip von TI.
Für die JeeNodes gibt ein gutes Protokoll. Die RF12 Module cc1100 kompatibel zu machen wäre ein riesen Aufwand. Die Jeelib für die Peripherie kann man auch auf der panstamp HW nutzen.
so, mal wieder ein update der files...
die empfangsroutine sollte jetzt stabil sein und alles anzeigen!
das handling von GDO_0 ist auf panStamp HW angepasst.
kannst du noch irgendwelchen input oder logs gebrauchen ?
gruss
andre
So, hier der Beginn des interworkings. Erst einmal sind einige Parameter abzustimmen, siehe Text.
Panstamp HM protokoll
A) Message sequenznummer
Die Sequenznummer ist ein Wert zwischen 00 und FF mit einfachem Überschlag bei FF nach 00.
Wichtig ist, dass ACKs immer die Sequenznummer der ankommenden Message spiegeln MÜSSEN. Diese Nummer wird dann als neue genutzt und von hier weitergezählt.
Nach reset beginnt der Zähler mit '00'
B) Anlernmessage
1) Seriennummer: Jedes HM device hat eine 10-stellige Seriennummer
Bedeutung: für den Betrieb unwichtig.
Kann man eine Solche Nummer aus dem Device ableiten?
Vorgabe für den Test "PS00000001" = 50533030303030303031
Offen: wie soll die Nummer generiert werden? Fixer Wert?
2) ModelID: ist ein 2-Byte wert. HM füllt diese von 0000 an auf, also nutzen wir hohe Werte
Vorgabe für den Test: 8001
3) subType: werte ich nicht mehr aus. Ist eine Art Gruppen-ID
Vorgabe für den Test: 9F
4) DevInfo: hat noch unbekante bestandteile Mit unter steht die Anzahl der Kanäle drin.
Vorgabe für den Test: 010101
5)HMID: exterm wichtig. Wir brauchen ein verfahren, diese eindeuting zumindest im System zu setzen. Sie muss ggf geaendert werden koennen
Vorgabe für den Test: FF00xx mit xx eine Hex zahl zwischen 00-FF
Fertige Anlernmessage:
nn A200 FF0001 000000 10 8001 50533030303030303031 010101
Ohne Leerzeichen, versteht sich.
C) Acknowledge
wenn das Flag der empfangenen Message ein ACK anfordert muss eine Antwort kommen. Im einfachsten Fall ein ACK.
Das Flag (erste Byte nach SeqNummer) hat ein response-request wenn "Flag & 0x20" war ist.
Beispiel:
Request: nn A200 FF0001 112233 10 8001 50533030303030303031 010101
ACK: nn 8002 112233 FF0001 00
D) Wiederhohlen
eine Nachricht muss wiederholt werden wenn ein ACK angefordert wurde und dies nicht innerhalb von 300ms eingetrofen ist.
Es wird 3 mal wiederholt (default, wird einstellbar)
Fortsetzung folgt
Gruss Martin
Part II
A) Definition
Parameter eines HM devices werden nicht-flüchtig in Registern gespeichert. HM gruppiert Register in Bänken mit einem Addressraum von 256 Byte. Die Bänke werden über "list" und "links" adressiert.
Über diese Werte wird das Device-verhalten festgelegt.
Der Speicherraum einer Registerbank wird selten komplett genutzt. Er wird nicht sequenziell genutzt sondern bestimmte Adressen haben bestimmte Bedeutung. Daher werden die auch Register genannt.
B) Register Bänke
List0: gibt es einmal je Device. Hier wird das pairng mit der Zenrale hinterlegt sowie Protokol-spezifische Eigenschaften
List1: legt Parameter eines Kanals fest, welche vom Peer unabhämgig sind. z.B. Fahrzeiten eines Rollos
List2: für Aktoren und Sensoren nicht genutzt
List3: legt das Verhalten beim Bearbeiten eines Triggers fest. Daher gibt es List3 nur für Aktoren. Diese Liste ist einmal je Kanal/peer kombination vorhanden. Mit jedem Peeren wird eine entsprechenden Liste angelegt.
List4: ist das Pendant zu List3 für Sensoren, die man peeren kann.
List5: für Aktoren und Sensoren nicht genutzt
List6: für Aktoren und Sensoren nicht genutzt
List7: für Aktoren und Sensoren nicht genutzt
C) ImplementierungsDetails
Jede RegisterBank hat einen Adressraum von 256 Byte und muss in einen Flash oder EEPROM gespeichert werden. Will man ein Device mit 6 Kanälen realisieren und jeden Kanal 8mal peeren kommen wir auf einen Speicherbedarf von :
List0 + 6*List1 + 6*8*List3 = 55 Bänke =^ 13,75kByte
Zu beachten ist, dass die Bänke nur zu einem geringen Teil genutzt werden. Es ist daher zu überlegen eine optimierte Speicherverwaltung vorzusehen. In C könnte man eine struktur definieren, die nur genutzte Register realisiert
D) Lesen von Registern durch die Zentrale
Register lesen darf nur die eingetragene Zentrale.
Es wird IMMER eine komplette Registerbank gelesen. Einzelne Register können nicht gelesen werden.
Message zu Lesen:
<no>A001<src><dst><chan>04<peer><list>
no: Message counter
src,dst: Source und Destination HM ID. Jeweils 3 Byte in Uppercase HEX, also je 6 Byte Ascii
chan: Nummer des Kanals, der gelesen werden soll
peer: PeerID ist 4 Byte lang: 3 Byte HMId des peers plus 1 Byte des Peer Channels
list: Nummer der zu lesenden Liste
Beispiele
nn A001 1743BF 1A0A02 00 04 00000000 00 # lesen List0: channel, peer und list ist "0"
nn A001 1743BF 1A0A02 01 04 00000000 01 # lesen List1 den Channel 1: peer ist "0"
nn A001 1743BF 1A0A02 05 04 00000000 01 # lesen List1 den Channel 5: peer ist "0"
nn A001 1743BF 1A0A02 02 04 12345604 03 # lesen List3 den Channel 2: peer ist 123456, chan 04
Die Antwort des Devices ist
<no>A010<src><dst>03<addr><data><addr><data>... # max 5 byte
E) Schreiben von Registern durch die Zentrale
Register schreiben darf nur die eingetragene Zentrale. Ausgenommen ist die Phase nach drücken der Anlerntaste.
Das Schreiben von Registern ist eine Sequenz von Nachrichten.
1: Öffnen einer Bank zum Schreiben
2: schicken der Daten - ggf. mehrere Messages
3: schliesen der Bank, schreiben der Daten
Messages
<no>A001<src><dst><chan>05<peer><list> # öffnen der Bank zum Schreiben
<no>A001<src><dst><chan>08<addr><data><addr><data>... # max 5 byte
<no>A001<src><dst><chan>06 # schliesen der Bank
Beispiel: schreiben bein pairing:
<no>A001<src><dst> 00050000000000
<no>A001<src><dst> 0008 0201 0A17 0B43 0CBF # pair mit 1743bf, in Register 0A,0B und 0C der List 0
<no>A001<src><dst> 0006
wow, das sieht echt gut aus was du da beschreibst :-)
kannst du mir hier noch eine auflistung geben, welche flags es noch gibt:
// A2 - Bitfeld - flags für die Message. Hier: message an die Zentrale (2), ACK angefordert (20) und message (80)
(1)
(2) message an die Zentrale
(4)
(8)
(10)
(20) ACK angefordert
(40)
(80) message
das mit den registern wird so nicht funktionieren, der avr 328 hat leider nur 1kb :-(
40 = repeater (ein repeater hat die Nachricht wiederholt). Falls beide messages empfangen wurden nur eine auswerten
10 = burst transmission. Vorläufig irrelevant, so weit sind wir nicht
8 = unbekannt
4 = config mode
1/2 = werden auch im wakeup mode verwendet. Ebenfalls zukunft
Manche sind nicht 100% sicher Sicher sind
80/40/20/10/2
Als wichtigste Fragen empfinde ich, wie du devices Einstellen willst.
- wie kann man devices eine HMID geben?
- was soll in die Seriennummer?
=> sind die lästigen Fragen, aber es ist das Fundament.
pairen ist übrigens erst einmal nicht wichtig, da wir nicht so weit sind. Das pairen können wir aber als blueprint für Register schreiben und lesen nehmen.
- wieviel Speicher steht in einem panstamp für Register zu Verfügung?
Übrigens ist ein Fehler in der ersten Beschreibung: wenn man an Broadcast sendet kann man (logisch) nie ein ACK anfordern!
Gruss Martin
Sehr interesannt was hier abgeht.
Wird das Ganze dann auch auf den neuen Panstamps (CC430F5137 SOC / Texas Instruments)
funktionieren ?
Nicht, dass Ihr was tolles konstruiert, das dann "nur" mit den alten Panstamps funktioniert.
Nur so ein Gedanke ;-)
Gruss Martin
@martin8573
ob das auf den neuen panstamps funktioniert kann ich dir nicht sagen - ich hab ja noch nicht einmal eine aktuelle :-)
nein, im ernst, wenn der cc1100 oder cc1101 drauf ist, dann wird es mit grösster wahrscheinlichkeit funktionieren. zumindest habe ich die lib so vorbereitet das der spi port und chip select einfach zu konfigurieren sind.
@martin876
das einstellen sollte ziemlich einfach sein, einmal möchte ich das über den programm code machen - also so:
struct_hmConf hmConf;
void fillConf() {
hmConf.serID[0] = 'P','S','0','0','0','0','0','0','0','1'; // (10) serial ID, needed for pairing
hmConf.modID[0] = 0x80,0x01; // ( 2) model ID, describes HM hardware. we should use high values due to HM starts from 0
hmConf.subType[0] = 0x9F; // ( 1) not needed for FHEM, it's something like a group ID
hmConf.devInfo[0] = 0x01,0x01,0x01; // ( 3) describes device, not completely clear yet. includes amount of channels
hmConf.HMID[0] = 0xFF,0x00,0x01; // ( 3) very important, must be unique. identifier for the device in the network
hmConf.sendRetries = 3; // ( 1) how often a string should be send out until we get an answer
}
zum anderen haben die arduino's ja eine serielle schnittstelle und da möchte ich es auch konfigurierbar machen.
der freie speicher im eeprom ist beim avr328 nicht besonders üppig - er hat 1kb das wir nutzen können
ich könnte auch martin im quadrat antworten :-)
Zitatavr328 nicht besonders üppig - er hat 1kb das wir nutzen können
Dann ist wohl eine der ersten Aufgaben, diesen zu optimieren.
Zum einen brauchst du platz für HMID und Serialnumber, FW version, model,... und zum 2. für die "Register".
Der erste Teil ist einfach, da du diesen einfach seqenzuell ablegen kannst. Wenn du nicht noch viel Addiert sollten so 50byte reichen.
Ich gehe davon aus, dass die Register zur Kompilezeit klar sind. Dann kann man eine Struktur über das EEPROM legen und somit den Speicher optimal nutzen.
Mal so ins Blaue den Bedarf (festgemacht an vorhandenen Devices):
List 0: 20Byte
List 1: 20Byte
List 3: 80Byte
= 1* list0 + 4* List1 + 4*10*List3 = 3,3kByte. Geht so nicht.
Wir stossen also schnell an Grenzen. Ich bin der Meinung, das für einen Schalter min 6 peers zugelassen werden müssen. Will man 4 Kanäle betreiben kommt man auf 24* List3. das sind dann max 40 Register....
Aus meiner sicht ergibt dies, dass keinerlei Platz für "dynamische" Zuweisungen ist.
Evtl kannst du mit diesen Konzept beginnen:
Nach start einfach einmal eine Anlernmessage schicken, die Daten dafür aus den EEPROM lesen. Danach regL_00 implementieren und sich von FHEM die HMID der Zentrale schicken lassen und speichern.
Gruss Martin
Du machst mich fertig mit diesen Registern, ich verstehe nur noch Bahnhof :-)
Lass es uns vielleicht mal an zwei Beispielen durchspielen, welche Register brauche ich pro Gerät und wie groß müssen die Register wirklich sein? Ich kann ja was anderes senden, als wirklich gespeichert wird....
1. Sensor Node mit 3 Temperatursensoren
2. 1 Channel Dimmer für Leds
die register müssen doch nicht alle im ran oder eeprom liegen. alles was read only ist könnte doch z.b. auch in den flash speicher.
die daten eines panstamp wären diese hier:
Flash: 32 KB
RAM: 2 KB
EEPROM: 1 KB
die neuen panstamps werden 4kb ram haben.
gruss
andre
Danke, das meinte ich mit - es muss ja nicht alles im eeprom liegen was gesendet wird :-)
ZitatWir stossen also schnell an Grenzen.
Daher haben einige HM-Devices einen externen Eeprom der per I2C angebunden ist.
Update:
z.B. den AT24C32 (2-Wire Serial EEPROM)
der hat 32 kb Speicher.
Gruß
Dirk
nun, register sind User-Aenderbar und nicht flüchtig. Also EEPROM, von mir aus auch Flash. Welche Bänke hat das Flash? Halte ich als Option für unwahrscheinlich.
Alles was im Code ist ist kein "Register" mehr, da man es nicht aendern kann.
Welche Register zu Verfügung gestellt werden kann/muss man beim Bau der FW entscheiden. Das hält den Start des Projekts nicht auf. Ist aber gut, wenn man die Resourcen kennt. EEPROM ist im Vergleich zu HM devices nicht üppig, vorsicht hier.
Trotzdem - das wird ein elementarer Baustein der SW.
Stellt das "OS" auch timer zu Verfügung? Muss ich mir einmal ansehen, sonst kann ich nicht mitreden....
Gruss Martin
Ich würde auch grundsätzlich dazu tendieren, einen externen EEPROM Baustein zu verwenden.
Hi Martin,
Stellt das "OS" auch timer zu Verfügung?OS? Falls du den Mikrocontroller meinst, je nach AVR-Typ stehen unterschiedliche Timer zur Verfügung.
ZitatIch würde auch grundsätzlich dazu tendieren, einen externen EEPROM Baustein zu verwenden.
Diese sollten sich auch einfach an einem Panstamp andocken lassen Und die gibt es auch als DIL-Versionen.
Gruß
Dirk
Jetzt hab ich in den Bastelkisten gewühlt und tatsächlich einen Arduino gefunden. Eigentlich müssten davon noch viel mehr da sein, komisch. Am Wochenende werde ich dann wohl das Funkmodul verdrahten (heute hab ich dazu keine Lust mehr) und dann bin ich beim Testen auch mit dabei.
Hi Dirk,
ok, OS ist hoch gegriffen - aber ein paar system funktionen und ein dispacher ist vorhanden? Hilft nichts, ich muss lesen.
Für einfache Anwendungen sollten wir schon versuchen mit boardmitteln auszukommen. Ein externes EEPROM sollte nicht zum minimal System gehören. Es wäre ein add-on wenn die boardmittel nicht reichen.
Die "Platfom" darf dies nicht fordern, sollte es aber unterstützen.
Gruss Martin
so, und wieder mal ein update...
senden müsste jetzt auch gehen, dazu einfach in der seriellen console einen string in folgendem format mit carriage return absenden:
$0B $7F $A2 $40 $1F $A6 $5C $63 $19 $63 $01 $A2 <cr>
der string kommt dann in einen buffer und wird einmal versendet.
ACK handling ist vorbereitet, aber noch nicht implementiert.
testet mal bitte ob das so funktioniert.
ich bräuchte noch eine möglichkeit mir die empfangenen strings in fhem anzeigen zu lassen. am besten über eine telnet session.
ich nutze den HM USB Adapter und den hmland treiber.
mache doch einfache eine telnetsession in auf dein System auf. Dann ein tail -f <syslogfile> und du siehst alle logs live.
Und nun "weg mit den Mist" (nicht ernst nehmen...)
in FHEM
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1
Du solltest alles sehen, was HM formatiert kommt.
Klar: FHEM muss laufen ;-)
Gruss Martin
Zitat von: betateilchen schrieb am Do, 08 August 2013 20:24Am Wochenende werde ich dann wohl das Funkmodul verdrahten (heute hab ich dazu keine Lust mehr) und dann bin ich beim Testen auch mit dabei.
so... fertig gebastelt:
(http://up.picr.de/15442607cn.jpg)
und scheint auch zu funktionieren:
start AskSin sketch
SPI_init done
cc1100_init: 123.....................4 done
Available commands:
b,b,b i - set device ID (3 bytes)
b[0],b[n] s - send a string, b[0] is length (50 bytes max)
n/a - load configuration from EEPROM
n/a - write configuration to EEPROM
$nn for HEX input (e.g. $AB,$AC )
Jetzt muss ich mich noch hier durch den Thread wühlen um rauszufinden, wie das Ding jetzt genutzt wird.
Empfangen tut es schonmal fleißig. NSA hat grade den "I like it" Button geklickt :O)
ich blick da grade nicht mehr durch.
Könnte man mal zusammenfassen, was bisher funktionieren sollte?
Das Setzen einer Adresse mit i habe ich kapiert
Wie könnte man eine Temperaturnachricht (wie z.B. vom HM-WDS10-TH-O kommend) byteweise zusammenstellen und (to broadcast) senden, um die dann in fhem irgendwo auftauchen zu sehen?
die liste mit dem was funktioniert ist noch recht kurz
empfangen funktioniert
und dekodieren funktioniert
mit senden bin ich gerade dran, hatte aber keine möglichkeit zu
prüfen ob wirklich was gesendet wird.
ich habe zum empfang nur einen HM USB adapter. Wenn ich etwas sende
zeigt mir der Adapter nichts an, was mehrere ursachen haben kann:
der HM CFG filtert ungültige nachrichten
ich setze die sende parameter falsch
der string ist nicht ordentlich kodiert
usw...
deshalb ja die bitte zu prüfen ob das senden klappt. soweit ich weiss hat der CUL
einen modus in dem er alle nachrichten anzeigt.
ich habe hier auch den HM_USB-CFG im Einsatz, gesehen habe ich beim Senden auch nichts auf fhem-Seite. Deshalb war ja meine Idee, eine "bekannte" Nachricht zum Testen zu verwenden.
Eigentlich müßte doch ein zweiter HMduino als Empfänger ebenfalls funktionieren?
jap, ein zweiter panstamp oder arduino mit modul müsste auch gehen.
ich hab aber derzeit nur einen :-(
mit einer bekannten nachricht habe ich es schon probiert, habe aber kein ACK bekommen.
das hilft mir aber nur bedingt, da es an der init des sendeteils liegen kann
oder am falsch kodierten string.
wäre klasse wenn jemand zwei panstamps hätte und das mal testen könnte!
Wenn ich heute nicht Homeoffice hätte, wär das kein Problem.
Aber ich werde mal versuchen, den COC in Homematic Mode zu versetzen und zu schauen, ob dann was ankommt.
der COC (mit raw X25) sieht keine Nachricht vom Arduino.
so, nun geht senden :-)
war ein blöder configurations fehler...
viel spass beim testen!
kannst Du mal Beispiele posten, WAS man senden kann?
wie gesagt: Vielleicht wäre eine einfache Temperaturmeldung (wie von einem Außensensor kommend) an broadcast das am Besten nachvollziehbare.
Werde nachher die neue Version testen.
------------
edit: nachher ist jetzt. Das kommt am HM an, wenn man das weiter oben genannte Beisipel von Dir sendet.
2013.08.09 20:35:13.282 1: HMLAN_Parse: HMUSB R:E1FA65C stat:0000 t:0940E1A8 d:FF r:FFC1 m:7F A240 1FA65C 631963 01A2
2013.08.09 20:35:13.410 1: HMLAN_Parse: HMUSB R:E1FA65C stat:0000 t:0940E23F d:FF r:FFC1 m:7F A240 1FA65C 631963 01A2
2013.08.09 20:35:13.570 1: HMLAN_Parse: HMUSB R:E1FA65C stat:0000 t:0940E2D6 d:FF r:FFC1 m:7F A240 1FA65C 631963 01A2
Hi trilu,
Du bist ja ziemlich fleissig.
Ich kann leider erst nächstes Wochenende mit testen.
Ich bin schon gespannt.
Gruß
Dirk
Martin hat doch die beispiele weiter vorne erklärt. Ich habe einfach einen string mitgeloggt, diesen in die serielle console kopiert, mit dollar zeichen versehen und abgeschickt. Wichtig ist, das das erste byte die länge angibt.
Man sieht dann schön das man von der zentrale die ACKs bekommt.
Beispiele kommen morgen.
Viele grüße
Horst
$0C $5b $86 $70 $1C $CA $12 $00 $00 $00 $00 $E0 $3B
ergibt im Eventmonitor:
2013-08-09 20:49:50.345 CUL_HM out_Balkon temperature: 22.4
2013-08-09 20:49:50.345 CUL_HM out_Balkon humidity: 59
2013-08-09 20:49:50.345 CUL_HM out_Balkon T: 22.4 H: 59 D: 14.0
2013-08-09 20:49:50.345 CUL_HM out_Balkon dewpoint: 14.0
das ist doch schon mal was :)
Jetzt habe ich ein HM-Device angelegt:
Internals:
CFGFN
DEF FEFEFE
EVENTS 1
HMUSB_MSGCNT 3
HMUSB_RAWMSG EFEFEFE,0000,09537E2A,FF,FFC3,5B8670FEFEFE00000000E03B
HMUSB_RSSI -61
HMUSB_TIME 2013-08-09 20:55:33
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 3
NAME arduino
NR 1885
STATE ???
TYPE CUL_HM
lastMsg No:5B - t:70 s:FEFEFE d:000000 00E03B
protLastRcv 2013-08-09 20:55:33
rssi_at_HMUSB avg:-61 min:-61 max:-61 lst:-61 cnt:3
Readings:
2013-08-09 20:55:32 noReceiver src:FEFEFE 8670 00E03B
Helper:
mId 003D
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -61
cnt 3
lst -61
max -61
min -61
Attributes:
expert 2_full
model HM-WDS10-TH-O
peerIDs
und die Bytefolge - mit geänderter Adresse natürlich - ergibt:
2013-08-09 20:55:32.747 CUL_HM arduino noReceiver: src:FEFEFE 8670 00E03B
Sehr Cool was hier so passiert.
Ich habe noch ein paar BMP180 hier rumliegen.
dann gibt es ja vielleicht bald einen Lufttrucksensor für Homematic.
Da müsste ich ja gleich mal ein Layout machen :)
Gruß
Dirk
Zitat von: Dirk schrieb am Fr, 09 August 2013 20:56Da müsste ich ja gleich mal ein Layout machen :)
Mach mal...
Ein Arduino Shield mit
- Footprints für die beiden möglichen Homematic Sendemodule
- für Deinen Luftdrucksensor
- für ein EEPROM
- für 3-polige Header zum Aufstecken für weitere Senosren an die verbleibenden Analogeingaänge
ZitatFootprints für die beiden möglichen Homematic Sendemodule
zwei? hab ich was verpasst?
Ich kenne nur das TRX01. Oder meinst du das China-Teil?
ZitatEin Arduino Shield mit
Ihh. Irgendwie hab ich bisher ne Abneigung gegen die Arduinos. Aber für die Freunde des Arduino mach ich auch eine Arduino-Version.
Zitatfür ein EEPROM
DIL oder TSSOP-8?
Wieviel kb belegt der Code denn aktuell im AVR?
Der nicht-Arduino-Version würde ich auch den USART nach aussen führen damit man darüber ggf. einfach die Firmware tauschen kann, ohne einen eigenen eigenen Brenner zu haben.
Zitat von: Dirk schrieb am Fr, 09 August 2013 21:24ZitatFootprints für die beiden möglichen Homematic Sendemodule
zwei? hab ich was verpasst?
In den Homematic Geräten gibt es zwei verschiedene Sendemodule.
- kurz, breit und einreihige Stiftleiste im 2.0mm Raster
- lang, schmal und zweireihige (2x4) Stiftleiste im 2.54mm Raster
(https://github.com/ccier/openhm/wiki/images/trx868_bot.png)
Quelle und Beschreibung:
https://github.com/ccier/openhm/wiki/Trx868Natürlich sind die Pinbelegungen bei beiden auch noch anders.
Ich hatte hier heute ein zweireihiges, drum hat das prima auf ein Prototype-Shield gepaßt
(http://up.picr.de/15442607cn.jpg)
Achso, die beiden.
Ja. Jetzt müsste man die Dinger nur noch einzeln bekommen. Jedesmal einen Fensterkontakt dafür schlachten finde ich bissl schade. Auch wenn das nur der Bausatz ist.
Obwohl in das Gehäuse könnte man vielleicht gleich einen Sensor einbauen.
Kannst du mal schauen wie Groß der Code als Hexfile aktuell ist. Würde mich mal interessieren ob ein Atmega 32 ausreicht.
Aktuell sind wir bei 6k. Das sagt aber noch gar nichts. Es fehlt noch jede menge. Pairen, register handling, peeren....
Ich habe mir jetzt die panstamps bestellt. Ist ohne basteln die wirtschaftlichste alternative. Avr 328 + cc1100 mit beschaltung für 16 euro. Das billigste modul kommt aus einem max! fensterkontakt bausatz und kostet 14 euro.
Billiger wird es nur, wenn jemand eine platine entwirft auf die der cc1100 kommt. Allerdings wird es nur in grossen stückzahlen billiger.
Ach ja, ich finde die arduino mini pro schöner als den uno ::)
Zitat von: martinp876 schrieb am Mi, 07 August 2013 22:34Fertige Anlernmessage:
nn A200 FF0001 000000 10 8001 50533030303030303031 010101
Hallo Martin,
das habe ich gerade getestet
$19 $00 $A2 $00 $FF $00 $01 $00 $00 $00 $10 $80 $01 $50 $53 $30 $30 $30 $30 $30 $30 $30 $31 $01 $01 $01 s und hier sind die Ergebnisse.
1. auf fhem Seite::
2013.08.09 22:04:08.063 1: HMLAN_Parse: HMUSB R:EFF0001 stat:0000 t:0992485E d:FF r:FFBF m:00 A200 FF0001 000000 10800150533030303030303031010101
2013.08.09 22:04:08.138 1: HMLAN_Send: HMUSB I:+FF0001,00,00,
2013.08.09 22:04:08.145 1: HMLAN_Send: HMUSB S:S64ADD490 stat: 00 t:00000000 d:01 r:64ADD490 m:06 A001 127000 FF0001 00050000000000
2013.08.09 22:04:08.415 1: HMLAN_Parse: HMUSB R:EFF0001 stat:0000 t:09924994 d:FF r:FFBF m:00 A200 FF0001 000000 10800150533030303030303031010101
2013.08.09 22:04:08.767 1: HMLAN_Parse: HMUSB R:R64ADD490 stat:0008 t:00000000 d:FF r:7FFF m:06 A001 127000 FF0001 00050000000000
2013.08.09 22:04:08.769 1: HMLAN_Parse: HMUSB no ACK from Device
2. auf Arduino Seite
s: 19 00 A2 00 FF 00 01 00 00 00 10 80 01 50 53 30 30 30 30 30 30 30 31 01 01 01 (l:26)
<- 00 A2 00 FF 00 01 00 00 00 10 80 01 50 53 30 30 30 30 30 30 30 31 01 01 01 (l:25)(174994)
<- 00 A2 00 FF 00 01 00 00 00 10 80 01 50 53 30 30 30 30 30 30 30 31 01 01 01 (l:25)(175150)
<- 00 A2 00 FF 00 01 00 00 00 10 80 01 50 53 30 30 30 30 30 30 30 31 01 01 01 (l:25)(175304)
no answer
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 A0 (l:16)(175370)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 00 (l:16)(175569)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 A0 (l:16)(179287)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 00 (l:16)(179487)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 A0 (l:16)(179687)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 00 (l:16)(182914)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 A0 (l:16)(183113)
-> 06 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 00 (l:16)(183313)
-> 07 A0 01 12 70 00 FF 00 01 00 08 02 01 0A 12 0B 70 0C A0 (l:19)(186438)
-> 07 A0 01 12 70 00 FF 00 01 00 08 02 01 0A 12 0B 70 0C 00 (l:19)(186638)
-> 07 A0 01 12 70 00 FF 00 01 00 08 02 01 0A 12 0B 70 0C A0 (l:19)(186838)
In fhem ist danach das neue device angelegt:
Internals:
CFGFN
DEF FF0001
EVENTS 1
HMUSB_MSGCNT 1
HMUSB_RAWMSG EFF0001,0000,09924994,FF,FFBF,00A200FF000100000010800150533030303030303031010101
HMUSB_RSSI -65
HMUSB_TIME 2013-08-09 22:04:08
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 1
NAME CUL_HM_ID_8001_FF0001
NR 2369
STATE MISSING ACK
TYPE CUL_HM
lastMsg No:00 - t:00 s:FF0001 d:000000 10800150533030303030303031010101
protLastRcv 2013-08-09 22:04:08
protResnd 6 last_at:2013-08-09 22:04:31
protResndFail 3 last_at:2013-08-09 22:04:36
protSnd 3 last_at:2013-08-09 22:04:29
protState CMDs_done_events:9
rssi_at_HMUSB avg:-65 min:-65 max:-65 lst:-65 cnt:1
Readings:
2013-08-09 22:04:36 state MISSING ACK
Helper:
burstEvtCnt 9
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -65
cnt 1
lst -65
max -65
min -65
Shadowreg:
Attributes:
expert 2_full
firmware 1.0
model unknown
peerIDs
room CUL_HM
serialNr PS00000001
subType
Sieht doch alles ganz prima aus. Fehlt eigentlich nur noch die Bestätigung vom Arduino.
-----
ZitatAktuell sind wir bei 6k. Das sagt aber noch gar nichts.
Das ist klar.
Schaut aber so aus, als sollte das in nen Atmega32 passen. Auf den aktuellen Panstamps ist ja auch nix grösseres drauf.
ZitatIch habe mir jetzt die panstamps bestellt.
Werde ich zum Experiementieren wohl auch mal machen. Die Dinger haben schon was. Ich habe schon einige eigene Anwendungen die aktuell noch per FS20-Protokoll gesteuert werden welche ich dann wohl umstellen werde.
ZitatBilliger wird es nur, wenn jemand eine Platine entwirft auf die der cc1100 kommt. Allerdings wird es nur in grossen stückzahlen billiger.
Oder wenn man selber lötet. Aber das währ nur ein kleiner Teil von uns :)
Oder wir bringen ELV dazu die Dinger auch einzeln zu verkaufen. Bei den FS20 Sender/Empfänger machen die es ja auch.
Zitat von: trilu schrieb am Fr, 09 August 2013 21:58Ach ja, ich finde die arduino mini pro schöner als den uno ::)
Mag sein, aber zum Basteln und Entwickeln finde ich die größeren Platinen praktischer, zumal ich schon jede Menge Bastel-Shields im Einsatz habe.
Das Schlachten eine Fensterkontaktbausatzes finde ich nicht so schlimm. Die 13,66 Euro ist mir der Spaß wert. Zumal man ja keine dutzende davon braucht.
Zitat von: Dirk schrieb am Fr, 09 August 2013 22:16Oder wir bringen ELV dazu die Dinger auch einzeln zu verkaufen.
Ich hab gestern schon dort angefragt, ob es die Funkmodule auch einzeln gibt. Mal sehen, was als Antwort kommt.
2013.08.09 23:01:06.617 1: HMLAN_Parse: HMUSB R:E1CCA12 stat:0000 t:09C671E5 d:FF r:FFBA m:92 8670 1CCA12 000000 00D03E
-> 92 86 70 1C CA 12 00 00 00 00 D0 87 (l:12)(226908)
Kann es sein, dass da noch irgendwas beim Dekodieren schiefgeht? Das letzte Byte ist unterschiedlich.
ok - der Fehler ist sytematisch: das letzte Byte einer empfangenen Message wird falsch (oder gar nicht) dekodiert
HMUSB R:E1D919A stat:0000 t:09D12AD2 d:FF r:FFBF m:62 A258 1D919A 1DA1A9 0000
-> 62 A2 58 1D 91 9A 1D A1 A9 00 47 (l:11)(208652)
HMUSB R:E1DA1A9 stat:0000 t:09D12B55 d:FF r:FFBD m:62 8202 1DA1A9 1D919A 010100003C
-> 62 82 02 1D A1 A9 1D 91 9A 01 01 00 00 00 (l:14)(208783)
Hi,
ihr seid schon ziemlich weit mit message senden, prima.
Wie Trilu schon gesagt hat, da ist noch jede Menge fleissarbeit für die "platform" zu tun.
commandstack handling, multiple channels, retry/ACK, registerdatenbank und Programmierung. All die lästigen Dinge, bei denen man kaum Fortschritt sehen wird.
Das Anlegen des Model hat funktioniert. Ich werden für diesen Code ein spielmodel anlegen, mit Registern und channels.
Ab Version 3657 (HMConfig) wird durch die Anlernmessage angelegt
Einen Switch (4 channels) bekommt man mit
$19 $00 $A2 $00 $FF $00 $01 $00 $00 $00 $10 $80 $01 $50 $53 $30 $30 $30 $30 $30 $30 $30 $31 $04 $01 $01 s
einen 4 channel TH sensor bekommt man mit:
$19 $00 $A2 $00 $FF $00 $01 $00 $00 $00 $10 $80 $02 $50 $53 $30 $30 $30 $30 $30 $30 $31 $32 $04 $01 $01 s
Gruss Martin
Zitat von: martinp876 schrieb am Sa, 10 August 2013 07:28einen 4 channel TH sensor bekommt man mit:
$19 $00 $A2 $00 $FF $00 $01 $00 $00 $00 $10 $80 $02 $50 $53 $30 $30 $30 $30 $30 $30 $31 $32 $04 $01 $01 s
Funktioniert:
Internals:
CFGFN
CHANGED
DEF FF0001
EVENTS 1
HMUSB_MSGCNT 2
HMUSB_RAWMSG EFF0001,0000,0C269772,FF,FFC1,00A200FF000100000010800250533030303030303132040101
HMUSB_RSSI -63
HMUSB_TIME 2013-08-10 10:05:24
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 2
NAME CUL_HM_PS_Th_Sens_FF0001
NR 375
STATE ???
TYPE CUL_HM
channel_01 CUL_HM_PS_Th_Sens_FF0001_Sen_01
channel_02 CUL_HM_PS_Th_Sens_FF0001_Sen_02
channel_03 CUL_HM_PS_Th_Sens_FF0001_Sen_03
channel_04 CUL_HM_PS_Th_Sens_FF0001_Sen_04
lastMsg No:00 - t:00 s:FF0001 d:000000 10800250533030303030303132040101
protLastRcv 2013-08-10 10:05:24
rssi_at_HMUSB avg:-63 min:-63 max:-63 lst:-63 cnt:2
Readings:
Helper:
mId 8002
rxType 1
Respwait:
Role:
dev 1
Rssi:
At_hmusb:
avg -63
cnt 2
lst -63
max -63
min -63
Attributes:
expert 2_full
firmware 1.0
model PS-Th-Sens
peerIDs
room CUL_HM
serialNr PS00000012
subType THSensor
webCmd getConfig
Internals:
CFGFN
DEF FF000101
NAME CUL_HM_PS_Th_Sens_FF0001_Sen_01
NR 377
STATE ???
TYPE CUL_HM
chanNo 01
device CUL_HM_PS_Th_Sens_FF0001
Readings:
Helper:
Role:
chn 1
Attributes:
expert
model PS-Th-Sens
peerIDs
room CUL_HM
$0C $00 $86 $70 $FF $00 $01 $00 $00 $00 $00 $E0 $3B
ergibt:
2013-08-10 12:25:16 CUL_HM CUL_HM_PS_Th_Sens_FF0001 temperature: 22.4
2013-08-10 12:25:16 CUL_HM CUL_HM_PS_Th_Sens_FF0001 humidity: 59
2013-08-10 12:25:16 CUL_HM CUL_HM_PS_Th_Sens_FF0001 T: 22.4 H: 59
Man könnte also schon Werte schicken, mit denen fhem was anfangen kann :)
@martinp876:
1. wie werden eigentlich Temperaturen über 25,5° übertragen?
2. wie werden Daten aus einem Channel übertragen anstatt aus dem Device?
Hi,
die temperatur ist 2Byte und Faktor 10. Also 20,7C ist 207.
Ist 2er komplement, also negative sind 32768 -temp.
Format ist
<nn><flag>70<src><dst><tttt><hh>
<tttt> ist die Temperatur
<hh> die Luftfeuchten (noch nicht für panstamp)
Problem beim THsensor und dieser Message ist (sehe ich gerade) dass kein Channel mitkommt. Waren sicher eine der ersten Devices und HM hatte noch keine Channels berücksichtigt. Geht also nur für 1-Kanal Devices.
=> für unser Konzept ist diese message also nicht geeignet.
dann gibt es noch messagetype 0x53, das sieht schon besser aus. Da muss ich beim WDS30_ot2 nachbessern. Aber diese message ist nutzbar und evtl auch geeignet. Aber hier muss ich nachbessern.
Ich bin aber die ~2Wochen nicht verfügbar sein.
Also vorläufig die "70" nehmen und daten aus dem Device holen. Alles andere kommt später.
Die messages zu bauen wird eine Kleinigkeit. Wichtig ist das Protokol.
Gruss Martin
Hi Martin,
ist das ganze eigentlich irgendwo dokumentiert, oder nur aus dem Code heraus zu lesen.
Gäbe es ein "Messagetype" den man z.B. den Luftdruck benutzen kann bzw. für andere eigene Werte?
Gruß
Dirk
Hi Martin,
ich bin gerade dabei die Sende und Empfangsroutine zu durchdenken.
Kannst du mir bitte die möglichen Messagetypes spezifizieren?
Message analysis
01 Message sequence counter
02 Bitfeld flags
03 Message type
04-06 SourceID
07-09 Destination ID, broadcast: 00 00 00
Genauer gesagt, Byte 3
00 - Pairing
40 - Event?
Vielen Dank!
Zitat von: martinp876 schrieb am Sa, 10 August 2013 18:22die temperatur ist 2Byte und Faktor 10.
Hallo Martin, wo kommt das zweite Byte her? In den Messages sehe ich nur ein Byte für die Temperatur und eines für die Feuchtigkeit.
Viele Grüße (und schönen Urlaub, wenn das die zwei Wochen sind)
Udo
Hallo,
ich habe mal einen Empfindlichkeitsverleich gemacht. Mit einem TRX01 und dem oben genannten China-Tranceiver.
TRX01 kommt am Testort (im Nachbarzimmer) auf etwa -50db,
Das China-Modul auf etwa -70db.
Wie erwartet schneided das schlechter ab, da dort die Antennenanpassung für 433Mhz vorgesehen ist.
Ich denke für ca. 4,30€ pro Modul kann man damit aber trotzdem was anfangen.
Die Module waren zum testen abwechselnd an einem HM-LC-SW1-BA-PCB angeschlossen.
Gruß
Dirk
Zitat von: trilu schrieb am Sa, 10 August 2013 20:38ich bin gerade dabei die Sende und Empfangsroutine zu durchdenken.
Hast Du Dir schon Gedanken über den Decodierfehler gemacht oder hängt das auch mit dem durchdenken zusammen?
VIele Grüße
Udo
Zitat von: Dirk schrieb am So, 11 August 2013 00:11Das China-Modul auf etwa -70db.
Wie erwartet schneided das schlechter ab, da dort die Antennenanpassung für 433Mhz vorgesehen ist.
Ich denke für ca. 4,30€ pro Modul kann man damit aber trotzdem was anfangen.
Reichweitenkrücken hab ich schon genügend hier - für mich kommt so eine (schlechte) Kompromißlösung nicht in Frage, egal wie billig sie wäre.
ZitatGäbe es ein "Messagetype" den man z.B. den Luftdruck benutzen kann bzw. für andere eigene Werte?
das liegt nicht am messagetype. Ein messagetype ist nicht ein-eindeutig, hängt immer auch nicht vom Device/mode/channel ab (oder könnte)
Die best passenden Message aktuell ist wohl
<nn><ff>53<ssssss><dddddd>00<c1><v1v1><c2><v2v2>
C1:v1v1 - ChannelNo mit einem Wert(2 Byte)
C2:v2v2 - ChannelNo mit einem Wert(2 Byte)
Die Auswertung ist an Model/channel gebunden. Für Panstamp können/sollen wir ein flexibles format vorsehen.
Das Format des Werts liegt nicht am messagetype
Das obige Format muss ich noch komplettieren!
Zitatwo kommt das zweite Byte her?
$0C $00 $86 $70 $FF $00 $01 $00 $00 $00 $00 $E0 $3B
--------ff mt ---src----- ----dst---- -temp-- hum
da sind sie dich
ZitatKannst du mir bitte die möglichen Messagetypes spezifizieren?
schwierig, hätte ich auch gerne. Eine message wird nicht nur durch messageType sondern auch durch subtype spezifiziert.
Schau einmal ans Ende von HMConfig, das gibt einen Überblick. Da es aber nicht operativ genutzt muss nicht alles 100% stimmen.
[quote title=betateilchen schrieb am So, 11 August 2013 01:11]
ZitatReichweitenkrücken hab ich schon genügend hier - für mich kommt so eine (schlechte) Kompromißlösung nicht in Frage, egal wie billig sie wäre.
Jetzt währ es nur noch interessant wie das Panstamp hier im Vergleich abschneidet. Nicht das das auch eine "Reichweitenkrücken" wird :)
[quote title=martinp876 schrieb am So, 11 August 2013 08:39]
Zitatdas liegt nicht am messagetype. Ein messagetype ist nicht ein-eindeutig, hängt immer auch nicht vom Device/mode/channel ab
Obwohl. der Messagetype sollte sollte doch eigentlich egal sein.
Das Format der Payload wird z.B. bei der CCU doch über die XML-Files definiert.
Hier sollten wir doch also für jedes eigene spezielle Gerät einen eigenen gültigen Messagetype definieren können.
Mit einer entsprechenden XML-Datei währen solche Module dann ggf. auch für reine CCU Benutzer interessant und zu benutzen. Oder übersehe ich hier was?
Gruß
Dirk
Zitatder Messagetype sollte sollte doch eigentlich egal sein.
Das Format der Payload wird z.B. bei der CCU doch über die XML-Files definiert.
Hier sollten wir doch also für jedes eigene spezielle Gerät einen eigenen gültigen Messagetype definieren können.
Mit einer entsprechenden XML-Datei währen solche Module dann ggf. auch für reine CCU Benutzer interessant und zu benutzen.
HM nutzt messagetypes in der gleichen Form, oft identisch. Anzufangen messages von der grünen Wiese zu definieren werde ich nicht machen. Es gibt einige allgemeine Auswertungen - und die sollten mehr, nicht weniger werden.
Möglich, dass wie eine neue message addieren, wenn notwendig. Bis dahin müssen erst die Standards implementiert werden: Register/Peering...
HM macht das auch nicht für jeden messagetype separat.
Ich werden kein XML file für eine CCU schreiben - da fehlen mir zu viele Infos. Selbstverständlich kann es jemand probieren. In den XML files die ich kenne fehlen etliche Infos - oder sind in einer Form kodiert die ich nicht blicke.
@betateilchen
im Anhang ein file, das die Werte auf die Channels verteilen soll (message 53 siehe oben)
Gruss Martin
Nachtrag:ACHTUNG: die erste Datei hatte einen Fehler. Diese sollte besser sein
Hi Martin,
vielleicht habe ich mich falsch ausgedrückt mit dem MessageType.
Ich brauche irgendwas mit dem ich die Messages, die ich empfange, unterscheiden kann und in die entsprechenden Routinen zur Beantwortung oder Aktion verzweigen kann.
Nehmen wir als Beispiel das Pairing:
Ich sende einen Pairing Request raus, der wird mit einer Message vom Master beantwortet. Wie sehe ich in der Antwort was das für eine Message ist?
Oder, der Master schickt mir eine Message zum Abfragen der Register - an was erkenne ich, dass es ein Request der Register ist?
Das was mir in den Log's bisher aufgefallen ist, Byte 2 & 3 sind die interessanten:
l> AF A2 00 1F A6 5C 63 19 63 11 00 A9 4B 45 51 30 33 31 38 38 31 30 40 06 00 A2 (l:26)(12255)
A2: Message, ACK required, Message to Master
00: Pairing request
l> AF 80 02 63 19 63 1F A6 5C 91 (l:10)(12363)
80: Message
02: ACK in pairing?
l> 32 A0 01 63 19 63 1F A6 5C 00 05 00 00 00 00 90 (l:16)(13832)
A0: Message, ACK required
01: Config, send details?
l> 32 80 02 1F A6 5C 63 19 63 80 (l:10)(13950)
80: Message
02: ACK in pairing?
Falls ich völlig daneben liege ist es auch ok, aber du verstehst mein Problem? Ich brauche im Moment eine Idee wie ich die verschiedenen Nachrichten automatisiert in Routinen verzweigen kann...
Viele Grüße
Horst
Zitat von: trilu schrieb am So, 11 August 2013 10:23Ich brauche im Moment eine Idee wie ich die verschiedenen Nachrichten automatisiert in Routinen verzweigen kann...
Hallo Horst,
das sollte nicht allzu schwierig werden. Aber hast Du das Deocdierproblem bei eingehenden Messages inzwischen gelöst?
Viele Grüße
Udo
mir war nicht bewusst das ich ein decodier problem habe :-)
habs aber eben gesehen an was es lag, eindeutig ein dummer kleiner fehler im kopieren der daten
modul asksin.cpp, routine uint8_t cc1100_recvDone() {
memcpy(&recv_buf, cc1100_buf, cc1100_buf[0]);
gehört geändert nach
memcpy(&recv_buf, cc1100_buf, cc1100_buf[0]+1);
falls ihr so fehler findet wäre es klasse wenn ihr ein genaues fehlerbild und etwas zum testen mit posten könntet.
ich bin in fhem in keinster weise fit!
Zitat von: trilu schrieb am So, 11 August 2013 12:15falls ihr so fehler findet wäre es klasse wenn ihr ein genaues fehlerbild und etwas zum testen mit posten könntet.
ich bin in fhem in keinster weise fit!
Nur am Rande bemerkt: Ich
hatte hier im Thread schon dreimal auf das Problem hingewiesen und das Problem auch am Freitagabend mit Beispielen belegt (http://www.tierkommunikation-forum.com/images/smilies/zwinker.gif)
Ich hatte auch schon versucht, den Fehler zu finden, aber ich habe an der falschen Stelle gesucht (direkt in der decoding-Routine)
Rückmeldung: Das Dekodieren funktioniert nach der Änderung jetzt korrekt. Die Messages von HMLAN und Arduino sind identisch
das ist schön - aber ich brauche immer noch die message typen :-)
Und ich wünsche mir einen 6-kanaligen HM-Gerätetyp, mit dem man einfach die Werte der sechs vorhandenen AD-Wandler an fhem übertragen kann. Das könnte nämlich schon völlig problemlos mit dem aktuellen Softwarestand funktionieren, wenn man die Message einfach an broadcast schickt. Man muss ja nicht alles pairen, wenn man einfach nur ein paar Messwerte haben möchte. *lach*
Natürlich muss das Protokoll möglichst komplett implementiert werden. Hauptproblem dabei dürfte wohl sein, dass vieles "trial and error" sein könnte.
Aber ich freue mich auch schon über Teilerfolge.
Hallo Horst,
Zitat von: trilu schrieb am So, 11 August 2013 17:35das ist schön - aber ich brauche immer noch die message typen :-)
Vielleicht solltest Du einfach auch mal die Antworten lesen, die Dir hier im Thread gegeben werden, bevor Du immer wieder die gleichen Fragen stellst *lach*
Zitat von: martinp876 schrieb am So, 11 August 2013 08:39schwierig, hätte ich auch gerne. Eine message wird nicht nur durch messageType sondern auch durch subtype spezifiziert.
Schau einmal ans Ende von HMConfig, das gibt einen Überblick. Da es aber nicht operativ genutzt muss nicht alles 100% stimmen.
Und "am Ende von HMConfig" steht:
my %culHmBits = (
"00" => { txt => "DEVICE_INFO", params => {
FIRMWARE => '00,2',
TYPE => "02,4",
SERIALNO => '06,20,$val=pack("H*",$val)',
CLASS => "26,2",
PEER_CHANNEL_A => "28,2",
PEER_CHANNEL_B => "30,2",
UNKNOWN => "32,2", }},
"01;p11=01" => { txt => "CONFIG_PEER_ADD", params => {
CHANNEL => "00,2",
PEER_ADDRESS => "04,6",
PEER_CHANNEL_A => "10,2",
PEER_CHANNEL_B => "12,2", }},
"01;p11=02" => { txt => "CONFIG_PEER_REMOVE", params => {
CHANNEL => "00,2",
PEER_ADDRESS => '04,6,$val=CUL_HM_id2Name($val)',
PEER_CHANNEL_A => "10,2",
PEER_CHANNEL_B => "12,2", } },
"01;p11=03" => { txt => "CONFIG_PEER_LIST_REQ", params => {
CHANNEL => "0,2", },},
"01;p11=04" => { txt => "CONFIG_PARAM_REQ", params => {
CHANNEL => "00,2",
PEER_ADDRESS => "04,6",
PEER_CHANNEL => "10,2",
PARAM_LIST => "12,2", },},
"01;p11=05" => { txt => "CONFIG_START", params => {
CHANNEL => "00,2",
PEER_ADDRESS => "04,6",
PEER_CHANNEL => "10,2",
PARAM_LIST => "12,2", } },
"01;p11=06" => { txt => "CONFIG_END", params => {
CHANNEL => "0,2", } },
"01;p11=08" => { txt => "CONFIG_WRITE_INDEX", params => {
CHANNEL => "0,2",
DATA => '4,,$val =~ s/(..)(..)/ $1:$2/g', } },
"01;p11=09" => { txt => "CONFIG_SERIAL_REQ", params => { } },
"01;p11=0A" => { txt => "PAIR_SERIAL", params => {
SERIALNO => '04,,$val=pack("H*",$val)', } },
"01;p11=0E" => { txt => "CONFIG_STATUS_REQUEST", params => {
CHANNEL => "0,2", } },
"02;p01=00" => { txt => "ACK"},
"02;p01=01" => { txt => "ACK_STATUS", params => {
CHANNEL => "02,2",
STATUS => "04,2",
DOWN => '06,02,$val=(hex($val)&0x20)?1:0',
UP => '06,02,$val=(hex($val)&0x10)?1:0',
LOWBAT => '06,02,$val=(hex($val)&0x80)?1:0',
RSSI => '08,02,$val=(-1)*(hex($val))', }},
"02;p01=02" => { txt => "ACK2"}, # smokeDetector pairing only?
"02;p01=04" => { txt => "ACK-proc", params => {# connected to AES??
Para1 => "02,4",
Para2 => "06,4",
Para3 => "10,4",
Para4 => "14,2",}}, # remote?
"02;p01=80" => { txt => "NACK"},
"02;p01=84" => { txt => "NACK_TARGET_INVALID"},
"02" => { txt => "ACK/NACK_UNKNOWN "},
"02" => { txt => "Request AES", params => { #todo check data
DATA => "0," } },
"03" => { txt => "AES reply", params => { # send 'old' AES key to actor
DATA => "0," } },
"04;p01=01" => { txt => "To-HMLan:send AES code", params => { # FHEM req HMLAN to send AES key to aktor ??
CHANNEL => "00,2",
TYPE => "02,2" } }, #00: old key? 01: new key?
"04" => { txt => "To-Actor:send AES key" , params => { # HMLAN sends AES key to actor ??
CODE => "00" } },
"10;p01=00" => { txt => "INFO_SERIAL", params => {
SERIALNO => '02,20,$val=pack("H*",$val)'},},
"10;p01=01" => { txt => "INFO_PEER_LIST", params => {
PEER1 => '02,8,$val=CUL_HM_id2Name($val)',
PEER2 => '10,8,$val=CUL_HM_id2Name($val)',
PEER3 => '18,8,$val=CUL_HM_id2Name($val)',
PEER4 => '26,8,$val=CUL_HM_id2Name($val)'},},
"10;p01=02" => { txt => "INFO_PARAM_RESPONSE_PAIRS", params => {
DATA => "2,", },},
"10;p01=03" => { txt => "INFO_PARAM_RESPONSE_SEQ", params => {
OFFSET => "2,2",
DATA => "4,", },},
"10;p01=04" => { txt => "INFO_PARAMETER_CHANGE", params => {
CHANNEL => "2,2",
PEER => '4,8,$val=CUL_HM_id2Name($val)',
PARAM_LIST => "12,2",
DATA => '14,,$val =~ s/(..)(..)/ $1:$2/g', } },
"10;p01=06" => { txt => "INFO_ACTUATOR_STATUS", params => {
CHANNEL => "2,2",
STATUS => '4,2',
UNKNOWN => "6,2",
RSSI => '08,02,$val=(-1)*(hex($val))' } },
"11;p01=02" => { txt => "SET" , params => {
CHANNEL => "02,2",
VALUE => "04,2",
RAMPTIME => '06,4,$val=CUL_HM_decodeTime16($val)',
DURATION => '10,4,$val=CUL_HM_decodeTime16($val)', } },
"11;p01=03" => { txt => "STOP_change" , params => {
CHANNEL => "02,2"} },
"11;p02=0400" => { txt => "RESET" },
"11;p01=80" => { txt => "LED" , params => {
CHANNEL => "02,2",
COLOR => "04,2", } },
"11;p02=8100" => { txt => "LEDall" , params => {
Led1To16 => '04,8,$val= join(":",sprintf("%b",hex($val))=~ /(.{2})/g)',
} },
"11;p01=81" => { txt => "LEVEL" , params => {
CHANNEL => "02,2",
TIME => '04,2,$val=hex($val)',
SPEED => '06,2,$val=hex($val)',
} },
"11;p01=82" => { txt => "Sleepmode" , params => {#only LED16?
CHANNEL => "02,2",
MODE => '04,2,$val=hex($val)',
} },
"12" => { txt => "HAVE_DATA"},
"3E" => { txt => "SWITCH" , params => {
DST => "00,6",
UNKNOWN => "06,2",
CHANNEL => "08,2",
COUNTER => "10,2", } },
"3F" => { txt => "TimeStamp" , params => {
UNKNOWN => "00,4",
TIME => "04,2", } },
"40" => { txt => "REMOTE" , params => {
BUTTON => '00,2,$val=(hex($val)&0x3F)',
LONG => '00,2,$val=(hex($val)&0x40)?1:0',
LOWBAT => '00,2,$val=(hex($val)&0x80)?1:0',
COUNTER => "02,2", } },
"41" => { txt => "Sensor_event", params => {
BUTTON => '00,2,$val=(hex($val)&0x3F)',
LONG => '00,2,$val=(hex($val)&0x40)?1:0',
LOWBAT => '00,2,$val=(hex($val)&0x80)?1:0',
VALUE => '02,2,$val=(hex($val))',
NEXT => '04,2,$val=(hex($val))',} },
"53" => { txt => "SensorData" , params => {
CMD => "00,2",
Fld1=> "02,2",
Val1=> '04,4,$val=(hex($val))',
Fld2=> "08,2",
Val2=> '10,4,$val=(hex($val))',
Fld3=> "14,2",
Val3=> '16,4,$val=(hex($val))',
Fld4=> "20,2",
Val4=> '24,4,$val=(hex($val))'} },
"58" => { txt => "ClimateEvent", params => {
CMD => "00,2",
ValvePos => '02,2,$val=(hex($val))', } },
"70" => { txt => "WeatherEvent", params => {
TEMP => '00,4,$val=((hex($val)&0x3FFF)/10)*((hex($val)&0x4000)?-1:1)',
HUM => '04,2,$val=(hex($val))', } },
);das könnte ja durchaus schon weiterhelfen.
Viele Grüße
Udo
-----
jau, das sieht gut aus - vielleicht sollte ich doch öfter mal lesen :-)
danke!
falls es Dir hilft:
# 4-Tasten-Fernbedienung
# Button 2 short
-> 00 A6 40 21 23 FC 12 70 00 02 00 (l:11)(11421)
-> 01 A2 40 21 23 FC 12 70 00 02 00 (l:11)(11672)
-> 02 A2 40 21 23 FC 12 70 00 02 00 (l:11)(11923)
# Button 1 short
-> 03 A6 40 21 23 FC 12 70 00 01 00 (l:11)(130043)
-> 04 A2 40 21 23 FC 12 70 00 01 00 (l:11)(130294)
-> 05 A2 40 21 23 FC 12 70 00 01 00 (l:11)(130545)
# Button 4 short
-> 06 A6 40 21 23 FC 12 70 00 04 00 (l:11)(135548)
-> 07 A2 40 21 23 FC 12 70 00 04 00 (l:11)(135798)
-> 08 A2 40 21 23 FC 12 70 00 04 00 (l:11)(136049)
# Button 3 short
-> 09 A6 40 21 23 FC 12 70 00 03 00 (l:11)(137201)
-> 0A A2 40 21 23 FC 12 70 00 03 00 (l:11)(137452)
-> 0B A2 40 21 23 FC 12 70 00 03 00 (l:11)(137703)
# Button 2 long
-> 0C 84 40 21 23 FC 12 70 00 42 01 (l:11)(170140)
-> 0D 84 40 21 23 FC 12 70 00 42 01 (l:11)(170391)
-> 0E 84 40 21 23 FC 12 70 00 42 01 (l:11)(170642)
-> 0F 84 40 21 23 FC 12 70 00 42 01 (l:11)(170893)
-> 10 A2 40 21 23 FC 12 70 00 42 01 (l:11)(171144)
-> 11 A2 40 21 23 FC 12 70 00 42 01 (l:11)(171395)
-> 12 A2 40 21 23 FC 12 70 00 42 01 (l:11)(171645)
# Button 1 long
-> 13 84 40 21 23 FC 12 70 00 41 01 (l:11)(178594)
-> 14 84 40 21 23 FC 12 70 00 41 01 (l:11)(178845)
-> 15 84 40 21 23 FC 12 70 00 41 01 (l:11)(179096)
-> 16 84 40 21 23 FC 12 70 00 41 01 (l:11)(179347)
-> 17 A2 40 21 23 FC 12 70 00 41 01 (l:11)(179598)
-> 18 A2 40 21 23 FC 12 70 00 41 01 (l:11)(179849)
-> 19 A2 40 21 23 FC 12 70 00 41 01 (l:11)(180100)
Zitat von: martinp876 schrieb am Mi, 07 August 2013 22:341) Seriennummer: Jedes HM device hat eine 10-stellige Seriennummer
Bedeutung: für den Betrieb unwichtig.
Kann man eine Solche Nummer aus dem Device ableiten?
Vorgabe für den Test "PS00000001" = 50533030303030303031
Offen: wie soll die Nummer generiert werden? Fixer Wert?
Vorschlag: wir binden die TrueRandom Library mit ein (vermutlich gibt es im Laufe der Entwicklung und Anwendungsszenarien noch andere Stellen, an denen echte Zufallszahlen gebraucht werden) und lassen uns daraus einmalig eine Seriennummer generieren, die ins EEPROM kommt. Falls beim Starten der Hardware im EEPROM eine S/N gefunden wird, wird sie verwendet.
Ich könnte mir durchaus auch vorstellen, diese Initialisierung, auch mit den anderen Werten wie HMID FW usw. in einen eigenen Sketch auszulagern, das dies ja nur ein einziges Mal gebraucht wird.
wenn der platz im sketch nicht reicht das erzeugen dieser serien nummern im standard sketch mit unter zu bringen würde ich es komplett ausserhalb machen (z.b. in fhem) und mit einem speziellen init kommando übertragen. extra einen sketch drauf zu brennen um die werte zu erzeugen ist eher unpraktisch und sollte nur der ausweg sein wenn noch nicht mal mehr platz für das empfangen und speichern ist.
gruss
andre
auch eine Idee, dann könnte man die gesamte Grundkonfiguration auslagern. Warten wir mal ab, ob am Ende der Entwicklung noch Platz im Sketch bleibt.
sub createHmFields(){
use UUID::Tiny;
my $hmUuid = uc(create_UUID_as_string());
$hmUuid =~ s/-//g;
return(substr($hmUuid,0,8)."/".substr($hmUuid,length($hmUuid)-6,6));
}
könnte z.B. eine 8-stellige Seriennummer und eine 6-stellige HMID liefern.
52D89F86/82384A
Macht euch doch wegen der Seriennummer keinen Kopf. Im Moment ist sie als Variable im Flash und kann vor dem kompileren geändert werden.
Wie wir das später lösen können wir ja dann immer noch überlegen.
Die HMID und Seriennummer könnte man auch über die serielle Konsole setzen. Hat dann aber den Nachteil das sie ins eeprom muss und lt. Martin ist der Eeprom mehr als knapp.
Mit dem Pairing bin ich auch einen guten Schritt weiter. Muss nur noch die Zentrale ID irgendwo merken und dann sollte Pairing klappen.
@betateilchen - danke noch einmal für den Hinweis mit den Messagetypen, die Auflistung ist Gold Wert.
Was ich noch nicht verstanden habe ist das Register Handling...
Zitat von: trilu schrieb am Mo, 12 August 2013 20:03Macht euch doch wegen der Seriennummer keinen Kopf.
Tu ich nicht. Ich kam da nur drauf, weil ich heute zufällig dienstlich mit einem ähnlichen Thema zu tun hatte.
Bestimmte Geräteparameter werden immer ins EEPROM müssen, dazu zähle ich die S/N, die HMID und die anderen schon von Martin hier genannten Werte.
so, mal wieder was zum testen - pairing funzt soweit, speichert nur noch nichts...
ACK handling für gesendete strings sollte funktionieren. strings ohne ack request werden nur einmal gesendet,
strings mit ack request werden 3 x gesendet ausser es kommt ein ack zurück...
send routine umgebaut, so dass sie einen fortlaufenden message zähler benutzt...
ack handling für empfangene strings im config mode (also pairing ) funzt auch
viel spass beim testen
pairing von Arduino an fhem oder pairing von HM-Komponenten mit dem Arduino?
edit: ok - Frage gestrichen *g*
<- 00 84 00 FF 00 01 00 00 00 0A 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01 (l:26) <- SE (57093)
-> 13 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 00 (l:16)(57266)
start config mode
<- 13 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (57394)
-> 14 A0 01 12 70 00 FF 00 01 00 08 02 01 0A 12 0B 70 0C 00 (l:19)(57696)
config write index, channel: 02,01
needs to be written
<- 14 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (57714)
-> 15 A0 01 12 70 00 FF 00 01 00 06 (l:11)(58012)
config end
<- 15 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (58018)
-> NA (58319)
Auch das mit den Registern hat Martin hier im Thread schon recht verständlich erklärt:
Link (http://forum.fhem.de/index.php?topic=14140.0)
D) Lesen von Registern durch die Zentrale
Register lesen darf nur die eingetragene Zentrale.
Es wird IMMER eine komplette Registerbank gelesen. Einzelne Register können nicht gelesen werden.
Message zu Lesen:
<no>A001<src><dst><chan>04<peer><list>
no: Message counter
src,dst: Source und Destination HM ID. Jeweils 3 Byte in Uppercase HEX, also je 6 Byte Ascii
chan: Nummer des Kanals, der gelesen werden soll
peer: PeerID ist 4 Byte lang: 3 Byte HMId des peers plus 1 Byte des Peer Channels
list: Nummer der zu lesenden Liste
Beispiele
nn A001 1743BF 1A0A02 00 04 00000000 00 # lesen List0: channel, peer und list ist "0"
nn A001 1743BF 1A0A02 01 04 00000000 01 # lesen List1 den Channel 1: peer ist "0"
nn A001 1743BF 1A0A02 05 04 00000000 01 # lesen List1 den Channel 5: peer ist "0"
nn A001 1743BF 1A0A02 02 04 12345604 03 # lesen List3 den Channel 2: peer ist 123456, chan 04
@betateilchen
In deinem Log ist ein -> NA (58319)
Kann es sein, dass du FHEM nicht im pairing mode hattest?
Du scheinst den Thread ja auswendig zu kennen :-)
Aber in diesem Fall hilft das nicht ganz so viel - ich würde zuerst gerne die Struktur von Channels und Registern verstehen.
Welche Funktion braucht ein Register, was ist der Inhalt von Registern. Oder muss ich die Adressierung der Zentrale verwenden?
Was muss in den Channels abgelegt werden, usw.
Hi trillu,
hast du schon mal in die XML-Files der CCU geschaut?
Hier sind die Register für jedes Device spezifiziert.
Obwohl ich hier auch noch nicht alles verstehe, kann man das hier glaube ich ganz gut die Registerzuordnung herrauslesen.
Gruß
Dirk
nein, habe ich nicht, wo finde ich die?
Kannst du die irgendwo hoch laden?
Zitat von: trilu schrieb am Mo, 12 August 2013 21:02In deinem Log ist ein -> NA (58319)
Kann es sein, dass du FHEM nicht im pairing mode hattest?
fhem war in pairforseconds 300 und hat gelauert...
Zitat von: trilu schrieb am Mo, 12 August 2013 21:02Aber in diesem Fall hilft das nicht ganz so viel - ich würde zuerst gerne die Struktur von Channels und Registern verstehen.
Welche Funktion braucht ein Register, was ist der Inhalt von Registern.
Ich versuchs mal mit meinen Worten zu erklären (kennst Du eigentlich das Homematic Grundlagendokument von Martin schon - da steht vieles drin)
Jedes Homematic Gerät besteht aus einem "device" und mindestens einem "Channel"
Beispiel: Fernbedienung mit HMID 123456
Channel0 hat die ID 12345600
Channel1 hat die ID 12345601
...
Channel4 hat die ID 12345604
Die Channel braucht man, um irgendwas mit dem HM-Gerät machen zu können. Der Channel1 der Fernbedienung entspricht dem Button1 Und
nur Channel können gepeert werden, also der Button1 der Fernbedienung wird mit dem Channel1 eines Schalters gepeert. Das funktioniert über peerChan.
Für das Device gibt es eine List0 - dort steht zB. das Pairing zwischen HM-Gerät und Zentrale drin.
Für jeden Channel gibt es (zumindest) eine List1
Ich hoffe, ich hab nicht zuviel Unsinn erzählt, und es ist auch bei weitem noch nicht vollständig. Aber das ist das Wichtigste, um vielleicht das Prinzip zu durchschauen.
-----
Zitat von: trilu schrieb am Mo, 12 August 2013 21:15nein, habe ich nicht, wo finde ich die?
Kannst du die irgendwo hoch laden?
bei eq3 in den Downloads vermutlich. Bisschen was solltest Du schon selbst machen ;)
-----
Hier z.B. http://www.eq-3.de/Downloads/Software/HM-CCU1-Firmware_Updates/1.509/hm-ccu-1509.zip (//www.eq-3.de/Downloads/Software/HM-CCU1-Firmware_Updates/1.509/hm-ccu-1509.zip)
Darin das *.img in *.tgz umbenennen und entpacken.
Wieder darin das root_fs.tar.gz entpacken.
Die Files sind dann unter /firmware/rftypes
Gruß
Dirk
Zitat von: trilu schrieb am Mo, 12 August 2013 21:02In deinem Log ist ein -> NA (58319)
Kann es sein, dass du FHEM nicht im pairing mode hattest?
Jetzt besser?
<- 00 84 00 FF 00 01 00 00 00 0A 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01 (l:26) <- SE (5551)
-> 18 A0 01 12 70 00 FF 00 01 00 05 00 00 00 00 00 (l:16)(5793)
start config mode
<- 18 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (5852)
-> 19 A0 01 12 70 00 FF 00 01 00 08 02 01 0A 12 0B 70 0C 00 (l:19)(6160)
config write index, channel: 02,01
needs to be written
<- 19 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (6178)
-> 1A A0 01 12 70 00 FF 00 01 00 06 (l:11)(6475)
config end
<- 1A 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (6481)
-> 1A A0 01 12 70 00 FF 00 01 00 06 (l:11)(6676)
config end
<- 1A 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (6782)
-> 1A A0 01 12 70 00 FF 00 01 00 06 (l:11)(6877)
config end
<- 1A 80 02 FF 00 01 12 70 00 00 (l:10) <- SE (7083)
Das Device war aus vorherigen Tests schon angelegt, vermutlich war das das Problem.
Als nächstes wäre dann set <name> getConfig abzusetzen, das vom Arduino zu beantworten wäre.
Ja, jetzt ist besser :-)
Das Problem bei so einem Timeout ist, das er echt schwer zu finden ist. Ich logge ja nicht mehr die Kommunikation, sondern bin jetzt ein Teil davon.
@Dirk - Danke für den Link, ich werde mir morgen mal besagte config files zu gemühte führen.
ich hab jetzt nen zweiten Arduino zur Funküberwachung aufgebaut.
-----
Meine panstamps sind auch schon bestellt, aber dauern anscheinend noch ein wenig...
Hast du eine Idee, wie ich die Library möglichst flexibel und konfigurierbar bekomme?
Ich habe schon an structs gedacht, in denen die Channels spezifiziert werden können. Also sowas wie
Anzahl Channels
Channel(0), Ein oder Ausgabe oder Sensor, Status send interval, etc
Hi Zusammen
Wie sind die Pins am langen TRX868 Board angeordnet (PIN1->PIN8)? Wo ist Pin1 ?
Gruss Peter
Nimm ein Widerstandsmeßgerät und suche den Massepin (messen gegen das Abschirmblech), Pin 1 ist der daneben.
Hallo
Wenn ich das erste Bild als Bezugspunkt nehme,
https://github.com/ccier/openhm/wiki/Trx868 (//github.com/ccier/openhm/wiki/Trx868)
ist mein Masseport links unten.
Das kann dann aber nicht Pin7 sein, oder ?
Gruss Peter
Beim langen schmalen Sendemodul liegt Masse an Pin 2. Steht doch klipp und klar in der Tabelle auf der von Dir verlinkten Seite? Bist Du Dir eigentlich sicher, welches Modul Du hast? einreihige Kontakte oder zwei Reihen?
Hi
Ich habe das gleiche 2×4 reihige Modul wie auf dem Bild.
Pin2 kann doch nicht unten links sein, oder ?
Gruss Peter
Das kommt drauf an, wo man an dem Teil "oben" und "unten" festlegt. Du kannst das Modul ja um 180° drehen, egal ob horizontal oder vertikal, dann hast Du den Pin "oben". Deshalb hatte ich eingangs darauf verzichtet, mit diesen Begriffen anzufangen.
Wenn Du Pin2 gefunden hast, hast Du die Reihe mit den "geraden" Pin-Nummern. Die ungeraden liegen direkt daneben. So einfach ist es.
Das heisst dann also:
Pin: 2 4 6 8
Pin: 1 3 5 7
Teste es mal
Gruss und danke Peter
genau so ist das Schema :)
Scheint mal zu funken :-)
start AskSin sketch
SPI_init done
cc1100_init: 123.....................4 done
Available commands:
b,b,b i - set device ID (3 bytes)
b[0],b[n] s - send a string, b[0] is length (50 bytes max)
p - start pairing with master
n/a - load configuration from EEPROM
n/a - write configuration to EEPROM
$nn for HEX input (e.g. $AB,$AC )
b> 19 86 70 1C C8 D1 00 00 00 00 A2 42 (l:12)(67206)
b> AD 86 70 1C C9 0F 00 00 00 00 F8 41 (l:12)(94144)
Hi Zusammen,
bin evtl. nicht auf dem letzten Stand, habe alles nur überflogen.
Bitte beachten zur Channel Diskussion:
Ein Gerät hat immer ein Device und min einen Channel. Die Zählung der Channel beginnt bei "01". "00" ist kein channel, wird verwendet wenn man mit dem Device selbst "redet".
In C sollte man mit Strukturen arbeiten um register zu definieren. Etwa in der Form
struct List0{ /*device level*/
unsigned char [9]; /*chars 1 to 9 are not used*/
unsigned char Paired[3]; /*HMID central*/
};
struct List1Remote{ /*channel level for remote*/
unsigned char [3];
unsigned char longPress [1];
unsigned char [4];
unsigned char dblPress [1];
};
struct List4Remote{ /*channel level for remote*/
unsigned int expectAES :1; /*addr 1 msb*/
unsigned int :6;
unsigned int peerNeedsBurst :1; /*addr 1 lsb*/
unsigned char [1];
unsigned char myData [1]; /*addr 0x03*/
};
struct {
List0 l0;
List1Remote l1;
List4Remote l4[10]; /*allow 10 peers*/
} myRegs;
Das ist die raumgreifenden Variante. Leer-register sind nicht ausgeblendet.
habt ihr schon einen Ansatz beispielsweise das pairing zu machen?
Gruss Martin
Das Pairing funktioniert grundsätzlich, wird aber noch nicht gespeichert.
@betateilchen,
hattest du eigentlich mal ein Feedback von ELV bekommen wegen der TRX1 Module?
Gruß
Dirk
ZitatDas Pairing funktioniert grundsätzlich, wird aber noch nicht gespeichert.
Wenn ich es recht verstehe antwortet der PS auf die pairing message von FHEM und filtert die HMID heraus.
das Speichern und Nutzen der ID ist das eigentliche pairen. Und noch das Rücklesen der Register.
Habt ihr eine schon Idee zu Sequenznummer und HMID des PS?
Gruss Martin
Zitat von: Dirk schrieb am Di, 20 August 2013 16:19hattest du eigentlich mal ein Feedback von ELV bekommen wegen der TRX1 Module?
Ja...
ZitatDas Sende-/Empfangsmodul führen wir einzeln nicht in unserem Liefersortiment. Wir werden Ihnen in diesem Fall im Rahmen der Kulanz aus unserer Retourenware ein Sende-/Empfangsmodul kostenlos zusenden.
Wir hoffen, Ihnen hiermit geholfen zu haben.
Zitat von: martinp876 schrieb am Di, 20 August 2013 20:04Habt ihr eine schon Idee zu Sequenznummer und HMID des PS?
Falls Du mit Sequenznummer die Seriennummer meinst, dann blättere einfach mal ein Stück hier im Thread zurück. Dort hatte ich einen Vorschlag zu S/N und HMID gemacht und es wurde geantwortet dass man sich darum derzeit noch keine Gedanken machen müsse...
War ein paar Tage im Urlaub :-)))
Mal wieder ein kleines Update, hab die lib komplett überarbeitet, da ich mich nicht mehr wirklich zurecht gefunden habe...
Basiert jetzt auf einer Class. Schaut es euch einfach selbst an.
@martin - schön das du wieder da bist!
ZitatHabt ihr eine schon Idee zu Sequenznummer und HMID des PS?
Derzeit vergebe ich das im Flash. Wird also beim Programmieren gesetzt - also hier:
const unsigned char HM_settings[] PROGMEM = {
'P','S','0','0','0','0','0','0','0','1', // hm.C.serID[10] serial ID, needed for pairing
0x80,0x02, // hm.C.modID[2] model ID, describes HM hardware. we should use high values due to HM starts from 0
0x9F, // hm.C.subType[1] not needed for FHEM, it's something like a group ID
0x04,0x01,0x01, // hm.C.devInfo[3] describes device, not completely clear yet. includes amount of channels
0x3F,0xA6,0x5C, // hm.C.HMID[3] very important, must be unique. identifier for the device in the network
3, // hm.C.sendRetries how often a string should be send out until we get an answer
0xF4,0x01, // hm.C.timeOut needs two byte split; time out for ack handling
};Die HMID kann man auch per serieller Konsole ändern, wird aber derzeit nicht gespeichert.
Ich denke das sollte für den Anfang so gehen, komplett dynamisch wird der Sketch wohl nicht werden, weil schliesslich muss ja auch noch Funktionalität zu den Registern programmiert werden.
Pairen geht derzeit von:
<- 1A 00 84 00 3F A6 5C 00 00 00 0A 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01 (l:27) <- SE (3614) 1
-> 10 01 A0 01 63 19 63 3F A6 5C 00 05 00 00 00 00 00 (l:17)(4159)
start config mode
<- 0A 01 80 02 3F A6 5C 63 19 63 00 (l:11) <- SE (4171) 1
-> 13 02 A0 01 63 19 63 3F A6 5C 00 08 02 01 0A 63 0B 19 0C 63 (l:20)(5089)
new PairID: 63 19 63 (l:3)
<- 0A 02 80 02 3F A6 5C 63 19 63 00 (l:11) <- SE (5101) 1
-> 0B 03 A0 01 63 19 63 3F A6 5C 00 06 (l:12)(5750)
config end
<- 0A 03 80 02 3F A6 5C 63 19 63 00 (l:11) <- SE (5758) 1An den Registern bin ich gerade dran...
Eine Verständnisfrage dazu hätte ich - per 04 werden die Register einzeln abgefragt - also
00 für Device - mit einem Inhalt wie 02:01 0A:63 0B:19 0C:63
01 für Channel 01?
02 für Channel 02?
Ich bekomme das mit den Registern oder Channels noch nicht gebacken. Ist Register oder Channel die führende Struktur?
also sowas wie:
Device:
- Channel 00
- Channel 01
- Channel 02
Kanal 1
- Channel 00
- Channel 01
- Channel 02
usw.?
Zweite Frage, ich sehe in den Registern sowas als Inhalt
02:01 0A:63 0B:19 0C:63
30:06 32:50 34:4B 35:50 56:00 57:24 58:01 59:01 00:00
Sind das Adressen vor den Werten? 0A, 0B, 0C - Byte Adresse mit folgendem Inhalt 63 19 63 ?
Channel PEER Addr PEER Param List
l> 10 04 A0 01 63 19 63 1E 7A AD 01 04 00 00 00 00 01 (l:17)(131270)
Slave sendet param liste an Master
"10;p01=02" => { txt => "INFO_PARAM_RESPONSE_PAIRS", params => {
DATA => "2,", },},
RegL_01: 30:06 32:50 34:4B 35:50 56:00 57:24 58:01 59:01 00:00
l> 1A 04 A0 10 1E 7A AD 63 19 63 02 30 06 32 50 34 4B 35 50 56 00 57 24 58 01 59 01 (l:27)(131405)
Hi,
register:
kann man byteweise setzen
kann man nur in Blöcken abfragen, also eine komplette liste oder liste/peer
können in manchen devices 'lokal' geaendert werden - dann sendet das Device die Aenderung "einzeln" an die Zentrale (z.B. TC)
ein Registerblock hat einen Adressbereich von 1 bis 255. Nicht alle Addressen werden genutzt - es werden immer nur die genutzten gesendet.
hier ein Beispiel
01 04 1BCCB802 03 # anfrage der Zentrale: schicke Register Channel 1/Liste3/peer 1BCCB802
das Device entscheidet das format '03' also Blöcke zu verwenden
03 01 000000326400FF00FF011112680000 # Block ab addresse 01, also 01 bis 0x10
03 11 C80000000000000000000000FF6800 # Block ab addresse 01, also 01 bis 0x10
03 81 000000326400FF00FF211112680000 # Block ab addresse 01, also 01 bis 0x10
03 91 C80000000000000000000000046800 # Block ab addresse 01, also 01 bis 0x10
03 00 00 #Adresse 00 - das bedeutet "Ende der Sequenz" das muss immer am schluss stehen!
Alternativ könnte das device mit format "02" antworten:
00 04 00000000 00 # anfrage der Zentrale: schicke Register Channel 0/Liste0/peer 00000000
# channel 0 ist das Device, also kein channel. Bei list 0 gibt es keine peers,als wird peer aof 00000000 gesetzt
02 0281 0A17 0B43 0CBF 15FF # 02 ist das Format, die 4er gruppen ist jeweils Adresse/data
03 0000 # hier wurde format 03 zum Terminieren gewählt.
Alternativ könnte das Device auch
02 0281 0A17 0B43 0CBF 15FF 0000
senden. Die 0000 am Ende terminiert auch die Serie.
=> Register Sequenz wird IMMER mir addr:00 data:00 terminiert, format 02 oder03 ist hier bei egal
Gruss Martin
Wenn das in dem Beispiel wirklich 4 Mal "# Block ab addresse 01" heißt, verstehe ich die Logik nicht.
so langsam beginne ich zu verstehen wie die dinger funktionieren....
d.h. das device legt fest welche variablen es an welchen adressen hat, also von HM festgelegt.
nachdem der eeprom des avr 328 begrenzt ist, sollten wir uns eine generelle struktur überlegen. die variablen und damit verfügbaren adressen können wir ja dann als standard für eigenbau devices verwenden.
willst du dir mal gedanken machen wieviele register wir anlegen mit wieviel platz pro register. wir haben beim panstamp 512 byte zur verfügung.
L01 braucht adresse 02, 0A, 0B und 0C also 4 byte weg.
was denkst du, macht das sinn?
Zitatnachdem der eeprom des avr 328 begrenzt ist
Daher würde ich für umfangreichere Aufgaben die Nutzung eines externen EEprom vorsehen. Dieser ist sehr einfach anzuschließen und kostet nur ein paar Cent.
Gruß
Dirk
darüber habe ich auch nachgedacht, aber unser panstamp ist ja nicht allein auf der welt.
ziel der aktion ist ja, hardware für unsere HM installation bauen zu können, die es so nicht zu kaufen gibt.
d.h. selbst wenn wir hier mehr als 512 byte an variablen ablegen können, so muss ja FHEM auch wissen, was mit den variablen anzufangen ist.
deshalb die idee, wir legen ~10 default devices in der schnittstelle zu FHEM und in der Asksin library und verwenden die Register nach unseren vorstellungen....
Ich bin auch dafür, den begrenzten internen EEPROM Speicher einfach zu ignorieren und generell einen externen Speicher zu verwenden.
Zuviel Speicher kann man nicht haben. Mit 512 Byte kommt man wirklich nicht weit, und beim Arduino siehts auch nicht viel besser aus.
Von Begrenzungen des Funktionsumfangs bereits im Vorfeld halte ich gar nichts.
Hi,
sorry, ist nicht immer Adresse 01 sonder 0x01-0x10, 0x11-0x20 0x81-0x90 und 0x91-0xA0
wir muessen unterscheiden zwischen der Darstellung in den Messages und der Speicherung im EEPROM.
Mein Vorschlag mir den Strukturen waere sicher nicht der Weg, wie ich es implementiere. Ich bin gegen ein Standart-zusatz-EEPROM, jedenfalls nicht weil die Register so viel Platz brauchen. Der Mechanismuss sollte ein zusatzprom zulassen. Mit etwas coding lässt es sich deutlich einfacher schaffen.
Ich bastle mal einen "sinnvollen" Vorschlag...
Soweit, denke ich, sind wir uns von der Architektur einig (ganz grobe Darstellung!!)
modul EEPROM
- verwaltet den physikalischen Addressraum
- stellt ein API zu Verfügung zum Schreiben
- ist skalierbar so dass auch ein zusatzEEPROM verwaltet wird - der virtuelle Addressraum wird linear.
modul register
- Sinn des Moduls ist es requests aus den Messages auf das EEPROM zu mappen
- macht die Umrechnung der Message-Addressierung (chan/list/peer/addr) nach virtuellen EEPROM addressraum
- stellt get und set funktionen zu verfügung, evtl getBulk, getall,... geschmackssache.
- set bedient das schreiben
- die get funktion könnte die Daten passend für die Message aufbereiten
- muss auch messages wie "fertig zum Schreiben" und "schreiben beendet" bedienen.
- auch die Peer-IDs müssen berücksichtigt werden!
Modul fData
- stellt ein API für die Operational SW auf das EEPROM dar.
- Die Register sind ja Daten, die für den Betrieb genutzt werden müssen. Daher muss auf die Daten immer schnell zugegriffen werden können.
- Mein Vorschlag ist, einfach eine Struktur über die Bereich des Proms zu legen, pointer basiered. Die Organisation hier ist nach Funktion zu organisieren, also statemachine, paired To
Für den Quickstart wollen wir das pairen konnen. Hierzu brauchen wir nur List 0, channel 0.
Somit konnen wir erst einmal speicher fressen, das wird dann später korrigiert, in den beiden Modulen.
Im EEPROM nutzen wir 255 Bytes
register muss chn/list/peer/addr (jetzt nur 0/0/0/addr) auflösen in
chars [1][1][1][255]
peering würde dann auf Adresse 10/11/12 schreiben oder 9/10/11 im EEPROM (HM fängt nicht bei 0 an)
Wenn eine read message kommt müssten dann "alle" bytes gesendet werden - zum Testen auch gerne 255
register liefert dann z.B. ein Array mit
01 000000000000000000PAIRID000000
11 000000000000000000000000000000
21 000000000000000000000000000000
...
D1 000000000000000000000000000000
E1 000000000000000000000000000000
F1 0000000000000000000000000000
der messageparser muss dann das Array in messages packen und das Terminieren einbauen (0000)
Ist ein schöner test, dass das Generieren der Messages funktioniert.
Ein Inteligenter Vorschlag zur Speicherverwaltung kommt noch.Das muss erheblich gestrafft werden, klar
So wieder viel gefaselt - kann man es verstehen, ist dieArchitektur so akzeptabel?
Gruss Martin
ZitatIch bin auch dafür, den begrenzten internen EEPROM Speicher einfach zu ignorieren und generell einen externen Speicher zu verwenden.
Von Ignorieren hab ich gar nicht geredet. Es gibt sicher viele Anwendungsfälle wo der interne EEprom ausreichend ist. Wir sollten aber einen optionalen externen EEprom vorsehen.
Gruß
Dirk
@Dirk,
absolut deiner Meinung - ich denke betateilchen wollte IMMER externe PROMS. Egal, kein Fingerpointing.
Ich versuche ein Konzept zu erarbeiten, dass eine Struktur für das "reading" und das variablenmodul erstellt.
Ich denke an einen code-generator, man gibt die Register in einer Tabelle an und erzeugt die C-files mit den Datenstrukturen. Schreiben ich evtl in Perl.
Man erstellt also die Register-definition im Textfile. Dann generiert man die C-files und kopiert sie in das ASKIN file (oder included sie).
Wenn man ein neues PS modul bauen will aendert man die Definition und kompiliert neu. Natürlich muss man die Nutzung der Register noch programmieren, eben die Spezielle Funktion der Register.
Das pre-Perl script kann dann auch einen Output erstellen, den man mit regList vergleichen kann.
Mal sehen, heute aber nicht mehr... ;-)
Gruss Martin
könnt ihr bitte aufhören so geile Ideen umzusetzen ? Irgendwann wirds zu teuer (sagt meine Frau ... ;-)
Kann mir jemand Tips zur Bestellung geben, bitte ?
a: auf der Frontseite haben die einen Prototypen für V2. Soweit ich sehe mehr Speicher und AES, dafür keine Header... lohnt es sich zu warten ?
wenn nein oder vielleicht:
einzige Quelle ist der store unter panstamp.com ? im Augenblick scheint da fast alles out-of-stock zu sein, liegt wohl an den ferien ... Versand ca 10$ ?
Passt das so oder gibt es sinnvolle Ergänzungen (hab ich was vergessen was ich hinterher bereue ?)
* panstick developer board ?
* DHT11 oder DHT22 (lohnt sich DHT22)?
* Gehäuse ? (Kann man die nehmen oder sehen die in echt total hässlich aus ? Bleibt noch ein wenig Platz für anderen Sensoren frei ?)
* Output Board ?
* rgb Board ?
* lohnt sich eine externe Antenne ?
Danke für Tips, Grüße
Jörg
v1 wird ab anfang september wieder lieferbar sein. für v2 gibt es noch keinen termin. warten lohnt sich höchstens dann wenn die resourcen von v2 reichen würden. v2 ist eine neue 'cpu' eventuell ist am anfang noch das ein oder andere problem mit der die zu erwarten.
du brauchst eine möglichkeit die dinger zu flashen. der panstick ist die einfachste aber nicht die einzige möglichkeit.
die gehäuse sind hmmm keine schönheit. aber ok. wichtig: es gibt keine öffnung für die externe antenne.
statt dem original rgb board schau dir das hier an: Link (http://forum.fhem.de/index.php?topic=13890.0).
was den batteriebetrieb mit dem aktuellen hm sketch angeht: wenn ich es richtig verfolgt habe ist noch nichts in richtung stromspaaren und schlaf modus implementiert. d.h. zumindest mit der aktuellen version wird die batterie recht schnell leer gelutscht sein.
gruss
andre
Hallo Zusammen,
und wieder ein Stückchen weiter...
Pairing sollte jetzt komplett funktionieren.
<- 1A 00 84 00 3F A6 5C 00 00 00 0A 80 02 50 53 30 30 30 30 30 30 30 31 00 04 01 01(l:27)(2797)
-> 10 01 A0 01 63 19 63 3F A6 5C 00 05 00 00 00 00 00(l:17)(3149)
start config mode; channel: 0, peerAdr: 00 00 00, peerCnl: 0, parmLst: 0
<- 0A 01 80 02 3F A6 5C 63 19 63 00(l:11)(3180)
-> 13 02 A0 01 63 19 63 3F A6 5C 00 08 02 01 0A 63 0B 19 0C 63(l:20)(3694)
write data: 02 01 0A 63 0B 19 0C 63
new PairID: 63 19 63
<- 0A 02 80 02 3F A6 5C 63 19 63 00(l:11)(3725)
-> 0B 03 A0 01 63 19 63 3F A6 5C 00 06(l:12)(3997)
config end
<- 0A 03 80 02 3F A6 5C 63 19 63 00(l:11)(4018)
-> 10 04 A0 01 63 19 63 3F A6 5C 00 04 00 00 00 00 00(l:17)(20996)
config param request; channel: 0, peerAdr: 00 00 00, peerCnl: 0, parmLst: 0
<- 1A 01 A0 10 3F A6 5C 63 19 63 02 00 00 01 00 00 00 00 00 00 00 63 19 63 00 00 00(l:27)(21043)
-> 0A 01 80 02 63 19 63 3F A6 5C 00(l:11)(21155)
ACK (21157)
-> 10 05 A0 01 63 19 63 3F A6 5C 01 04 00 00 00 00 01(l:17)(22016)
config param request; channel: 1, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 02 A0 10 3F A6 5C 63 19 63 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00(l:27)(22065)
-> 0A 02 80 02 63 19 63 3F A6 5C 00(l:11)(22177)
ACK (22177)
-> 0B 06 A0 01 63 19 63 3F A6 5C 01 03(l:12)(22810)
config peer list request; channel: 1
<- 0E 03 A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(22837)
-> 0A 03 80 02 63 19 63 3F A6 5C 00(l:11)(22962)
ACK (22962)
-> 10 07 A0 01 63 19 63 3F A6 5C 02 04 00 00 00 00 01(l:17)(23232)
config param request; channel: 2, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 04 A0 10 3F A6 5C 63 19 63 02 00 00 00 00 00 01 04 00 8C 07 32 00 32 00 00 00(l:27)(23347)
-> 0A 04 80 02 63 19 63 3F A6 5C 00(l:11)(23459)
ACK (23461)
-> 0B 08 A0 01 63 19 63 3F A6 5C 02 03(l:12)(23726)
config peer list request; channel: 2
<- 0E 05 A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(23834)
-> 0A 05 80 02 63 19 63 3F A6 5C 00(l:11)(23959)
ACK (23959)
-> 10 09 A0 01 63 19 63 3F A6 5C 03 04 00 00 00 00 01(l:17)(24229)
config param request; channel: 3, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 06 A0 10 3F A6 5C 63 19 63 02 00 00 00 00 00 01 00 00 00 00 32 00 32 00 00 00(l:27)(24348)
-> 0A 06 80 02 63 19 63 3F A6 5C 00(l:11)(24461)
ACK (24463)
-> 0B 0A A0 01 63 19 63 3F A6 5C 03 03(l:12)(24727)
config peer list request; channel: 3
<- 0E 07 A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(24836)
-> 0A 07 80 02 63 19 63 3F A6 5C 00(l:11)(24961)
ACK (24961)
-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(25231)
config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 08 A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 00 38 00 05 60 00 08 05 1D 00 11 31(l:27)(25348)
-> 0A 08 80 02 63 19 63 3F A6 5C 00(l:11)(25460)
ACK (25462)
-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(26454)
config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 09 A0 10 3F A6 5C 63 19 63 02 00 28 05 1D 00 2B 00 05 5F 00 00 05 1D 00 04 31(l:27)(26501)
-> 0A 09 80 02 63 19 63 3F A6 5C 00(l:11)(26615)
ACK (26615)
-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(27602)
config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 0A A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 00 1E 00 05 5F 00 42 05 1D 00 37 31(l:27)(27650)
-> 0A 0A 80 02 63 19 63 3F A6 5C 00(l:11)(27764)
ACK (27764)
-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(28753)
config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 0B A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 05 5F 00 13 05 1D 00 05 1D 00 2A 31(l:27)(28801)
-> 0A 0B 80 02 63 19 63 3F A6 5C 00(l:11)(28913)
ACK (28915)
-> 10 0B A0 01 63 19 63 3F A6 5C 04 04 00 00 00 00 01(l:17)(29902)
config param request; channel: 4, peerAdr: 00 00 00, peerCnl: 0, parmLst: 1
<- 1A 0C A0 10 3F A6 5C 63 19 63 02 11 29 05 1D 05 5F 00 05 60 00 1D 05 1D 00 1D 31(l:27)(29949)
-> 0A 0C 80 02 63 19 63 3F A6 5C 00(l:11)(30064)
ACK (30064)
-> 0B 0C A0 01 63 19 63 3F A6 5C 04 03(l:12)(31047)
config peer list request; channel: 4
<- 0E 0D A0 10 3F A6 5C 63 19 63 01 00 00 00 00(l:15)(31074)
-> 0A 0D 80 02 63 19 63 3F A6 5C 00(l:11)(31199)
ACK (31199)
Ich bin mal auf deine Idee bzgl. der Register gespannt :-)
Die Arduino's haben nicht wirklich viel RAM. Um genau zu sein, hat der atmega 328 genau 2kb RAM.
So ein Array - uint8_t stor[1][1][1][255] - belegt also schon mal 255 bytes, das ganze für 4 Channel wäre 1KB.
Das wäre auch die max. Größe mit der meine Library derzeit noch läuft. Vielleicht kann ich da noch ein wenig
optimieren, aber viel geht bestimmt nicht mehr.
Vielleicht brauchen wir sowas, wie eine direkte EEprom Adressierung und dazu ein Bit-Array indem wir
beschriebene Adressen markieren.
Bei 512 Byte EEprom hätten wir dann eine Speichernutzung von 64 Byte. Damit hätten wir dann was im Speicher
um die beschriebenen EEprom Adressen zu finden und die eigentlichen Werte ziehen wir aus dem EEprom.
Zusätzlich gibts dann noch ein Array für die variablen Dinge, die als Statuswert geschickt werden müssen.
Viele Grüße
Horst
Das klingt ja schon mal gut.
Ich würde die Register aber direkt ins EEprom schreiben und daraus lesen. Hierfür muss das nicht über eine RAM-Variable laufen.
Dann muss man auch nicht sicherstellen, dass die Variablen im Ram bei einem plötzlichem Spannungsausfall erst ins EEprom gesichert werden müssen.
Der Mega328 hat zwar nur 1KB EEprom, den RAM kann man dann aber für andere Sachen benutzen.
Und für mehr, dann wie gesagt ein externes EEprom.
Gruß
Dirk
Hi,
bin im rückstand mit meiner Ankündigung.
für mich ist klar, dass die Daten direkt aus dem EEPROM gelesen werden müssen - sonst steigt der Overhead noch weiter.
Aber auch dort muss er komprimiert werden - und somit braucht es eine "access-struktur". Die wird bei der Kompilierung festgelegt und steht quasi im Code.
Ich gehe davon aus, dass man sich einen code je Anwendung compiliert und diesen dann auf den PS laden kann. Damit ist die Funktion festgelegt. Andere Funktion: anderen Code auf PS laden.
So jetzt hoffe ich auch einen sauberen Code zu liefern, der das hält, was ich verspreche.
Gruss Martin
mach dir mal keinen stress! ich brauch ja auch noch zeit um die anderen funktionen zu integrieren.
und dann auch noch um zu optimieren, ich lerne ja pausenlos beim coden dazu :-)))
nun, jetzt habe ich wenigstens angefangen.
das Konzept für das erste Interface zum FHEM-register-schreiben/lesen nimmt formen an.
Zum 2. interface, register im code nutzen
- unterstützt der Compiler bitfields?
- wie lange ist ein pointer? 26bit?
Gruss Martin
na, du fragst fragen :-)
soweit ich weiß sind pointer im avr compiler vom typ integer - also 16 bit
wenn du sowas meinst:
typedef struct {
byte b1 : 1;
byte b2 : 1;
byte b3 : 1;
byte b4 : 1;
byte b5 : 1;
byte b6 : 1;
byte b7 : 1;
byte b8 : 1;
} EightBitfield;
dann ja, das unterstützt der avr c compiler.
ich hab mal in den sketch ein weiteres blatt eingebaut, nennt sich register.h -
wäre klasse wenn wir dort die struktur des speichers abbilden können.
anbei ein neues update, habe noch einen fehler in der empfangsroutine entdeckt.
sollte jetzt stabiler sein und das aussetzen des empfangs nach einer längeren zeit sollte
der vergangenheit angehören...
viele grüße
trilu
irgendwie hab ich den Faden verloren :(
@betateilchen
faden wieder gefunden? :-)))
und mal wieder ein kleines update.
die empfangsfunktion basiert jetzt komplett auf interrupt. das macht es in zukunft leichter die stromsparmodi zu verwenden.
ansonsten habe ich ein wenig aufgeräumt und viele der texte ins progmem geschickt. so das jetzt noch etwa 1k ram frei ist.
anfangs hatte ich öfter das problem das sich nach längeren standby zeiten das empfangsteil weg gehängt hat, das sollte jetzt auch behoben sein.
ich fahre jetzt am sonntag für eine woche in die türkei, d.h. in der zeit wird sich von meiner seite nicht viel tun.
nach meinem urlaub bastle ich weiter und implementiere weitere funktionen und befehle.
viele grüße
horst
schönen Urlaub :)
Vielleicht komme ich am Wochenende mal dazu, den Faden zu suchen und wiederzufinden. Und wenn Du dann zurück bist, fahre ich in Urlaub *g*
Das heisst du kommst aus Bayern oder hast keine Kinder :)
oder ich bin so alt, dass ich mich um Schulferien nicht mehr kümmern muss :)
so urlaub beendet - jetzt kanns hier wieder etwas weiter gehen.
ich habe mir so meine gedanken gemacht wie man den speicher aufteilen könnte und habe dazu auch einige ideen. was mir fehlt ist die info was alles in List0 rein kommt.
mein verständnis war bisher das da nur 4 adressen drin stehen, also 02, 0A, 0B und 0C
jetzt habe ich bei einem dimmer gesehen, das es zwei weitere gibt 15 mit dem wert ff und 16 ebenfalls mit dem wert ff.
könnt ihr mal bitte bei euren HM geräten schauen was in List0 steht und hier posten. List0 mit geräteangabe...
Meinst Du diese Angaben ?
Habe leider nur die beiden Geräte.
model HM-LC-Bl1PBU-FM
RegL_00:
02:01 0A:F1 0B:10 0C:34 15:FF 00:00
2013-09-10 07:07:55
model HM-LC-Dim1TPBU-FM
RegL_00:
02:01 0A:F1 0B:10 0C:34 15:FF 16:FF 00:00
2013-04-18 08:52:35
Gruss Martin
Hallo Zusammen,
mal wieder ein kleines Update zur Weiterentwicklung
- Register Definition über ein Perl Script von Martin
- Lesen und schreiben der Registerinhalte und Speicherung im EEprom
- Handling der meißten Config Befehle
Was noch fehlt
- ACK/NACK Handling
- INFO_PARAMETER_CHANGE, INFO_ACTUATOR_STATUS und diverse andere Befehle
- Event Handling
- Power Management
- Tests, tests, tests
Die Sourcen werde ich Mitte der Woche hier posten...
Viele Grüße
Horst
Ach ja - eine Frage
was antwortet eigentlich ein Device auf einen Peer Request wenn die Peer Liste voll ist?
Kommt dann ein NACK oder keine Antwort zurück?
wie meinst du das?
ein "get peers" sendet natürlich alle peers.
ein "set peer" wird mit NACK beantwortet.
ist das generell unter HM so.
Alle ungültigen Fragen werden mit einem NACK beantwortet?
Z.b. ich frage Channel 0 nach List1?
Hi Martin,
habe heute mal ein wenig mit deinem Config-Script gespielt.
Funktioniert gut!
Device config, size: 536 byte
cnl lst slcPtr slcEnd phyAddr phyLen
0 0 0 2 0 4
1 1 2 1 4 1
1 3 3 2 5 22
2 1 15 1 137 1
2 3 16 2 138 22
3 1 28 1 270 1
3 3 29 2 271 22
4 1 41 1 403 1
4 3 42 2 404 22
Peer Database, size: 96 byte
cnl pIdx slcPtr slcEnd phyAddr phyLen peer
1 0 3 2 5 22 00 00 00 00
1 1 5 2 27 22 00 00 00 00
1 2 7 2 49 22 AA BB CC 04
1 3 9 2 71 22 AA BB CC 03
1 4 11 2 93 22 00 00 00 00
1 5 13 2 115 22 00 00 00 00
2 0 16 2 138 22 00 00 00 00
2 1 18 2 160 22 00 00 00 00
2 2 20 2 182 22 00 00 00 00
2 3 22 2 204 22 00 00 00 00
2 4 24 2 226 22 00 00 00 00
2 5 26 2 248 22 00 00 00 00
3 0 29 2 271 22 00 00 00 00
3 1 31 2 293 22 00 00 00 00
3 2 33 2 315 22 00 00 00 00
3 3 35 2 337 22 00 00 00 00
3 4 37 2 359 22 00 00 00 00
3 5 39 2 381 22 00 00 00 00
4 0 42 2 404 22 00 00 00 00
4 1 44 2 426 22 00 00 00 00
4 2 46 2 448 22 00 00 00 00
4 3 48 2 470 22 00 00 00 00
4 4 50 2 492 22 00 00 00 00
4 5 52 2 514 22 00 00 00 00
Viele Grüße
Horst
schon wieder eine frage - kann unter HM ein device mit mehreren channeln gleichzeitig gepeert werden?
also ist sowas zulässig?
Peer Database, size: 96 byte
cnl pIdx slcPtr slcEnd phyAddr phyLen peer
1 0 3 2 5 22 00 00 00 00
1 1 5 2 27 22 00 00 00 00
1 2 7 2 49 22 AA BB CC 04
1 3 9 2 71 22 AA BB CC 03 <- siehe weiter unten...
1 4 11 2 93 22 00 00 00 00
1 5 13 2 115 22 00 00 00 00
2 0 16 2 138 22 AA BB CC 04
2 1 18 2 160 22 AA BB CC 03 <- gleicher peer eintrag auf verschiedenen channeln?
2 2 20 2 182 22 00 00 00 00
2 3 22 2 204 22 00 00 00 00
2 4 24 2 226 22 00 00 00 00
2 5 26 2 248 22 00 00 00 00
Anscheinend führe ich hier Alleinunterhaltungen :-)
Ich bin ganz begeistert. Bisher waren es nur Trockenübungen am Modul, gerade aber der Test
in Verbindung mit FHEM. Scheint ganz gut zu klappen!
Serial: PS00000001, HMID: 3F A6 5C, FreeMem: 1200 byte's
S- 1A 00 A2 00 3F A6 5C 00 00 00 10 00 67 50 53 30 30 30 30 30 30 30 31 9F 41 01 01 (l:27)(4196)
<- sendStr (4229)
<- sendStr (4530)
-> 10 01 A0 01 63 19 63 3F A6 5C 00 05 00 00 00 00 00 (l:17)(4601)
start config mode; Cnl: 0, PeerID: 00 00 00, PeerCnl: 0, ParmLst: 0
S- 0A 01 80 02 3F A6 5C 63 19 63 00 (l:11)(4620)
-> 10 01 A0 01 63 19 63 3F A6 5C 00 05 00 00 00 00 00 (l:17)(4800)
start config mode; Cnl: 0, PeerID: 00 00 00, PeerCnl: 0, ParmLst: 0
S- 0A 01 80 02 3F A6 5C 63 19 63 00 (l:11)(4818)
<- sendStr (4837)
-> 13 02 A0 01 63 19 63 3F A6 5C 00 08 02 01 0A 63 0B 19 0C 63 (l:20)(5210)
write data: 02 01 0A 63 0B 19 0C 63
S- 0A 02 80 02 3F A6 5C 63 19 63 00 (l:11)(5224)
<- sendStr (5242)
-> 0B 03 A0 01 63 19 63 3F A6 5C 00 06 (l:12)(5521)
end config mode; Cnl: 0
S- 0A 03 80 02 3F A6 5C 63 19 63 00 (l:11)(5529)
<- sendStr (5548)
-> 10 04 A0 01 63 19 63 3F A6 5C 00 04 00 00 00 00 00 (l:17)(32407)
config param request; Cnl: 0, PeerID: 00 00 00, PeerCnl: 0, ParmLst: 0
S- 14 01 A0 10 3F A6 5C 63 19 63 02 02 01 0A 63 0B 19 0C 63 00 00 (l:21)(32430)
<- sendStr (32456)
-> 0A 01 80 02 63 19 63 3F A6 5C 00 (l:11)(32579)
ACK (32581)
-> 10 05 A0 01 63 19 63 3F A6 5C 01 04 00 00 00 00 01 (l:17)(33683)
config param request; Cnl: 1, PeerID: 00 00 00, PeerCnl: 0, ParmLst: 1
S- 0E 02 A0 10 3F A6 5C 63 19 63 02 08 00 00 00 (l:15)(33703)
<- sendStr (33726)
-> 0A 02 80 02 63 19 63 3F A6 5C 00 (l:11)(33853)
ACK (33853)
-> 0B 06 A0 01 63 19 63 3F A6 5C 01 03 (l:12)(34734)
config peer list request; Cnl: 1
S- 1A 03 A0 10 3F A6 5C 63 19 63 01 11 22 33 04 11 22 33 03 AA BB CC 04 AA BB CC 03 (l:27)(34750)
<- sendStr (34783)
-> 0A 03 80 02 63 19 63 3F A6 5C 00 (l:11)(34899)
ACK (34902)
S- 0E 04 A0 10 3F A6 5C 63 19 63 01 00 00 00 00 (l:15)(34908)
<- sendStr (35074)
-> 0A 04 80 02 63 19 63 3F A6 5C 00 (l:11)(35194)
ACK (35194)
-> 10 07 A0 01 63 19 63 3F A6 5C 02 04 00 00 00 00 01 (l:17)(35469)
config param request; Cnl: 2, PeerID: 00 00 00, PeerCnl: 0, ParmLst: 1
S- 0A 07 80 02 3F A6 5C 63 19 63 80 (l:11)(35487)
<- sendStr (35506)
-> 0B 08 A0 01 63 19 63 3F A6 5C 02 03 (l:12)(35784)
config peer list request; Cnl: 2
S- 0A 08 80 02 3F A6 5C 63 19 63 80 (l:11)(35794)
<- sendStr (35813)
-> 10 09 A0 01 63 19 63 3F A6 5C 03 04 00 00 00 00 01 (l:17)(36096)
config param request; Cnl: 3, PeerID: 00 00 00, PeerCnl: 0, ParmLst: 1
S- 0A 09 80 02 3F A6 5C 63 19 63 80 (l:11)(36114)
<- sendStr (36134)
-> 0B 0A A0 01 63 19 63 3F A6 5C 03 03 (l:12)(36411)
config peer list request; Cnl: 3
S- 0A 0A 80 02 3F A6 5C 63 19 63 80 (l:11)(36421)
<- sendStr (36440)
-> 10 0B A0 01 63 19 63 3F A6 5C 01 04 11 22 33 03 03 (l:17)(36722)
config param request; Cnl: 1, PeerID: 11 22 33, PeerCnl: 3, ParmLst: 3
S- 1A 05 A0 10 3F A6 5C 63 19 63 02 02 00 03 00 06 00 07 00 08 00 09 00 0A 00 82 00 (l:27)(36749)
<- sendStr (36782)
-> 0A 05 80 02 63 19 63 3F A6 5C 00 (l:11)(36898)
ACK (36900)
S- 18 06 A0 10 3F A6 5C 63 19 63 02 83 00 86 00 87 00 88 00 89 00 8A 00 00 00 (l:25)(36913)
<- sendStr (37081)
-> 0A 06 80 02 63 19 63 3F A6 5C 00 (l:11)(37193)
ACK (37193)
-> 10 0C A0 01 63 19 63 3F A6 5C 01 04 11 22 33 04 03 (l:17)(37468)
config param request; Cnl: 1, PeerID: 11 22 33, PeerCnl: 4, ParmLst: 3
S- 1A 07 A0 10 3F A6 5C 63 19 63 02 02 00 03 00 06 00 07 01 08 63 09 19 0A 63 82 00 (l:27)(37494)
<- sendStr (37525)
-> 0A 07 80 02 63 19 63 3F A6 5C 00 (l:11)(37644)
ACK (37644)
S- 18 08 A0 10 3F A6 5C 63 19 63 02 83 00 86 00 87 00 88 00 89 00 8A 00 00 00 (l:25)(37656)
<- sendStr (37824)
-> 0A 08 80 02 63 19 63 3F A6 5C 00 (l:11)(37937)
ACK (37937)
-> 10 0D A0 01 63 19 63 3F A6 5C 01 04 AA BB CC 03 03 (l:17)(38211)
config param request; Cnl: 1, PeerID: AA BB CC, PeerCnl: 3, ParmLst: 3
S- 1A 09 A0 10 3F A6 5C 63 19 63 02 02 00 03 00 06 00 07 00 08 00 09 00 0A 00 82 00 (l:27)(38238)
<- sendStr (38270)
-> 0A 09 80 02 63 19 63 3F A6 5C 00 (l:11)(38387)
ACK (38387)
S- 18 0A A0 10 3F A6 5C 63 19 63 02 83 00 86 00 87 00 88 00 89 00 8A 00 00 00 (l:25)(38402)
<- sendStr (38569)
-> 0A 0A 80 02 63 19 63 3F A6 5C 00 (l:11)(38682)
ACK (38684)
-> 10 0E A0 01 63 19 63 3F A6 5C 01 04 AA BB CC 04 03 (l:17)(38957)
config param request; Cnl: 1, PeerID: AA BB CC, PeerCnl: 4, ParmLst: 3
S- 1A 0B A0 10 3F A6 5C 63 19 63 02 02 00 03 00 06 00 07 00 08 00 09 00 0A 00 82 00 (l:27)(38983)
<- sendStr (39016)
-> 0A 0B 80 02 63 19 63 3F A6 5C 00 (l:11)(39133)
ACK (39133)
S- 18 0C A0 10 3F A6 5C 63 19 63 02 83 00 86 00 87 00 88 00 89 00 8A 00 00 00 (l:25)(39145)
<- sendStr (39315)
-> 0A 0C 80 02 63 19 63 3F A6 5C 00 (l:11)(39428)
ACK (39428)
-> 10 0F A0 01 63 19 63 3F A6 5C 01 01 1F A6 5C 04 03 (l:17)(120741)
config peer add; Cnl: 1, PeerID: 1F A6 5C, PeerCnl_A: 4, PeerCnl_B: 3, ret: 1
S- 0A 0F 80 02 3F A6 5C 63 19 63 00 (l:11)(120856)
<- sendStr (120875)
Device config, size: 117 byte
cnl lst slcPtr slcEnd phyAddr phyLen
0 0 0 2 0 4
1 1 2 1 4 1
1 3 3 4 5 14
Peer Database, size: 32 byte
cnl pIdx slcPtr slcEnd phyAddr phyLen peer
1 0 3 4 5 14 11 22 33 04
1 1 7 4 19 14 11 22 33 03
1 2 11 4 33 14 AA BB CC 04
1 3 15 4 47 14 AA BB CC 03
1 4 19 4 61 14 1F A6 5C 04
1 5 23 4 75 14 1F A6 5C 03
1 6 27 4 89 14 00 00 00 00
1 7 31 4 103 14 00 00 00 00
-> 0B 6A A4 40 1F A6 5C 3F A6 5C 04 00 (l:12)(169619)
Remote_Event; cnl: 04, data: 00
recv_Event, cnl: 1, data: 04 00
S- 0A 6A 80 02 3F A6 5C 1F A6 5C 00 (l:11)(169635)
<- sendStr (169656)
-> 0B 6B 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(174143)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 6C 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(174409)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 6D 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(174675)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 6E 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(174944)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 6F 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(175210)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 70 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(175476)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 71 A0 40 1F A6 5C 3F A6 5C 44 01 (l:12)(175742)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
S- 0A 71 80 02 3F A6 5C 1F A6 5C 00 (l:11)(175759)
<- sendStr (175777)
-> 0E 18 A0 11 63 19 63 3F A6 5C 02 01 C8 00 00 (l:15)(470085)
-> 0E 18 A0 11 63 19 63 3F A6 5C 02 01 C8 00 00 (l:15)(470284)
Was sieht man in dem Log? Zuerst einmal das Pairing mit der Zentrale, danach ein get config.
Hier sind einige NACK's drin, da ich nur einen Kanal definiert habe, FHEM aber bei diesem Device zwei Kanäle erwartet.
Danach folgt das Peeren mit einem Funktaster...
-> 10 0F A0 01 63 19 63 3F A6 5C 01 01 1F A6 5C 04 03 (l:17)(120741)
config peer add; Cnl: 1, PeerID: 1F A6 5C, PeerCnl_A: 4, PeerCnl_B: 3, ret: 1
S- 0A 0F 80 02 3F A6 5C 63 19 63 00 (l:11)(120856)
<- sendStr (120875)
Das hier ist die Wiederholungssequenz von einem Funktaster:
-> 0B 6C 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(174409)
Remote_Event; cnl: 44, data: 01
recv_Event, cnl: 1, data: 44 01
-> 0B 6D 84 40 1F A6 5C 3F A6 5C 44 01 (l:12)(174675)
Mit cnl ist peerChannel gemeint, also Taste 4 - in Data seht ihr den eigentlichen Kanal.
Als nächstes werde ich jetzt noch ein wenig mit der Config spielen und mir mal die Sache mit List4 anschauen.
Was mir auch noch nicht klar ist, wie muss der Payload für einen Status aussehen. Wäre Klasse wenn ihr hier
mithelfen könntet.
Viele Grüße
Horst
Hallo Horst,
aktuell lese ich mit. Aber die Zeit kommt, dass ich deine Lib einsetzen werde.
Bis dahin werkle ich noch an den anderen Baustellen in FHEM die ich aufgerissen habe :)
Gruß
Dirk
Hallo Horst,
keine Sorge, ich lese hier aufmerksam mit.
Zu Deiner Frage: Ein Device wird überhaupt nicht gepeert. Es werden nur Channels untereinander gepeert. Deshalb muss jedes Device mindestens einen Channel besitzen.
Und ein Channel kann natürlich gleichzeitig mit mehreren anderen Channeln gepeert werden.
ich bin gerade dabei noch einmal das message handling zu checken und habe noch ein paar offene punkte entdeckt.
01 02 03 04 05 06 07
1A 00 A2 00 3F A6 5C 00 00 00 10 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01
01 Message length indicator
Reflect the size of the message without the indicator
02 Message counter
One Byte counter, increased by every send message. While sending an ACK the message counter from the received message is used.
03 Communication bit field
1 wakeup
2 wake me up
4 config mode (broadcast)
8 unknown
10 burst transmission
20 ACK requested
40 message from repeater
80 message to master or message could be repeated
04 Message type; see table below
05 Source Address; 3 Byte length, identification of own device
06 Target Address; 3 Byte length, 00 00 00 means broadcast
07 Payload; max size is 20 bytes
40 - message from repeater
ich gehe davon aus das eine message vom repeater 1:1 weiter gesendet wird und hier nur 0x40 bei byte03 gesetzt wird.
wurde die message bereits empangen, dann verwerfe ich sie.
korrekt?
1 - wakeup
2 - wake me up
10 - burst transmission
keine ahnung - kann das jemand beschreiben, am besten mit beispielen belegen?
danke und viele grüße
und noch eine Frage - braucht jemand zufällig Funkmodule?
http://www.aliexpress.com/item/25pcs-lot-CC1101-868MHz-wireless-module-1-2k-500-kbps-data-rate-Free-shipping/1104691912.html (//www.aliexpress.com/item/25pcs-lot-CC1101-868MHz-wireless-module-1-2k-500-kbps-data-rate-Free-shipping/1104691912.html)
Das Stück kostet 3,30€ oder so?
http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html (//www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html)
gibts auch in kleineren Stückzahlen :-)
Dafür aber auch etwas teurer,
1 Stück für 4,60€
Sind anscheinend auf 868 MHz abgestimmt, damit wären sie mit einem Arduino Mini Pro eine gute Alternative zur Panstamp.
Und somit auch deutlich günstiger - Arduino Mini Pro bei ebay aus Fernost für etwa 5 Euro + so ein Modul, macht 10€
Viele Grüße
Horst
Hi Horst,
wollte genau diese die Tage auch schon mal ordern.
Ich würde zum testen erst mal zwei nehmen.
Wenn du die 25 Stück nicht voll bekommst, dann gerne auch mehr.
Blöderweise ist die Zeit derzeit knapp.
Gruß
Dirk
Update:
Arduino Mini Pro gibts auch schon für $3,90 das Stück
http://www.aliexpress.com/item/Free-Shipping-Version-Pro-Mini-Module-Atmega328-5v-16M-For-Arduino-Compatible/1022001878.html (//www.aliexpress.com/item/Free-Shipping-Version-Pro-Mini-Module-Atmega328-5v-16M-For-Arduino-Compatible/1022001878.html)
Hallo Horst,
Ich wäre ebenfalls mit min. 3 von jedem dabei, um mich mal in das Thema Ardunio zu beschäftigen.
Gruß
Stefan
Hallo
Ich würde auch mal ein Funkmodul (zum testen) nehmen.
@Dirk
Währe der Arduino Mini Pro mit 3,3V nicht die bessere Variante.
Dann kann man das Funkmodul ab dem Arduino speisen.
Gruss Martin
PS: Das Project hier, find ich übrigens Klasse :-)
Hi Martin, da hast du recht.
laut Beschreibung kann das Board oben ab 3,3V betrieben werden. Daher sollte das da passen
Zitat7. Support for external 3.3V ~ 12V DC power supply
Gruß
Dirk
Hi!
Ich würde auch 2 Module abnehmen.
LG
Jan
Hallo trilu
Ich habe basierend auf deinem letzten Sketch (131001-2_sketch_aug05a.zip) mal versucht Ping-Pong zu spielen.
Gemäß message handling sollte das 3. Byte das Communication bit field enthalten ?!
Bei mir stehen da immer Werte >160 drin (A0=160). Was bedeuten diese ?
Das simulierte HM-Device "CUL_HM_HM_LC_Dim1PWM_CV_3FA65C_Sw" liefert beim Webcmd "on" folgenden Log:
-> 0E 1D A0 11 F1 15 02 3F A6 5C 02 01 C8 00 00 (l:15)(2313615)
Wie ist hier der Payload (C8 00 00) to interpretieren ?
Wie kann ich dem Device eine Nachricht zurückschicken ?
Gruss Peter
Available commands:
p - start pairing with master
b[0] b[n] s - send a string, b[0] is length (50 bytes max)
i[0]. i[1]. e - show eeprom content, i[0]. start address, i[1]. length
i[0]. b[1] f - write content to eeprom, i[0]. address, i[1] byte
c - clear eeprom complete, write 0 from start to end
t - gives an overview of the device configuration
$nn for HEX input (e.g. $AB,$AC ); b[] = byte, i[]. = integer
l> 0C E0 86 70 1C C8 D1 00 00 00 00 3C 5A (l:13)(2253259)
-> 0E 1D A0 11 F1 15 02 3F A6 5C 02 01 C8 00 00 (l:15)(2313615)
l> 0C 96 86 70 1C C9 0F 00 00 00 00 AC 40 (l:13)(2402155)
l> 0C E1 86 70 1C C8 D1 00 00 00 00 3C 5A (l:13)(2418075)
01 02 03 04 05 06 07
1A 00 A2 00 3F A6 5C 00 00 00 10 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01
01 Message length indicator
Reflect the size of the message without the indicator
02 Message counter
One Byte counter, increased by every send message. While sending an ACK the message counter from the received message is used.
03 Communication bit field
1 wakeup
2 wake me up
4 config mode (broadcast)
8 unknown
10 burst transmission
20 ACK requested
40 message from repeater
80 message to master or message could be repeated
04 Message type; see table below
05 Source Address; 3 Byte length, identification of own device
06 Target Address; 3 Byte length, 00 00 00 means broadcast
07 Payload; max size is 20 bytes
Hallo trilu,
giebts was neues ?
Hoffe nicht, dass Du das Project einstellst.
Grüsse Martin
Hallo trilu
Das hoffe ich auch nicht !
Eine vernünftige Arduino library via homematic Protokoll würde neue Möglichkeiten bieten.
Multisensoren und jegliche Art der Signalerfassung (Klingelsensor, Hall- u .Ultraschallsensor, etc.) sowie der Steuerung :D
Gruss Peter
Hallo trilu
Die Fragen haben sich erübrigt :-)
Durch lauschen und simulieren konnte ich diverse HM-Geräte (Temp, Sensor, etc.) nachstellen und den Payload besser verstehen.
Dein Script funktioniert wirklich gut.
Ich werde mich nun mal an deinen Sketch wagen.
Ich hoffe mal, dass noch jemand in das Library-Projekt zurückfindet :-)
Gruss Peter
Hallo PeterS
Zitat von: PeterS am 12 Oktober 2013, 08:03:02
Wie kann ich dem Device eine Nachricht zurückschicken ?
Hast Du das auch hinbekommen ?
Eine Nachricht von FHEM an das Gerät zu schicken.
Ich warte noch auf meinen bestellten Arduino, sobald der da ist, werde ich mich auch mal an der Libary versuchen.
Gruss Martin
Hallo mmatt
Ja, habe Senoren und Aktoren in Fhem definiert (Kopie von bestehenden mit neuer ID) und dann von Fhem bzw. per Serial Monitor aus getriggert.
Durch das Lauschen von echten Homematic-Komponenten bzw. Fenstersensor (HM-SEC-SC) kann man den Empfangsstring auch einfach noch mal abgewandelt schicken und so den Rückmeldestatus umschiessen.
Beispiel Fenstersensor (HM-SEC-SC): Sensor-ID:ABC123; HM-ID:456DEF
0C 2D A4 41 12 3A BC 45 6D EF 01 75 00 - > Rückmeldung Sensor zu
$0C $2C $A4 $41 $12 $3A $BC $45 $6D $EF $01 $74 $C8 s -> Rückmeldung ändern auf Sensor auf
Das Ergebnis macht echt Laune :-)
Gruss Peter
Hallo,
ich habe mir eben ein paar Funkmodule (MAX! Fensterkontakt ARR) bestellt und würde gerne bei der Entwicklung mitmachen.
Gibt es hier einen aktuellen Stand der Library mit dem man spielen kann?
bye,
Karl
Hi shaddi
Die letzte Version von trilu ist 131001-2_sketch_aug05a.zip.
Auf dieser Basis habe ich auch getestet.
Gruss Peter
Hi
Das original ELV-TRX868 Modul macht bisher auf mich noch den besten Eindruck.
Schlank und schmal:
https://github.com/ccier/openhm/wiki/Trx868
In Kombination mit einem Arduino Nano ideal.
Schade, dass man die CC1101-Module nicht über ELV beziehen kann.
Der Arduino Mini Pro wird über ein Breakout-Board versorgt und programmiert? Kostet auch wieder ein paar Euro. Dann schrumpft der Preisvorteil wieder gegenüber dem Nano:-(
http://arduino.cc/de/Main/ArduinoBoardProMini
Gruss Peter
PS: Die Arduino IDE ist auch nix für Debugger. Serial printing ist ja auch steinzeitlich :-)
Hallo Zusammen,
zuerst einmal Entschuldigung für die lange Pause. Mit der neuen Forensoftware scheinen die Benachrichtigungen per Email verloren gegangen zu sein.
Klar bastle ich noch an der Lib weiter. Mein Ziel ist es ein Framework zu haben, mit dem man ähnlich Panstamp eigene Geräte für HM-Protokoll bauen kann.
Panstamp ist eigentlich eine feine Sache, leider gibt es aber keine schönen Aktoren, also Fernbedienungen und Wandschalter die dann direkt den Panstamp schalten können.
Status der China Funkmodule: Nachdem nicht annähernd 25 Stück zusammen gekommen sind, habe ich jetzt einen 5'er Pack bestellt. Sobald die da sind, bekommen die Leute die sich wegen Sammelbestellung gemeldet haben je 1 Stück zum testen. Wenn Qualität und Reichweite passt können wir ja eine neue Sammelbestellung versuchen.
Anbei gibt es einen neuen Stand der Library. Mittlerer weile funktioniert schon einiges :-)
Ich versuche mal zusammen zu fassen was geht:
Der Sketch ist derzeit als Dimmer konfiguriert. Er lässt sich mit FHEM pairen. Peeren über die FHEM Oberfläche mit HM Aktoren funktioniert auch. Pair und peers werden im EEprom gespeichert und sind nach dem nächsten Start auch wieder vorhanden. Ich schreibe ein Magic Byte in den EEprom, anhand dessen erkenne ich beim nächsten starten ob der EEprom bereits richtig beschrieben ist. Beim ersten Start wird der EEprom mit 00 gefüllt.
Über die serielle Konsole kann man durch Eingabe eines 'r' <Return> das MagicByte löschen und einen Reset ausführen.
Zusätzlich könnt ihr euch den EEprom anzeigen lassen. Komplett anzeigen geht mit 'e' <Return>. Einzelne Bereiche mit Addresse '280.' (der Punkt nach der Addresse zeigt an das es ein 16bit Wert ist), Länge '10.' und 'e'. Z.b. <280. 10. e> zeigt 10 Byte ab Adresse 280 an.
Schreiben geht mit 'f'. z.b. <100. 255 f> schreibt das Byte 255 an Adresse 100 im EEprom.
Mit 'c' kann man den kompletten EEprom mit 00 voll schreiben.
Ein 'p' <Return> an der seriellen Konsole startet das Pairen mit FHEM. Die PairID wird dann in den EEprom geschrieben und fort an ist das Gerät gepaired.
Wenn ihr Strings versenden wollt dann geht das mit 's' <Return>. Ihr könnt auch an die eigene Addresse versenden - hier geht dann die Message nicht durch das Funkmodul sondern direkt in den Empangs Puffer. Ist ganz praktisch zum testen eigener Funktionen.
Anfordern der Config und der Peers aus FHEM läuft auch (nach dem pairen auf getConfig in FHEM drücken). Die Anfrage wird aus dem EEprom beantwortet. Eingetragene peers und die dazugehörigen List3'en werden ausgelesen und übertragen.
Was noch nicht geht und als nächstes dran kommt sind die Status Messages. Also automatisches versenden nach einer Änderung, oder auf Anforderung durch die Zentrale.
Die Library besteht aus 4 files:
sketch_aug05a.ino ist der Userbereich. Hier kann man die gerätespezifischen Funktionen programmieren.
register.h ist der Config Bereich, im oberen Teil sind die Variablen für Seriennummer usw. Im unteren Teil kommen die Register Definitionen rein. Also die Config für List0, List1 usw.
Martin hat hier ein klasse Config Tool in Perl gebastelt. Aber dazu wird er hoffentlich bald mehr erzählen :-)
Für später heisst das - die Gerätedefinition wird in dem Tool gemacht, der Output in die register.h kopiert und gut.
asksin.cpp und asksin.h, das ist der HM Kommunikations Bereich. Jegliches HM Handling soll hier statt finden und kein User Eingreifen benötigen.
So jetzt aber zum Userbereich:
Im Userbereich (das ist sketch_aug05a.ino) - gibt es einen "s_jumpTable jumpTable[]", hier werden die Funktionen angegeben die beim erreichen eines HM Events aufgerufen werden. Das Format für diesen Table ist "{ 0x40, HM_Remote_Event },".
40 steht für die Art des Events, 'HM_Remote_Event' ist der Name der Funktion in "sketch_aug05a.ino" die aufgerufen wird. Hier werden dann auch Channel und Daten übergeben.
Die List0 und List1 je Channel stehen im Userbereich in der Variablen 'regMC' zur Verfügung. Im der aktuellen Beispiel Config gibt es zwei Channels, somit gibt es in der regMC folgende Variablen:
regMC.ch0.intKeyVisib
regMC.ch0.pairCentral
regMC.ch1.intKeyVisib
regMC.ch2.intKeyVisib
Die genaue Config könnt ihr euch in der register.h anschauen, da sind die structs definiert.
Dann gibt es eine struct für die List3'en. Das sind die Variablen die man braucht wenn ein Ereignis über ein Peer ausgelöst wird.
Diese struct heisst 'regL3', besteht in unserem Beispiel aus zwei Channeln die unterschiedlichen Inhalt haben können. Im aktuellen Beispiel ist der Inhalt aber gleich.
regL3.ch1
regL3.ch2
Dahinter sind dann die ganzen Variablen pro Peer. Den genauen Inhalt könnt ihr euch in der register.h in der struct "s_peer_regChan" anschauen.
Das struct wird aber nur befüllt wenn ein Event über ein peer ausgelöst wird. Deshalb empfehle ich die Variablen nur in den Funktionen im "jumpTable" definiert, zu benutzen.
Was fehlt noch - ausgiebige Tests :-)
Statusmessages
Powermanagement
Lib als Aktor konfigurieren und die List4 im Userbereich zur Verfügung stellen.
Verknüpfung der Gerätespezifischen Variablen mit Aktionen in der asksin.cpp
Ach ja, fast vergessen. Ihr findet ganz oben in der register.h 4 Variablen für das debuggen.
//#define CC_DBG; // debug messages of the CC module, ~0.2k program space
//#define SM_DBG; // debug messages of the SM module, ~1k program space
#define AS_DBG; // debug messages of the HM module, ~0.6k program space
//#define AS_DBG_Explain; // debug messages of the HM module, ~5k program space
Wenn ihr die einschaltet bekommt ihr jede Menge Infos auf die serielle Konsole.
CC = Funkmodul
SM = Storage Management, ein Schelm wem was Anderes dazu einfällt
AS = Asksin oder eben HM Protokoll
AS Explain = zeigt eine Beschreibung der Binär Strings an
Viel Spass beim testen. Falls Fehler, oder Fragen nur her damit. Falls Programm Verbesserungen auch gern gesehen!!!!!
Hallo trilu
Danke für die ausfürliche Beschreibung und für die neue lib.
Die Details muss man natürlich erst einmal komplett verinnerlichen und verstehen ::)
Werde mal weitertesten und berichten !!
PS: Bitte ergänze noch den Helptext (f,r, etc.) in der nächsten Version.
Gruss Peter
Hi,
habe diesen Thread heute erst gefunden. Wenn ich das hier richtig lese, dann müsste ich ja zu einer bestehenden SChaltung mit einem ATMega32 (Puppenhaus mit 6 dimmbaren LED-Leuchten, einer Kaminfeuer LED mit Flimmereffekt, und einer Türklinkel (über Transistor angesteuert)) ein Tranceiver-Modul hinzufügen können und dann noch die Lib und einige Funktionen dafür einbauen können.
Ist allerdings batteriebetrieben mit 3 AA Batterien. Mit meiner jetzigen Software halten die Batterien 2-3 Jahre, zumal sich die Lichter bei Nichtnutzung ja abschalten und der Controller dann in so ein Deep Standby geht. Das dürfte wohl dann so nicht mehr gehen. Man bräuchte so ein Verhalten ähnlich der Thermostate mit Aufwach / Burst Modus.
Nun das nur gedanken...freue mich dass es so ein Projekt gibt. Werde mir das im Detail durchlesen!
VG
Hi unimatrix,
Zu deiner Frage, ein ganz klares Jein.
ATMega 32 dürfte zu klein sein. Die Lib braucht im Moment etwa 15 k Flash und etwa 1k Ram.
Das Powermanagement ist noch nicht implementiert, aber ich habe schon ein wenig getestet.
Der Arduino zieht etwa 3ma wenn er läuft, das Funkmodul etwa 17ma. Sind 20ma. Damit ist deine Batterie vermutlich in 1 oder 2 Tagen leer.
Ich möchte einen Mode für Batteriebetrieb implementieren der über den Watchdog läuft. Bei Nichtbenutzung gehen dann der Atmel und das Funkmodul in einen Tiefschlaf mit einigen uA. Wachen aber alle 300 ms wieder auf. Ziehen dann für einige ms etwa 20ma, wenn in der Zeit keine Übertragung rein kommt, dann wird weiter geschlafen. Damit dürfte eine Batterie dann auch ziemlich lange halten.
Viele Grüsse
Horst
Hallo trilu
Anbei ein paar Feedbacks:
- Der Befehl r (reset Device) führt bei mir nur zu einem lang (=unendlich) blinken der LED13
- Das HM Event (z.B. 0x40) ist das das Communication bit field oder der Messagetype ? Oder was ganz anderes :-) Habe mal die Source auf Rückmeldungen meiner Geräte (xx86, xx70 ) umgeschossen. Leider ohne Log-Erfolg.
- SetSleep und SetWakeup funktioniert schon mal ganz gut.
PS: Hat schon mal jemand gelauscht, wenn HM-Geräte via AES-Key kommunizieren ?
Gruss Peter
Hallo trilu,
danke für die Rückmeldungen. Das mit der Planung für den Batteriebetrieb klingt ganz gut. Wenn der ATMega zu klein ist, stört mich das weniger. Ich kann das Puppenhausboard auch neu machen. Wäre halt eine mal ganz andere lustige Anwendung dachte ich mir. Außerdem steht das bei uns an einer zentralen Stelle, ich könnte es auch als Fertigmelder für Waschmaschine/Trockner nehmen (also Licht blinken lassen), der MP3 Gong ist in einer anderen Etage verbaut...wäre jedenfalls eine lustige Sache für Besucher ein Puppenhaus zu haben, das blinkt, wenn der Trockner fertig ist *G*
Gibt es denn jetzt eine klare Referenzschaltung - die man sich selbst aufbauen muss?
VG
Hi Horst,
Zitat
Ich möchte einen Mode für Batteriebetrieb implementieren der über den Watchdog läuft. Bei Nichtbenutzung gehen dann der Atmel und das Funkmodul in einen Tiefschlaf mit einigen uA. Wachen aber alle 300 ms wieder auf. Ziehen dann für einige ms etwa 20ma, wenn in der Zeit keine Übertragung rein kommt, dann wird weiter geschlafen.
Ich meine der CC110x kann den Atmega auch per Interrupt aufwecken wenn er eine bestimmte Bytesequenz empfängt. Und ich denke, das ist bei den fertigen HM-Geräten die mit Batterie laufen so implementiert.
Gruß
Dirk
Hallo zusammen,
habt Ihr schon mal einen Test mit
1 Digitalen Eingang
1 Digitaler Ausgang
1 Analoger Eingang
1 Analoger Ausgang
gemacht. Was muss ich dabei beachten ?
lg
Stefan
Hi Peter,
eine Message 40 sieht so aus :-)
-> 0B 11 A4 40 22 66 08 2F B7 4A 01 06 (l:12)(1951)
Remote_Event; cnl: 01, data: 06
S- 0A 11 80 02 2F B7 4A 22 66 08 00 (l:11)(1961)
<- sendStr (1988)
Wird von Fernbedienungen und Wandschaltern verschickt wenn das Device gepeert ist...
Mit Reset mach ich eigentlich nichts Anderes als den Watchdog starten. Vielleicht muss der erst irgendwie initialisiert werden. Ich schau mir das mal an.
Viele Grüße
Horst
Hi Dirk,
Zitat von: Dirk am 29 Oktober 2013, 12:55:17
Ich meine der CC110x kann den Atmega auch per Interrupt aufwecken wenn er eine bestimmte Bytesequenz empfängt. Und ich denke, das ist bei den fertigen HM-Geräten die mit Batterie laufen so implementiert.
ich glaube nicht das es HM so macht. Der CC1101 zieht etwa 17ma in Empfangsmodus und er muss was empfangen um einen Interrupt auszulösen.
Das was es im CC1101 noch gibt ist ein Wake on Radio. Den werde ich mir mal anschauen.
Ich vermute aber, da es diesen Burst Modus gibt - im Burst wird 350ms ein Signal übertragen - dass HM einfach nur den Watchdog vom Arduino zum schlafen verwendet und das Funkmodul alle 300ms aufwachen lässt.
Ich muss mir das aber noch einmal genauer anschauen...
Viele Grüße
Horst
Zitat
Das was es im CC1101 noch gibt ist ein Wake on Radio. Den werde ich mir mal anschauen.
Der Burst wird gebraucht damit der CC1101 aufwacht. Erst wenn die gesendete Bytefolge stimmt, wird der AVR geweckt.
Gruß
Dirk.
sehe ich so nicht!
wenn der cc1101 schläft, dann empfängt er auch keinen burst.
zumindest steht das so im datenblatt...
aber wenn du andere infos hast, dann her damit
The optional Wake on Radio (WOR)
functionality enables CC1101 to periodically
wake up from SLEEP and listen for incoming
packets without MCU interaction.
When the SWOR strobe command is sent on
the SPI interface, the CC1101 will go to the
SLEEP state when CSn is released. The RC
oscillator must be enabled before the SWOR
strobe can be used, as it is the clock source
for the WOR timer. The on-chip timer will set
CC1101 into IDLE state and then RX state. After
a programmable time in RX, the chip will go
back to the SLEEP state, unless a packet is
received. See Figure 28 and Section 19.7 for
details on how the timeout works.
Ich bekomme beim compilen mit Arduino 1.0.1 folgende Fehlermeldung:
In file included from AskSin.cpp:7:0:
AskSin.h:298:39: error: variable 'cmdTab' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
AskSin.cpp: In member function 'void CC::init()':
AskSin.cpp:42:9: error: 'prog_uint8_t' does not name a type
AskSin.cpp:69:29: error: 'initVal' was not declared in this scope
Was mache ich falsch?
mhh, mir sagt die Fehlermeldung rein gar nichts.
Bei mir läuft das Kompilieren ohne Probleme - allerdings nutze ich Arduino 1.0.5
Versuch mal mit einer aktuelleren Version...
Zitat von: trilu am 29 Oktober 2013, 16:07:14
The optional Wake on Radio (WOR) ...
wie du schon geschrieben hast. WakeOnRadio. Der CC1101 schläft bis er durch den burst geweckt wird. Prüft die ersten Bytes und weckt bei Übereinstimmung den AVR. Wenn ich wieder zu Hause bin schau ich mal nach.
Gruß
Dirk
ZitatDer CC1101 schläft bis er durch den burst geweckt wird.
Das ist natürlich nur "bildlich" gemeint.
In Wirklichkeit wird der cc1101 im WOR nicht per Funk aufgewacht, sondern der wacht selbstständig z.B. alle 300ms auf um kurz zu lauschen ob Daten zu empfangen sind.
Daher muss der Sender dann auch einen Burst schicken, damit das Packet sicher in das Zeitraster passt.
Der CC1101 hat dafür so ein Feature namens Sync-Word-Check.
Zitat... On-chip support for sync word
detection, ...
The sync word is a 16 bit configurable field (can be repeated to get a 32 bit) that is automatically inserted at the start of the packet by the modulator in transmit mode.
Der Burst wird also ein entsprechendes Syncword senden.
Wenn das Syncword stimmt, dann weckt der Chip den AVR über GDO0, GDO1 oder GDO2
ZitatCC1101 can be set up to signal the MCU that a packet has been received by using the GDO pins.
Alles andere währ bei Batteriebetrieb auch "Energieverschwendung" Der AVR muss nur aktiv werden wenn es was zu tun gibt. Der bekommt schon die fertigen Daten und muss hier auch nix mehr decodieren. Der muss nur noch das Protokoll interpretieren.
Gruß
Dirk
Hallo trilu
Die events aus dem s_jumpTable jumpTable[] werden bei mir nicht angesprungen.
Weder dein genanntes Beispiel noch die 0x70 Ereignisse meiner Temperatursensoren führen hier zu serial log ?!
PS: Meine Paired-ID steht noch komischerweise auf "Paired: 00 00 00" ? Wurde schon mehrfach gepaired.
Gruss Peter
Mhh, mach mal bitte einen eeprom dump, schalte das debuggen für AS ein und poste die pairing sequenz.
Ach ja, und drücke t und zeig das ergebnis...
ich habe mich die letzten zwei tage mal ein wenig mit der burst geschichte und dem strom sparen gespielt, aber irgendwie bekomme ich die register settings für das cc1101 nicht hin.
hat jemand zufällig einen bus pirate und kann mal den spi port von einem batterie betriebenen aktor belauschen?
was ich bis jetzt rausgefunden habe läuft die kommunikation wohl so ab:
der master schaltet um auf transmit, wenn das anzusprechende device keinen burst braucht, wird 10ms gewartet, wenn der receiver ein burst device ist, dann wird 360ms in diesem zustand gewartet.
auf der receiver seite wacht wohl das funkmodul alle 300ms für ein paar ms auf und lauscht ob auf der hm frequenz ein burst signal gesendet wird, wird eins erkannt dann bleibt das funkmodul wach, wenn nicht legt es sich wieder schlafen.
leider werde ich aus dem datenblatt nicht wirklich schlau und für "trial and error" fehlt mir das mess equipment.
viele grüße
horst
Hi Horst.
ich habe zwar nur ein Logicanalyzer, aber ich meine die Software kann auch SPI decodieren. Ich schaue mir das mal an. Das wird aber erst Sonntag Abend.
Gruß
Dirk
super!
falls möglich - einer fernbedienung/schalter und einem schaltgerät :-)
wobei schaltgerät prio hat...
Hallo trilu
Das Einschalten von #define AS_DBG_Explain brachte die erwünschten Debug-Messages. Funktioniert !!
Sorry hatte wohl in deiner Ausführung überlesen, dass man es erst aktivieren muss ;D
Allerdings werden die s_jumpTable z.B HM_Weather_Event im sketch nicht ausgeführt?!
Der Eintrag paired ist nun komischerweise auch gefüllt !
Gruss Peter
und wieder mal ein update...
die library sollte jetzt stabiler laufen da ich den code ein wenig aufgeräumt habe.
pair und peer geht
config request und status request von der zentrale werden beantwortet
settings werden ins eeprom geschrieben und stehen im user bereich zur verfügung (ist aber noch baustelle)
peer events stehen im user bereich zur verfügung
der jumptable im userbereich hat jetzt nicht nur die events, also sowas wie die benachrichtigung das von
einer fernbedienung die taste gedrückt wurde, sondern auch für den status request der zentrale
und für alle kommandos die von der zentrale an ein device gesendet werden können.
was noch fehlt ist das power management und die funktionen um als aktuator konfiguriert zu werden....
viele grüße
horst
ps: bin gerade ganz begeistert - wenn man debug ausschaltet und den serial parser auch weglässt dann braucht
die lib 13,4k im arduino - also 43% belegt! es bleibt also jede menge platz für eigene sachen!
Danke Dir trilu,
Hab gerade das Update auf meinen arduino gespielt.
Pair mit Fhem hat problemlos geklappt.
Auch der Status Request von Fhem funtioniert.
Auch ich bin begeistert :-) :-) :-)
Hab gerade etwas wenig Zeit, um weiter zu testen.
Bleibe aber in jedem Fall drann.
Grüsse Martin
Ich glaube ich weiss jetzt wie der Burst Mode funktioniert. Laut den culw Sourcen wird für das Senden im Burst Mode nur umgeschalten in den TX Mode und 360 ms gewartet.
Der Wake on Radio Mode des CC1101 scheint aber anders zu funktionieren. Hier wird einach alle paar ms aufgewacht und gewartet das die Preamble Bits kommen. Falls nicht, geht der Chip wieder in Idle.
Die Lösung des Problems, ich schalte den CC1101 einfach aus, warte 250 ms, schalte ihn ein, gehe in den RX Mode und prüfe auf ein Carier Signal. Ist keins da, lege ich den Chip wieder schlafen. Ist eins da, dann lasse ich den Chip für eine definierte Zeit wach und lege ihn dann wieder schlafen....
Für den Stromverbrauch ist das eine prima Sache. Im RX Mode braucht der CC1101 etwa 17 ma. In Power down sind es einige wenige ua. Das lauschen dauert 5ms alle 250ms, folglich brauchen wir nur 2% der Zeit die 17ma.
Rechnerrisch müsste ich den Stromverbrauch auf 350 ua im Idle mode reduzieren können. Das würde für den Batteriebetrieb absolut passen.
Weiter reduzieren ist auch noch möglich durch verlängern der Idle azeit. Aber hier muss ich noch testen wie lange der HM Lan den Burst sendet...
Hallo trilu
Wann wird die s_jumptable jumptable Aktion (z.B. void HM_Weather_Event) im sketch getriggert?
Der #define AS_DBG_Explain triggert die entsprechende Routinen (z.B. 0x70) im AskSin.cpp.
Im Sketch bekomme ich diese einfach nicht aufgerufen ?!
Bitte gib mir mal einen neuen Insidertip ;)
Gruss Peter
Die Funktionen im jumptable werden immer dann aufgerufen wenn ein entsprechender String empfangen wird. Die Events sind alle den Peers zugeordnet. Der Weather Event kann also nur getriggert werden wenn dein Device mit einem Sensor gepeert ist, der einen Weather Event sendet.
AS_DBG und AS_DBG_Explain triggert nichts. Das sind Variablen um Debugmeldungen einzuschalten. Wenn AS_DBG definiert ist dann wird die Funkkommunikation an der seriellen Konsole angezeigt. AS_DBG_Explain zeigt zusätzlich die Erklärung zu den Byte Strings der Funkkommunikation.
Hi trilu,
Zitatich habe zwar nur ein Logicanalyzer, aber ich meine die Software kann auch SPI decodieren.
Ich habe die mal was mitgeschnitten und per PM geschickt.
Gruß
Dirk
Hallo trilu
Wie du beschrieben hast ist dein Sketch (über die register.h) als Dimmer konfigurtiert.
Wenn das device mit fhem gepairt ist, wird das device durch fhem auch angelegt.
Wenn ich nun ein "on" oder "off" von fhem sende, wird das über die Serielle Konsole von der Arduino IDE ausegeben.
Wo kann ich nun das "on" oder "off" abgreifen und für meine eigene Anwendung weiterverwenden ?
Wenn ich das richtig verstanden habe, werden die Funktionen der "jumptable" ja nur aufgerufen, wenn das device mit irgendwas gepeert ist.
Vielleicht hast Du ein kleines Beispiel.
Vielleicht bin ich mit meinem Wunsch auch etwas zu früh, dann einfach diesen Post ignorieren.
Grüsse Martin
ok, ok, - der jumptable scheint nicht wirklich selbsterklärend zu sein :-)
s_jumptable jumptable[] PROGMEM = { // jump table for HM communication
{ 0x01, 0x0E, HM_Status_Request },
{ 0x11, 0x02, HM_Set_Cmd },
{ 0x11, 0x03, HM_StopChange_Cmd },
{ 0x11, 0x04, HM_Reset_Cmd },
{ 0x11, 0x80, HM_Led_Cmd },
{ 0x11, 0x81, HM_Level_Cmd },
{ 0x11, 0x82, HM_SleepMode_Cmd },
{ 0x12, 0x00, HM_HaveData_Event },
{ 0x3E, 0x00, HM_Switch_Event },
{ 0x3F, 0x00, HM_TimeStamp_Event },
{ 0x40, 0x00, HM_Remote_Event },
{ 0x41, 0x00, HM_Sensor_Event },
{ 0x53, 0x00, HM_Sensor_Data },
{ 0x58, 0x00, HM_Climate_Event },
{ 0x70, 0x00, HM_Weather_Event },
{ 0x0 }
};
Derzeit gibt es drei verschiedene Kategorien im jumptable:
1 - der Statusrequest
2 - die Commands
3 - die Events
1. Statusrequest:
Ein Statusrequest kann nur von der Zentrale angefragt werden, also dem Pair.
Beantwortet wird er mit einem INFO_ACTUATOR_STATUS. Das ist die selbe Message die man auch proaktiv, nach dem Einschalten, oder nach einer Statusänderung des Devices senden muss.
Die jump - Funktion findest du in "sketch_aug05a.ino" als Funktion "void HM_Status_Request(uint8_t cnl, uint8_t *data, uint8_t len)".
Also, wenn du in FHEM Status request drückst, dann wird diese Funktion angesprungen, der Channel und die Statusdaten übergeben.
In der Funktion habe ich eine Status message drin
Serial << F("\nStatus_Request; cnl: ") << pHex(cnl) << F(", data: ") << pHex(data,len) << "\n\n";
Vor, oder nach dieser Zeile kannst du deinen eigenen Code platzieren.
In dieser Funktion muss der eigene Status dann gesendet werden, das passiert mit dem Aufrufen der Funktion:
hm.sendInfoActuatorStatus(cnl, status);
cnl: ist der Channel
status ist ein byte Wert, mehr Info kann über diese Funktion nicht transportiert werden.
2. Commands
Die Commands können nur von der Zentrale an unser Device gesendet werden. Z.b. wird die Funktion "HM_Set_Cmd " angesprungen wenn du in FHEM auf "toogle,on,off,up,down" drückst. Übergeben wird an die Funktion der Channel und der Statuswert.
Die Funktion findest du auch wieder in "sketch_aug05a.ino" als Funktion "void HM_Set_Cmd(uint8_t cnl, uint8_t *data, uint8_t len)".
Als Antwort auf alle Commands wird ein erweiterter ACK verwendet, der die Statusinformation enthält.
hm.sendACKStatus(cnl, status, douplo);
Ich habe das als Beispiel schon mal in die Funktion gepackt.
3. Events
Die Events werden nur von den Peers gesendet. Wen eine Remote oder ein Switch mit unserem Device gepeert ist und eine Taste gedrückt wird, dann bekommen wir einen "HM_Switch_Event". Die zugehörige Funktion findest du in "sketch_aug05a.ino" als Funktion "void HM_Switch_Event(uint8_t cnl, uint8_t *data, uint8_t len)".
Übergeben wird hier auch wieder der Channel und die gesendeten Daten. Bei einem Switch Event wird normalerweise der Channel des Peers als low byte übergeben. High byte enthält die Info ob es ein Tastendruck oder ein Langer Tastendruck war.
Antwort muss der User bei Events keine schicken, da die Message nur einen ACK erfordert und ich diesen automatisch sende.
Vom Grundsatz ist der Sketch so aufgebaut, das in Register.h die gerätespezifischen Sachen kommen, also die Register Definition.
Asksin.cpp und Asksin.h machen die Kommunikation im HM Netz, kein Usereingriff notwendig.
Das Programmieren der Device Funktionen findet in "sketch_aug05a.ino", also dem Userbereich statt.
Alles klar soweit?
Viele Grüße
Horst
Hallo Horst aka trilu,
ich habe mit großem Interesse diesen Thread durchgelesen und möchte schon jetzt in dieses Projekt einsteigen um Erfahrungen sammeln.
Im Moment scheitere ich etwas an der Hardware. Die HM-TRX868 Module habe ich (aus 2 Bausätzen), aber nur ein Arduino Leonardo Board. Da scheitere ich schon an der zum Arduino Uno und Pro Mini anderen Pin-Belegung (INT0 und 1 vertauscht, die MOSI/MISO-Pins nur am 6-poligen Anschluss). Einen Arduino Micro habe ich auch noch hier, den wollte ich mir mal Heute Abend angucken.
In deinem Code habe ich mal nachgeschaut und auch die Stellen gefunden, wo die Port/Pin-Definitionen stehen, aber das sind ein wenig böhmische Dörfer für mich.
Könnten die Port/Pin-Definitionen statt an unterschiedlichen Stellen nicht besser an einem zentralen Ort stehen?
Wäre es möglich, diese je nach verwendetem Arduino-Board per
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
# Port=
# PIN=
#elif defined(__AVR_ATmega328P__)
# Port=
# PIN=
#endif
zu belegen bzw. kompilieren zu lassen?
Danke und Gruß
Thomas
@Rohan: beachte auch, dass das TRX-Modul nur 3,3 Volt beherrscht! Wenn du da mit einem 5-Volt Arduino ankommst, grillst du wahrscheinlich das Teil!
Ich habe auch schon über die Flexibilisierung der HW nachgedacht, ist aber auf der Prio Liste erst mal nach hinten gerutscht.
Ist einfach eine lästige Arbeit die verschiedenen Pinbelegungen zu vergleichen :-)
Es gibt derzeit zwei Stellen im Code an denen HW definiert wird - beide male in der Asksin.h
In der Class Definition CC die zusätzlichen Angaben zur Kommunikation über SPI
// Hardware definition
#define PORT_SPI_MISO PINB
#define BIT_SPI_MISO 4
#define PORT_SPI_SS PORTB
#define BIT_SPI_SS 2
#define GDO0 2
In der Class Definition HM die Angaben zum Interrupt 0, oder Pin 2
// hardware definition for interrupt handling
#define GDO0 2
#define PORT_GDO0 PIND
#define BIT_GDO0 2
#define INT_GDO0 0
Ich sehe gerade, der Leonardo benutzt eine ATmega32u4 CPU mit 5 Volt. Das heisst du musst Level Converter zwischen Funkmodul und CPU basteln, sonst grillst du das Funkmodul. Die Funkmodule vertragen nur eine Spannung zwischen 1,8 und 3,6 Volt.
Die Anpassung der HW Pins bekommst du allein durch den Vergleich der Datenblätter hin, ist wie gesagt, eine Fleißarbeit.
Viele Grüße
Horst
Hallo shaddi,
hallo Horst,
Eure Warnungen kommen wohl leider zu spät (aber die waren ja schon im Thread gewesen), denn ich habe noch einen UNO gefunden. Ich habe nicht dran gedacht, dass ja nicht nur die Stromversorgung 3,3 V (die ja die 5V Arduinos alle bieten) max. betragen sollte, sondern wohl auch die Spannungen auf den Signal-/Daten-/IO-Leitungen ::)
Egal, Lehrgeld bezahlt (werde das Modul aber dennoch mal im Bausatz testen) ... Weiter geht's 8)
Und bevor ich jetzt mit Level Convertern anfange, besorge ich mir lieber doch ein paar 3,3 V Mini-Pros ;)
Gruß
Thomas
Edit:
Nachtrag: Das HM-TRX868 Modul hat keinen Schaden genommen. Testaufbau mit dem Bausatz funktionierte in Sende- und Empfangsrichtung :)
Es bleibt aber dabei: 3,3 V Arduinos müssen ran.
Hallo trilu,
vielen Dank für die genaue Bechreibung der jumptable.
Ob alles klar ist, denke nicht ganz alles, aber das liegt an mir :-)
Hab gerade ne LED auf dem arduino über fhem ein und ausgeschaltet.
Geil :-)
Grüsse Martin
Hallo Martin.
Auch schon eine zweite probiert zu steuern ?
Gruss Peter
Hallo Peter
Wenn man zwei LED unabhängig voneinnander schalten möchte, könnte man die Dimmer-Werte "misbrauchen"
zb. dim-wert 10 schaltet LED1, dim-wert 20 schaltet LED2...
Ich versuche als nächstens am Arduino eine Taste anzuschliessen und mit der Taste "on" und "off" an fhem zu senden.
Mache mir aber keinen Stress, habe noch den ganzen Winter Zeit :-)
Grüsse Martin
Du könntest auch den zweiten Kanal nutzen. Derzeit ist der Sketch auf zwei Kanäle konfiguriert. Mit zwei peer tables. Man müsste FHEM nur sagen, dass noch ein weiterer Kanal da ist ;D
Hallo trilu
Danke für den Tip :-)
Ick kann bei allen Sensoren etc. mitlauschen.
Wenn aber bei mir einmal die HM_Set_Cmd durchlaufen wird, kommen keine Nachrichten mehr an ?!
D.h. es wird auf dem Serial still ???
Reset und alles geht wieder, bis einmal der HM_Set_Cmd ausgeführt wird ...
Gruss Peter
mhhh, still werden ist nicht gut!
das hört sich so an als würde das programm in irgend einer loop hängen bleiben.
schalte mal den cc_dbg ein, hier ist der receive interrupt gesteuert. d.h. wenn das programm in einer loop hängt müsstest du zumindest eine nachricht aus dem interrupt bekommen und ich hätte einen anhaltspunkt zum checken...
wenn ich dazu komme, bau ich mal aus dem derzeitigen example sketch einen einfachen dimmer.
vielleicht hilft das den hier beteiligten beim verstehen was ich mit dem jumptable mache :-)
Hallo trilu
Der "cc_dbg" lässt sich nicht aktivieren !
Compilingfehler:
...\libraries\AskSin\/AskSin.h: In function 'Print& operator<<(Print&, T) [with T = char (*)()]':
...\libraries\AskSin\AskSin.cpp:169: instantiated from here
...\libraries\AskSin\/AskSin.h:357: error: call of overloaded 'print(char (*&)())' is ambiguous
Läuft der bei dir ?
Gruss Peter
jetzt schon :-)
ich habe zwei klammern vergessen.
schau mal in asksin.cpp in der funktion
uint8_t CC::receiveData(uint8_t *buf) {
ziemlich weit unten
#if defined(CC_DBG) // debug message, string should be short, otherwise program stops
if (buf[0] > 0) Serial << pHex(&buf[1], buf[0]) << pTime();
#endif
und mach bei pTime die zwei klammern ran...
Hallo Zusammen,
ich habe mal auf die schnelle einen Dimmer gebastelt :-)
Ist recht einfach gehalten, LED kann Ein- oder Ausgeschaltet werden oder in 20 Schritten gedimmt werden.
Egal ob von FHEM oder einer Fernbedienung.
Als Pin für die LED verwende ich Pin3 - also einen PWM Ausgang.
Viel Spass beim testen....
Horst
hey, kommt schon - 7 mal runter geladen und kein feed back?
Hallo trilu
ist auf Pin3 nicht GD02 vom TRX868 ?
(siehe Deinen ersten Post)
Hast Du für die LED noch einen Vorwiderstand genommen ?
Gruss Martin
Ne, GD02 wurde wieder frei gemacht, weil beim PanSTAMP dieser auch nicht belegt ist. Bei mir klappt die Version super!
Habe ein 180Ohm Widerstand in Reihe geschaltet.
Ich lese mich aktuell in das Protokoll ein, um zu verstehen, was, wie und wann übertragen wird..
@shaddi
Ach so, hab die Stelle im Tread zwar gefunden, bin aber nicht ganz schlau daraus geworden.
Also GD02 ist nun frei, und was ist mit GD00, ist und bleibt der (beim Arduino) auf Pin2 ?
@trilu
Dein LED Dimmer läuft. (getestet ab fhem, Fernebdienung habe ich keine.)
Klasse :D
Gruss Martin
vorwiderstand brauchst du nur wenn die led spannung kleiner 3.3 volt ist.
ich habe zum testen eine blaue led dran, die brauchen 3.3 - 3.6 volt, damit brauche ich keinen vorwiderstand.
ist ja auch erst mal nur zum testen ob die software passt und das protokoll stimmt.
die led ist somit nur ein platzhalter für einen mosfet, damit kann man dann schön led lampen, oder diese stripes dimmen.
das trx868 modul hat einen GDO0 und GDO2 ausgang, beide sind einigermaßen frei konfigurierbar. anfangs hatte ich beide angeschlossen. um die library aber panstamp kompatibel zu halten habe ich dann GDO0 abgeschaltet.
somit brauchen wir derzeit auch nur den Pin2 am Arduino für GDO2. Pin3 ist frei.
mein ziel ist es in absehbarer zukunft einen rgb dimmer zu basteln. der arduino hat aber nicht wirklich viele pwm ausgänge, insofern bin ich froh das der pin3 jetzt frei ist :-)
Hallo trilu
Die letzen 2 Versionen laufen bei mir nicht mehr richtig:
Der Sketch startet mit:
Serial: PS00000001, Model ID: 00 57 , HMID: 2F B7 4A
Paired: F1 47 12
FreeMem: 1232 byte's
S- 0E 00 A4 10 2F B7 4A F1 47 12 06 01 00 00 00 (l:15)(1189)
<- sendStr (1191)
<- sendStr (1492)
<- sendStr (1793)
-> NA (2093)
dann ist Feierabend !
Habe nun mal einen downgrade auf die Version 131027 gemacht.
Sketch läuft !! Upgrade auf 131109. Sketch bleibt hängen !!
define CC_DBG aktiviert !!
Ergebnis:
Port open
CC1101_init: 12..............................................3 - ready
Available commands:
p - start pairing with master
b[0] b[n] s - send a string, b[0] is length (50 bytes max)
i[0]. i[1]. e - show eeprom content, i[0]. start address, i[1]. length
i[0]. b[1] f - write content to eeprom, i[0]. address, i[1] byte
c - clear eeprom complete, write 0 from start to end
t - gives an overview of the device configuration
$nn for HEX input (e.g. $AB,$AC ); b[] = byte, i[]. = integer
Serial: PS00000001, Model ID: 00 57 , HMID: 2F B7 4A
Paired: F1 47 12
FreeMem: 1232 byte's
S- 0E 00 A4 10 2F B7 4A F1 47 12 06 01 00 00 00 (l:15)(1189)
<- 0E 76 F6 C2 B1 3A 5C C9 B0 8E 6C 49 25 01 A4 (l:15)(1199)
<- sendStr (1202)
<- 0E 76 F6 C2 B1 3A 5C C9 B0 8E 6C 49 25 01 A4 (l:15)(1501)
<- sendStr (1502)
<- 0E 76 F6 C2 B1 3A 5C C9 B0 8E 6C 49 25 01 A4 (l:15)(1803)
<- sendStr (1804)
-> NA (2104)
Mehr passiert nicht mehr ! Es werden direkt nach der Sequence keine Sensoren mehr erkannt und Befehle ausgeführt (endlos-loop) ?
Die Hardware ist ein Arduino Nano 328
Hast du noch einen Tip für mich :-)
Gruss Peter
@ trilu
Alles kar, habe hier nochmals die Pinbelegung für (Arduino Mini Pro 3.3V) den LED Dimmer Sketch:
kurze aber breitere TRX868 Variante:
TRX868 Arduino Description
1 11 SPI Mosi
2 13 SPI SCK
3 12 SPI MISO
5 2 GD00
6 10 SPI chip select
7 GND GND
8 VCC 3.3V
- 3 PWM ---LED---GND
schmale aber längere TRX868 Variante:
TRX868 Arduino Description
1 VCC 3.3V
2 GND GND
3 11 SPI Mosi
4 13 SPI SCK
5 12 SPI MISO
7 2 GD00
8 10 SPI chip select
- 3 PWM ---LED---GND
Gruss Martin
Hallo mmatt
Es gibt 2 Varianten des TRX868.
https://github.com/ccier/openhm/wiki/Trx868
Deine ist vermutlich die kurze aber breitere Variante.
Ich nutze z.B. die schmale aber längere Variante:
TRX868 Arduino Description
1 VCC 3.3V
2 GND GND
3 11 SPI Mosi
4 13 SPI SCK
5 12 SPI MISO
6 FREI GDO2 (function programmable, see CC1100 datasheet)
7 2 GDO0 (function programmable, see CC1100 datasheet)
8 10 SPI chip select (low active)
Gruss Peter
Hallo PeterS
Da hast Du recht, ich hab´s (hoffentlich richtig) in meinem Post ergänzt.
Gruss Martin
Hallo Peter,
ist schwierig zu sagen, eine der größeren Änderungen zu der Zeit war, das ich checke ob der sketch ein Pair hat.
D.h. es werden nur noch Nachrichten von einem eingetragenem Pair oder Peer akzeptiert.
Loops sollte es mit dem neuen sketch nicht mehr geben.
Stimmt denn das eingetragene Pair? - F1 47 12
Das was ich in den geposteten logs sehe ist, es wird etwas weg geschickt, aber nichts empfangen...
Schalte mal das #define AS_DBG; ein - dann sollte zumindest alles empfangen werden was so an HM Messages bei dir in der Luft rumschwirrt...
Viele Grüße
Horst
Zitat von: PeterS am 10 November 2013, 17:02:37
Hallo trilu
Die letzen 2 Versionen laufen bei mir nicht mehr richtig:
Der Sketch startet mit:
Serial: PS00000001, Model ID: 00 57 , HMID: 2F B7 4A
Paired: F1 47 12
und wieder ein kleines update - hatte einen bug in der routine beim hinzufügen von peers...
zusätzlich gibt es jetzt eine funktion um als remote zu agieren.
mit dieser funktion kann man einen event an alle eingetragenen peers pro kanal senden.
diese funktion wird gebraucht wenn unser demo nicht ein aktuator sondern z.b. eine remote oder ein sensor ist...
Hallo trilu
Habe nun deinen neuesten Sketch (131111-1) am Laufen alle Debugs eingeschaltet.
Alle Geräte werden wieder erkannt und das Lauschen funktioniert soweit.
Du hast den GDO2 nun auf Pin 2 umgezogen, damit der Pin3 für die LED frei wird, richtig ?
Überprüfe gerade mal wieder, warum bei mir nun wieder kein pairing mehr geht ?? :-(
Gruss Peter
Zitat von: PeterS am 11 November 2013, 21:43:00... Du hast den GDO2 nun auf Pin 2 umgezogen, damit der Pin3 für die LED frei wird, richtig ? ...
Soweit ich das mitbekommen habe, ist der GDO2 nicht umgezogen, sondern nicht mehr verbunden. Arduino Pin 2 hätte somit also nach wie vor Verbindung zum GDO0 des TRX868.
Gruß
Thomas
Hallo Rohan
Der Erste Eintrag beinhaltet folgende Auflistung:TRX868 Arduino Description
1 11 SPI Mosi
2 13 SPI SCK
3 12 SPI MISO
4 3 GDO2
5 2 GDO0
6 10 SPI chip select
7 GND GND
8 VCC 3.3V
Ich hatte bisher den GDO2 auf Pin3 und nun auf Pin2 geändert.
Gruss Peter
Hallo Peter,
gerade nochmal nachgelesen:
Zitat... das trx868 modul hat einen GDO0 und GDO2 ausgang, beide sind einigermaßen frei konfigurierbar. anfangs hatte ich beide angeschlossen. um die library aber panstamp kompatibel zu halten habe ich dann GDO0 abgeschaltet.
somit brauchen wir derzeit auch nur den Pin2 am Arduino für GDO2. Pin3 ist frei.
Beitrag => http://forum.fhem.de/index.php/topic,14140.msg106307.html#msg106307 (http://forum.fhem.de/index.php/topic,14140.msg106307.html#msg106307)
Du hast also danach Recht. Sorry für evtl. Verwirrungen.
Gruß
Thomas
Ok, jetzt ist die Verwirrung komplett :)
Laut Schaltplan (gerade noch mal kontrolliert) ist am Panstamp nur GD0 verbunden mit PD2 am Atmel/Arduino. GD2 wird nicht verwendet!
Wenn trilu also die Library PanStamp-Kompatibel gemacht hat, sollte das auch so verbunden sein. Ich vermute sein Posting hatte einen typo oder hier stimmt tatsächlich etwas nicht...
Entschuldigt bitte die Verwirrung. Natürlich ist GDO0 an Pin2. Ich habe es verwechselt, da GDO0 die Registeradresse 0x02 hat und GDO2 hat die 0x00.
Also GDO0 muss an Pin2
Hallo zusammen
hat schon jemand die Library mit dem Modul
http://www.busware.de/tiki-index.php?page=ARDCSM
getestet ?
lg
Stefan
Das Board von Busware wird mit der Library nicht ohne größere Änderungen funktionieren.
Zuerst mal, hat das Huckepack Board eine eigene Firmware und wird über RX/TX, also seriell gesteuert.
Meine Lib kommuniziert direkt mit dem Funkchip auf dem Panstamp.
Man könnte jetzt die Firmware auf dem Board ersetzen und das Board stand alone betreiben.
Dafür müsste aber erst mal ein Arduino Bootloader aufgespielt werden, zusätzlich sind Änderungen an der Lib bzg. der Pins nötig.
Die Lib ist derzeit für einen AVR328, das Board hat einen ATMEGA1248...
Ausserdem macht es wenig Sinn weil die Lösung viel zu teuer ist :-)))))))
Hallo Trilu
schade :(
Kannst Du mir bitte nochmal die Bezugsadresse der Module nennen. Panstamps sind zur Zeit auch nicht lieferbar.
Gibt es eigentlich schon eine Wiki Seite zu diesem Thema ?
lg
Stefan
Hi,
Zitat von: Stefan M. am 12 November 2013, 12:04:13... Gibt es eigentlich schon eine Wiki Seite zu diesem Thema ?...
Ist in der Pipeline, habe auch schon Verkabelungsschematas mit Fritzing gemacht. Aber ich lasse gerne anderen den Vortritt ;)
Evtl. aber noch etwas zu früh für das Wiki?
Gruß
Thomas
Edit: Gerade nochmal im Code nachgesehen. In der Asksin ist ein Hinweis auf Opensource (MIT-Lizenz) enthalten. Im INO-Sketch von Trilu steht nichts bezüglich Lizenzrechten. Wäre evtl. vor Verwendung im Wiki zunächst zu klären...
Falls sich hier jemand findet der Spass daran hat eine Dokumentation zu machen oder ein Wiki zu pflegen, dann gerne!
Für mich ist das proggen ein Ausgleich zur Arbeit, und ganz ehrlich, neben Arbeit, Kinder, Frau, sonstige Verpflichtungen bleibt nicht wirklich viel Zeit. Aber das kennt ihr hier bestimmt alle....
Mein Lib soll jeder der Spass daran hat auch nutzen und weiter entwickeln können. Ich möchte nur eins vermeiden, dass irgendjemand einen wirtschaftlichen Nutzen zieht.
Also, wie geschrieben - Falls sich jemand findet, der Spass am Dokumentieren hat, dann herzlich gerne.
Ich werde auch nach Kräften unterstützen!
Hallo Stefan,
falls du etwas löten kannst würde ich dir das Homematic Schaltmodul für 16,95, oder den Max Fensterkontakt für 13,95 von ELV empfehlen. Das Funkmodul dann einfach an einen Arduino und gut.
Alternativ gibts beim Chinesen Funkmodule, ich habe sie aber noch nicht geliefert bekommen, kann also nichts über Qualität, etc sagen. 5 Module müssten die nächsten Tage ankommen, weitere 25 in etwa 4 Wochen :-))))
Ich habe jetzt doch den größeren Posten bestellt, da die Lib ganz gut funktioniert und ich einiges umrüsten möchte....
Viele Grüße
Horst
Zitat von: Stefan M. am 12 November 2013, 12:04:13
Hallo Trilu
schade :(
Kannst Du mir bitte nochmal die Bezugsadresse der Module nennen. Panstamps sind zur Zeit auch nicht lieferbar.
Gibt es eigentlich schon eine Wiki Seite zu diesem Thema ?
lg
Stefan
Hallo trilu,
Zitat von: trilu am 12 November 2013, 13:11:37.... Mein Lib soll jeder der Spass daran hat auch nutzen und weiter entwickeln können. Ich möchte nur eins vermeiden, dass irgendjemand einen wirtschaftlichen Nutzen zieht. ...
Saubere Einstellung! Und ja, ich kenne das mit dem Ausgleich zu den sonstigen "Zeitvertreiben" ;)
Dann dürfte aber Opensource nicht das Richtige sein. CC BY-NC-SA (Link: http://creativecommons.org/licenses/by-nc-sa/3.0/de/ (http://creativecommons.org/licenses/by-nc-sa/3.0/de/) würde aber z.B. - wie von dir gewollt - eine kommerzielle Nutzung ausschließen. Sollte passen. Vlt. könntest du dann bereits jetzt einen entsprechenden Hinweis in deinen Codeteilen anbringen?
Gruß
Thomas
Vielen Dank. Werde ich machen...
ist auch noch nichts verloren, bisher ist die Lib noch nicht gut genug für einen produktiven Einsatz.
Es fehlt aber nicht mehr viel 8)
Hallo trilu.
Deine Einstellung finde ich auch gut.
Wird eigentlich immer besser die library.
Bevor ich über eine produktive Nutzung nachdenke,
muss ich nach den GDO?-Diskussionen
erst einmal weiter mein pairing Fehler suchen. :o
Cool wäre auch eine Multi-Device Definition.
Dann könnte der Arduino abhängig von den verfügbaren Ports und Speicher mehrere Geräte emulieren *träum*
Gruss Peter
Vielleicht bist du mit dem Arduino zu nah am Sender?
Ich habe bei mir festgestellt das es min. 0.5 meter abstand braucht, damit der Funk sauber arbeitet...
Ein Multidevice wird es vermutlich nicht geben, das gibt aus meiner Sicht das Protokoll nicht her. Was ich aber demnächst mal testen will ist eine schaltbare Steckdose die den Stromverbrauch misst. Zusätzlich dann auch die Koppelung beider Kanäle um bei stand by Stromaufnahme die Steckdose automatisch abzuschalten.
Ein weiteres Projekt ist dann noch ein RGB Dimmer.
Ach ja - nachdem ich noch einige Temperatursensoren, Druckmesser und Feuchtemesser zu Hause habe wird es vermutlich auch eine Wetterstation geben....
Ich hätte ja noch so viele Ideen ::)
Hallo trilu
Mit Multidevice meinte ich x Devices in einem Arduino (z.B. Temperatursensor mit HMID, Türkontakt mit HMID, Aktor mit HMID) zu emulieren.
Das sollte doch möglich sein, da man ja dies schon manuell senden kann.
Gruss Peter
PS: Bin weiterhin auf Fehlersuche ::)
Leider nicht so einfach. Im Moment ist die Lib als single Device but Multi channel ausgelegt.
D.h. du kannst ein Device mit mehreren Funktionalitäten bauen....
Hallo trilu
Bin weiterhin auf der Fehlersuche, warum das pairing auf meinem Arduino nicht mehr klappt.
Habe mal verschiedene Entwicklungsstände auf meinen Arduino Nano probiert.
Nach der Version 131027 funktioniert das Pairing nicht mehr ?!
In den neueren Versionen verschluckt er auch teilweise 70er-Meldungen (Wetter).
Diese sind nicht gepaired aber das Debugging ist aktiviert.
Verdrahtungsfehler habe ich übergeprüft.
Momentan läuft das Lauschen wieder auf Version 131027.
Hast du noch einen Tip für mich.
PS: Kann es sein das mein Arduino + CC1101 doch den GDO2 für Pairing oder Senden benötigen ?
Gruss Peter
Hallo trilu
Erneute Test mit dem sketch 131111-1 mit allen debugs lauscht der Arduino solange, bis ich "P"durchführe.
Dann geht nix mehr ?!
Habe im Sketch mal nacheinander die Powersettings deaktiviert. Leider ohne Erfolg ;)
Komme hier irgendwie nicht wirklich weiter.
Der Sketch 131027 läuft problemlos
Gruss Peter
Port open
CC1101_init: 12..............................................3 - ready
Loading PeerDB, starts: 2, size of: 48
getSliceDetail, slcPtr: 0, slcLen: 2, phyAddr: 0, phyLen: 4, peerIdx: 0
getSliceDetail, slcPtr: 2, slcLen: 1, phyAddr: 4, phyLen: 1, peerIdx: 0
getSliceDetail, slcPtr: 15, slcLen: 1, phyAddr: 137, phyLen: 1, peerIdx: 0
Available commands:
p - start pairing with master
b[0] b[n] s - send a string, b[0] is length (50 bytes max)
i[0]. i[1]. e - show eeprom content, i[0]. start address, i[1]. length
i[0]. b[1] f - write content to eeprom, i[0]. address, i[1] byte
c - clear eeprom complete, write 0 from start to end
t - gives an overview of the device configuration
$nn for HEX input (e.g. $AB,$AC ); b[] = byte, i[]. = integer
Serial: PS00000001, Model ID: 00 57 , HMID: 2F B7 4A
Paired: 00 00 00
FreeMem: 1167 byte's
9E FC A8 98 BC 49 25 01 DD B9 A3 DE (l:12)(13554)
l> 0C E8 86 70 1C C8 D1 00 00 00 00 36 58 (l:13)(13561)
WEATHER_EVENT; temp: 00 36, hum: 58
S- 1A 00 A2 00 2F B7 4A 00 00 00 10 00 57 50 53 30 30 30 30 30 30 30 31 9F 41 01 01 (l:27)(26399)
DEVICE_INFO; fw: 10, type: 00 57, serial: 50 53 30 30 30 30 30 30 30 31
, class: 9F, pCnlA: 41, pCnlB: 01, na: 01
<- 1A 76 F0 CC 87 D4 FA D6 B2 8E 7A 56 65 11 BE AA B6 A2 4E 1A C6 92 5F A4 C1 9C A3 (l:27)(26439)
<- sendStr (26443)
<- 1A 76 F0 CC 87 D4 FA D6 B2 8E 7A 56 65 11 BE AA B6 A2 4E 1A C6 92 5F A4 C1 9C A3 (l:27)(26746)
<- sendStr (26749)
<- 1A 76 F0 CC 87 D4 FA D6 B2 8E 7A 56 65 11 BE AA B6 A2 4E 1A C6 92 5F A4 C1 9C A3 (l:27)(27053)
<- sendStr (27056)
-> NA (27354)
sooo...
ich war so frei und habe im Wiki den Beitrag zur Asksin-Library begonnen: Link => http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library (http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library)
Anmerkungen, Fehlerhinweise, Korrekturen und konstruktive Kritik(en) bitte nicht in diesem Thread, sondern bevorzugt als PN, sonst wird dieser Thread evtl. kaputt gemacht. Es steht natürlich jedem frei, den Wiki-Beitrag zu ändern, ggfls. nach Anmeldung bei den Wiki-Admins (Link => http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren (http://www.fhemwiki.de/wiki/FHEMWiki:Administratoren))
Bitte beachten, dass dies nur der "erste Aufschlag" im Wiki ist. Ich werde nach und nach noch einiges einbauen/erweitern/ergänzen ...
Gruß
Thomas
Hi Peter,
Zitat von: PeterS am 12 November 2013, 23:24:08... Erneute Test mit dem sketch 131111-1 mit allen debugs lauscht der Arduino solange, bis ich "P"durchführe.
Dann geht nix mehr ?! ...
Habe heute auch den Sketch "131111-1_sketch_aug05a" ausprobiert und keine Problem
e. Auch nach "p" wird weiter gelauscht. Ich habe allerdings
1. die alte Verkabelung, also incl. GDO2
und
2. an dem alten Pairing nicht
s geändert.
Gruß
Thomas
Edith: Ein "s" und ein "e" gekauft ;) Ist schon spät ... N8
Hi Rohan
Die alte Verkabelung kann eigentlich nix mehr bringen, da der Sketch GDO2 am Pin3 nicht mehr unterstützt.
Mich würde mal interessieren, ob es auch funktioniert, wenn auf alle Settings+Eeprom ein Reset durchgeführt wird.
Gruss Peter
Hi Peter,
ich zitiere dich mal aus einem Beitrag etwas weiter oben ;)
ZitatPS: Kann es sein das mein Arduino + CC1101 doch den GDO2 für Pairing oder Senden benötigen ?
und jetzt schreibst du:
Zitat von: PeterS am 12 November 2013, 23:46:02... Die alte Verkabelung kann eigentlich nix mehr bringen, da der Sketch GDO2 am Pin3 nicht mehr unterstützt. ...
8)
Was spricht gegen einen einfachen Test? Und nimm mal einen Original-Sketch, in dem du noch nichts geändert hast.
Ansonsten kann nur trilu etwas sagen, denn ich bin fern von meinen Gerätschaften.
Gruß
Thomas
Hallo Rohan
Nutze zur Zeit nur unveränderte Sketche von trilu, bis ich meinen Fehler befunden und behoben habe.
Bis sketch 131027 funktioniert alles reibungslos (Pairing, Lauschen, etc.). Somit kann ich einen Hardwarefehler ausschliessen.
Der neueste sketch 131111-1 nutzt den GDO2 nicht mehr, somit wurde der Pin3 frei und gleich wieder für die Steuerung der LED verwendet.
Mit meiner Aussage "... Die alte Verkabelung kann eigentlich nix mehr bringen, da der Sketch GDO2 am Pin3 nicht mehr unterstützt. ... " meinte ich, dass der PIN3 nun halt für die LED verwendet wird !
Gruss Peter
Zitat von: PeterS am 07 November 2013, 22:42:46
Hallo trilu
Danke für den Tip :-)
Ick kann bei allen Sensoren etc. mitlauschen.
Wenn aber bei mir einmal die HM_Set_Cmd durchlaufen wird, kommen keine Nachrichten mehr an ?!
D.h. es wird auf dem Serial still ???
Reset und alles geht wieder, bis einmal der HM_Set_Cmd ausgeführt wird ...
Gruss Peter
Hallo Peter
Was hast Du den alles für Sensoren ?
Kann es sein, dass einer Deiner Sensoren irgendwas sendet, was den Sketch von trilu zum "einfrieren" bringt ?
Versuch doch mal die Sensoren wegzunehmen, und dann mach das Pairing nochmals.
Gruss Martin
Hallo mmatt
Den Versuch habe ich schon unternommen.
Die Wettersensoren senden alle 3-20 Minuten. Die restlichen Sensoren nur bei Aktionen (Auf, Zu bzw. Lageänderung).
Wie gesagt, bis sketch 131027 funktioniert das pairing inkl Lauschen. Danach nur noch Lauschen, und nach dem "p"-Versuch gar nix mehr.
Gruss Peter
was kann den das sein... :-\
Blöde Frage, du hast fhem schon im "Pairing-Requests-Modus" bevor Du das 'p' absetzt ?
Oder giebt es einen Unterschied zwischen Deinem Arduino nano und dem Arduino mini pro ?
Hat der nano auch die 3.3V für das TRX Modul ?
Oder hat das etwas mit der eingesetzten Arduino-IDE (Compiler) Version zu tun ?
Gruss Martin
Also
Ich schalte fhem (CUL) in den pairing modus und setze dann auf dem Arduino Nano den "p"-Befehl ab.
Das mache ich bei allen sketch versionen so und bis sketch 131027 funktioniert es auch. Den IDE-Compiler kann ich mal auschliessen.
Ich tippe mal auf ein Register, Powersetting, etc. - also was Softwaremässiges ??? Hier gibt es sicherlich Unterschiede zwischen dem Arduino nano und dem Arduino mini pro ?!
Ich hoffe trilu hat noch einen Tip für mich.
Gruss Peter
Hallo trilu
Habe gerade mal folgenden Befehl abgesetzt und dem letzen Wert (Luftfeuchtigkeit) mal ein wenig modifiziert:
$0C $E8 $86 $70 $1C $C8 $D1 $00 $00 $00 $00 $36 $58 s
s: 0C E8 86 70 1C C8 D1 00 00 00 00 36 58 (l:13)
<- 0C 9E FC A8 98 BC 49 25 01 DD B9 A3 DE (l:13)(52184)
<- sendStr (52187)
s: 0C E8 86 70 1C C8 D1 00 00 00 00 36 48 (l:13)
<- 0C 9E FC A8 98 BC 49 25 01 DD B9 A3 CE (l:13)(56689)
<- sendStr (56692)
s: 0C E8 86 70 1C C8 D1 00 00 00 00 36 38 (l:13)
<- 0C 9E FC A8 98 BC 49 25 01 DD B9 A3 BE (l:13)(60442)
<- sendStr (60445)
Fhem reagiert hier prompt !!
D.h. für mich: Empfangen geht, Senden geht, aber kein Pairing !
Gruss Peter
ich werd mir das pairing noch einmal anschauen, also mal den eeprom von meinem arduino löschen um einen sauberen grundzustand zu bekommen.
die power settings spielen keine rolle, die laufen eigentlich noch ins leere.
du könntest mal eins testen - eeprom löschen und den arduino neu starten.
den entsprechenden geräte eintrag in fhem löschen und neu starten.
danach mit deinem cul in den pairing modus und dann am arduino das p drücken.
zum debuggen brauchst du eigentlich nur das flag AS-DBG frei schalten.
CC dbg gibt nicht wirklich viele infos und verschandelt das log file.
und noch mal zur pin2 GDO0 diskussion. es reicht wenn pin GDO0 an pin2 hängt, GDO2 ist abgeschaltet.
hab gerade noch einmal nachgeschaut, da du von einem arduino nano schreibst - mich wundert das es funktioniert :-)
arduino nano arbeitet mit 5 volt ttl pegel, das funkmodul arbeitet aber mit nur bis 3,6 volt ....
hast du da level konverter dazwischen, oder direkt angeschlossen.
der nächste punkt der mir dazu einfällt, ich nehme an du nimmst die 3,3 volt vom nano - die 3,3 volt werden erzeugt von einem ftdi baustein der 50mA liefert. das trx modul benötigt etwa 20ma beim empfang, ich habe nie gemessen wieviel das ding beim senden braucht. könnte auch sein, da der pair string relativ lang ist, das die versorgung zusammen bricht.
wow, vielen dank!
da hast du dir richtig arbeit gemacht...
Zitat von: Rohan am 12 November 2013, 23:32:44
sooo...
ich war so frei und habe im Wiki den Beitrag zur Asksin-Library begonnen: Link => http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library (http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library)
.......
Super, vielen Dank!
Ich arbeite wesentlich lieber mit Wiki-Einträgen als mich durch ewig lange Threads zu wühlen! :-)
Hallo Peter,
Willst Du dir nicht den Arduino Pro Mini 3,3 V holen und nochmals probieren.
Selbst wenn Du bei Deinem Arduino nano die 3,3V vom FTDI (PIN 17) nimmst, die Datenleitungen des Funkomduls (haben dann immer noch den 5V Pegel)
Kostet ja auch nicht die Welt ;)
Grüsse Martin
hallo trilu,
ich versuche gerade ein seltsames problem nachzustellen bei dem scheinbar ein HM-PB-6-WM55 beteiligt ist: http://forum.fhem.de/index.php/topic,11485.msg107233.html#msg107233 (http://forum.fhem.de/index.php/topic,11485.msg107233.html#msg107233).
ich hab aber keinen :( und kann das problem weder mit dummys noch mit einem swap panstamp nachstellen.
hast du eine idee ob man mit deiner lib schon einen HM-PB-6-WM55 nachstellen kann?
gruss
andre
Hallo trilu
Du hast Recht, eigentlich müsste ein Levelshifter dazwischen. Die Stromversorgung läuft auf 3,3V.
Betateilchen hatte seinen Aufbau mit einen Arduino-Uno dargestellt.
@Betateilchen: Hattest du einen Levelshifter benutzt ?
Werde mal einen Levelshifter dazwischenhängen und testen.
Allerdings erklärt dies nicht warum es bis zum sketch 131027 noch funktioniert hat ;D
Gruss Peter
PS: Ihr nutzt alle einen Panstamp oder Arduino Pro Mini 3,3 V ?
hi andre,
die lib würde es schon können, ist aber aufwand da er in der register.h nicht definiert ist.
es gibt aber die möglichkeit manuell zu senden. also byte's per serieller konsole ins funkmodul zu schicken.
ich könnte dir aber auch leihweise einen schicken :-))))
viele grüße
horst
Zitat von: justme1968 am 14 November 2013, 09:08:03
hallo trilu,
ich versuche gerade ein seltsames problem nachzustellen bei dem scheinbar ein HM-PB-6-WM55 beteiligt ist: http://forum.fhem.de/index.php/topic,11485.msg107233.html#msg107233 (http://forum.fhem.de/index.php/topic,11485.msg107233.html#msg107233).
..........
Zitat von: PeterS am 14 November 2013, 10:16:25
...
Allerdings erklärt dies nicht warum es bis zum sketch 131027 noch funktioniert hat ;D
...
ich habe zu der zeit einiges an der sende und empfangsroutine geändert, viele loops rausgenommen um das hängen bleiben zu verhindern.
es kann jetzt schon sein, das die zeit bis sich ein register "gesetzt" hat nicht mehr reicht. ich werde die nächsten tage da noch mal genauer drauf schauen. das komische ist halt, senden scheint bei dir ja zu funktionieren, damit kann es nicht an der seneroutine an sich liegen. der senderoutine ist es ja wurscht was in dem string steht. pairing ist ja nichts anderes wie senden von einigen bytes...
ich hab mal angefangen ein wenig zu dokumentieren, vielleicht kannst du einige inhalte fürs wiki brauchen...
Zitat von: Rohan am 12 November 2013, 23:32:44
sooo...
ich war so frei und habe im Wiki den Beitrag zur Asksin-Library begonnen: Link => http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library (http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library)
...
wenn ich einen leihweise habe kauf ich mir noch einen. und ich brauch ihn doch nicht wirklich :).
serielle konsole reicht aber völlig.
weißt du was ich für ein und aus verwenden muss?
gruss
andre
klar, aber ich sags dir nicht :-)
es gibt kein wirkliches ein- aus signal, das wird bei HM über die channels geregelt.
der WM55 hat 6 channel. damit ist channel 01,03,05 für aus
und 02,04,06 für ein...
bei tastendruck wird ein remote event gesendet, der sieht so aus:
0B E1 A2 40 22 66 08 63 19 63 04 49
0B - länge
E1 - msg zähler
A2 - msg flags
40 - msg type (remote event)
22 06 08 - hm id des wm55
63 19 63 - pair id, addresse der zentrale
04 - channel, wie weiter oben beschrieben
49 - tastenzähler
zum senden bastelst du einen string in folgendem format:
$0B $E1 $A2 $40 $22 $66 $08 $63 $19 $63 $04 $49 s
hast es ja doch verraten :P
ich probier es heute abend gleich aus.
gruss
andre
Ich habe mich ein wenig nach "fertiger" Hardware umgesehen. Der PanStamp scheint der einzige zu sein, der einen AVR und den Funkchip drauf hat :(
Ich habe hier noch einen "ähnlichen" gefunden, allerdings mit eine m168: http://www.watterott.com/de/RFbee-V11 (warum tut man sowas?!)
Hallo trilu
Habe mal etwas Code-Schnitzeljagd betrieben um den Fehler etwas einzugrenzen.
Wie gesagt funktioniert bei mir das pairing nicht mehr und nach den Aufruf von "p" wird nichts mehr erkannt.
Also habe ich alles resetet.
Es scheint als kann er bei mir keine HMID finden oder bilden und läuft ständig in die Senderoutine, weil send.counter > 0 ist ?!
Der Memory-Compare gibt mir zu denken.
Du hast die Routine startPairing etwas umgestellt. Könnte daran der Fehler liegen ?
NEU:
void HM::startPairing(void) { // send a pairing request to master
// 01 02 03 04 05 06 07
// 1A 00 A2 00 3F A6 5C 00 00 00 10 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01
memcpy_P(send_payLoad, devParam, 17); // copy details out of register.h
send_prep(send.mCnt++,0xA2,0x00,broadCast,send_payLoad,17);
}
ALT:
void HM::startPairing(void) { // send a pairing request to master
// 01 02 03 04 05 06 07
// 1A 00 A2 00 3F A6 5C 00 00 00 10 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01
uint8_t bCastID[3] = {0,0,0}; // size broadcast
memcpy_P(send_payLoad, devParam, 17); // copy details out of register.h
send_prep(send.mCnt++,0xA2,0x00,bCastID,send_payLoad,17);
}
Wenn ich testweise den send.counter auskommentiere, läuft alles stabil ! Fhem kann die LED schalten und alle Wettersensoren werden im Debug erlauscht.
Nur geht halt kein pairing :-)
void HM::send_out() {
if (bitRead(send.data[2],5)) send.retries = maxRetries; // check for ACK request and set max retries counter
else send.retries = 1; // otherwise send only one time
send.burst = bitRead(send.data[2],4); // burst necessary?
if (memcmp(&send.data[7], HMID, 3) == 0) { // if the message is addressed to us,
memcpy(recv.data,send.data,send.data[0]+1); // then copy in receive buffer. could be the case while sending from serial console
send.counter = 0; // no need to fire
} else { // it's not for us, so encode and put in send queue
hm_enc(send.data); // encode the string
// send.counter = 1; // and fire
}
Gruss Peter
Hi
Wo habt ihr euch den Arduino Mini Pro 3,3V bestellt ?
Günstige 3,3V Versionen habe ich noch keine entdeckt :D
Gruss Peter
Ich kaufe meine in China 8)
Bei ebay auf Weltweit, dann nach Arduino 8mhz suchen.
Kosten incl. Porto etwa5 Dollar.
Hab jetzt noch einen ganzen Schwung bei Alibaba geordert. Da kosten sie 3 Dollar,
Lieferung dauert so um die 4 Wochen :(
@shaddi: die xbee module sind eigentlich dafür gedacht mit einem XbeeShield auf einen arduino gesteckt zu werden. urspünglich gab es glaube ich nur zigbee module. danach wurden im gleichen form faktor dann bluetoth, wlan und eben das modul auf basis eines cc1101 herausgebracht.
der primäre anwendungsfall ist also nicht das ding stand allone zu betreiben sondern mit einem usb/serial converter an einem pc oder als funk modul an einem avr.
im vergleich zu einem panstamp mit arduino und cc1101 auf einem board sind es also eigentlich drei komponenten die dann zusammen eine ähnliche funktionalität geben.
gruss
andre
Hi,
Zitat von: PeterS am 14 November 2013, 20:57:58... Wo habt ihr euch den Arduino Mini Pro 3,3V bestellt ? ...
Entweder (wie schon geschrieben) in Fernost oder (so wie ich ;) meine letzten 3) hier: http://www.exp-tech.de/Mainboards/Arduino-Pro-Mini-328-3-3V-8MHz.html (http://www.exp-tech.de/Mainboards/Arduino-Pro-Mini-328-3-3V-8MHz.html)
Gruß
Thomas
Vielleicht findet sich ja hier auch noch jemand der spass daran hat platinen zu den möglichen geräten zu entwickeln...
Da kannst du aber von ausgehen :)
Ich habe schon einige Ideen
Ich habe mir zuvor aber auch schon ein paar der Arduinos bei Ali geordert.
Also Erste Idee hätte ich einen Wettersensor mit Luftdruck / Temperatur / Feuchte
Als alternative SW würde ich dann auch den FS20 / HMS Code für die Freunde von SlowRF beisteuern den ich in einigen Projekten schon verbaut habe.
Mit diesem Sensor liebäugle ich auch schon:
http://www.tme.eu/de/details/mikroe-1444/entwicklungsboards-sonstige/mikroelektronika/thunder-click/#
Gruß
Dirk
Hmmm, ich wollte schon fragen, ob es nicht günstig wäre direkt mit nem ATmega328P zu arbeiten, aber bei den Komplettpreisen für nen Arduino bei Alibaba, macht das wenig Sinn ;-)
Hallo trilu
An welche Platinen hattest du gedacht ?
Ein grosser Punkt ist wie immer die Stromversorgung der Einheiten.
Diese ist wieder abhängig von den Sensoren und Aktoren.
Mir schwebt immer noch ein universeller Spannungssensor (12 - 230V) vor.
Hier könnten alle möglichen Zustände (Licht, Pumpe, Klingel, etc.) überwacht und an Fhem gemeldet werden.
Die wäre aber auch mit einem Homematic Fensterkontakt in Kombination mit einer Vorschaltung möglich.
Aber mal schauen ... ;D
Gruss Peter
ich meinte damit endgeräte spezifische platinen.
rgb dimmer auf lochraster ist nicht schön :-)
oder auch eine wetterstation auf lochraster sieht doof aus ....
so, mal wieder ein update. ich habe festgestellt das martin vermutlich was in der hmconfig.pm geändert hat und deswegen das getstatus nicht mehr richtig beantwortet wurde.
-> 10 08 A0 01 63 19 63 2F B7 4A 00 04 00 00 00 00 00 (l:17)(124923)
S- 14 08 A0 10 2F B7 4A 63 19 63 02 02 01 0A 63 0B 19 0C 63 00 00 (l:21)(124936)
hier wird list0 von channel0 abgefragt. das zweite byte, also die 08 ist der message counter. ich hatte hier meinen eigenen counter verwendet, es muss aber mit dem counter der zentrale geantwortet werden. naja, muss man erst mal drauf kommen :-)))
das ist eine erfolgreiche pairing sequenz:
S- 1A 00 A2 00 2F B7 4A 00 00 00 10 00 57 50 53 30 30 30 30 30 30 30 31 9F 41 01 01 (l:27)(114565)
<- sendStr (114569)
-> 10 04 A0 01 63 19 63 2F B7 4A 00 05 00 00 00 00 00 (l:17)(114792)
S- 0A 04 80 02 2F B7 4A 63 19 63 00 (l:11)(114798)
<- sendStr (114870)
-> 13 05 A0 01 63 19 63 2F B7 4A 00 08 02 01 0A 63 0B 19 0C 63 (l:20)(115175)
S- 0A 05 80 02 2F B7 4A 63 19 63 00 (l:11)(115193)
<- sendStr (115195)
-> 0B 06 A0 01 63 19 63 2F B7 4A 00 06 (l:12)(115492)
S- 0A 06 80 02 2F B7 4A 63 19 63 00 (l:11)(115499)
<- sendStr (115501)
-> 0B 07 A0 01 63 19 63 2F B7 4A 01 0E (l:12)(120866)
S- 0E 07 A4 10 2F B7 4A 63 19 63 06 01 00 00 00 (l:15)(120872)
<- sendStr (120877)
-> 0A 07 80 02 63 19 63 2F B7 4A 00 (l:11)(121024)
-> 10 08 A0 01 63 19 63 2F B7 4A 00 04 00 00 00 00 00 (l:17)(124923)
S- 14 08 A0 10 2F B7 4A 63 19 63 02 02 01 0A 63 0B 19 0C 63 00 00 (l:21)(124936)
<- sendStr (124940)
-> 0A 08 80 02 63 19 63 2F B7 4A 00 (l:11)(125089)
-> 10 09 A0 01 63 19 63 2F B7 4A 01 04 00 00 00 00 01 (l:17)(125366)
S- 0E 09 A0 10 2F B7 4A 63 19 63 02 08 00 00 00 (l:15)(125374)
<- sendStr (125378)
-> 0A 09 80 02 63 19 63 2F B7 4A 00 (l:11)(125526)
-> 0B 0A A0 01 63 19 63 2F B7 4A 01 03 (l:12)(125796)
S- 0E 0A A0 10 2F B7 4A 63 19 63 01 00 00 00 00 (l:15)(125804)
<- sendStr (125806)
-> 0A 0A 80 02 63 19 63 2F B7 4A 00 (l:11)(125954)
viel spass beim testen!
das panstamp rgb board aus dem bastel thread sollte mit einem passenden sketch auch für homematic funktionieren. es braucht dann aber noch das passende fhem gegenstück das mit den drei oder mehr kanälen klar kommt.
gruss
andre
Zitatich meinte damit endgeräte spezifische platinen.
rgb dimmer auf lochraster ist nicht schön :-)
Wie gesagt, ich bin dabei und würde die Platinen entwerfen.
Ich würde das ganze dann auch gerne modular bauen.
Nicht jeder braucht / möchte in der Station z.B. einen Gewitterdetector / Luftdrucksensor / ...
Also Optionen für einen kombinierten Wettersensor hätte ich folgende Ideen:
- Temperatur / Feuchte
- Luftdruck / Temperatur (BMP180)
- Gewittersensor (AS3935 bzw. unten genannte Sensorplatine, leider ist das Teil nicht ganz so günstig)
- Helligkeitssensor
- CO2 / Gassensor
- Weitere Ideen ?
Das ganze hätte ggf. auf eine Art Universalplatine an der man nur die benötigten Sensoren bestückt.
Evtl macht es ja auch Sinn die Sensoren für fertige Wetterstationen (z.B. den Kombi-Wettersensor KS-300) oder auch andere hier anschließen zu können.
Weitere Ideen sind dann
RGB / Bzw. Multikanal-Dimmer (Hier würde ich sogar bis zu 6 Kanäle vorsehen alle Hardware PWM
10 Bit mit konfigurierbarer Helligkeitstabelle für eine für's Auge liniare Heligkeitskurve. Der Code liegt schon hier und funktioniert seit ein Paar Jahren. Allerdings auf FS20 Basis.
Als weitere Idee hätte ich noch eine Homematic - IR Brücke.
Damit könnte man dann auch einfach Geräte in FHEM einbinden die nur per IR steuerbar sind.
Gruß
Dirk
Hallo Dirk
Ein Spannungssensor wäre sicherlich noch nützlich (Spannung liegt (nicht) an).
Wie hast du dir die Platine den gedacht ?
Als Trägerplatine fur den Arduino Mini Pro + optionale austauschbare Boards für die Komponenten?
Oder einfach eine Platine als Ersatz für die Lochraster und mit Freiluftverdrahtung ?
Gruss Peter
Hallo Dirk,
+ Piri, Display, Taster ?
vg
jörg
Hallo Dirk,
ja! einmal eine Handvoll von allen Teilen :)
Ich möchte vor allem Sensoren für alle möglichen Werte großflächig verteilen. Die Temp/hygro-Sensoren für das System sind einfach unverschämt teuer. Genauso wie die Tür/Fenster-melder.
Und auch so spielereien wie RGB-Dimmer wären sehr interessant.
Was ich mich frage ist, wie kompleziert ist es, eigene Modelle ins FHEM zu integrieren. Ich überblicke den Code fürs HM im FHEM üüüberhaupt nicht.
bye,
Karl
Das Einbinden in FHEM wird einfach. Es wird ein Perl script geben, zur Definition der Register. Der Output wird nach register.h kopiert und damit sind dann die Register des panstamp definiert.
Hier gibt es heute schon aus der Homematic Familie jede Menge Parameter die wir recyceln können.
Die Messages aus dem HM Protokoll sind eigentlich auch flexibel genug um verschiedene eigene Devices bauen zu können. Martin wollte sich auch noch was überlegen, wie die Device Konfig dann nach FHEM kommt.
Zitat von: Dirk am 15 November 2013, 09:35:31
Wie gesagt, ich bin dabei und würde die Platinen entwerfen.
- Weitere Ideen ?
Klar ;)
Vibrationssensor
MPU-6050 3 Axis Gyroscope Accelerometer (Vielleicht ist das ja genau genug um die Exakte Fenster Position zu bestimmen ;D )
Hallsensor
Wassersensor
Touchsensor
RFID Modul (Wobei da gleich das Bessere das auch NFC kann) (Dafür habe ich auch schon mal Arduino sketches gesehen)
(Die Modle gibt es alle günstigl vom Chinesen)
ALDIs Digitale RGB Stripes (Dafür gibt es auch schon Arduino Sketches,das werde ich mir mal ansehen, sobald ich endlich mal meinen Arduino bekomme)
So, das waren meine Ideen ;)
ich bräuchte noch einen garagentoröffner, schaltbare strommesssteckdose, haustürklingel mit mp3,
gas und stromzähler 8)
Zitat von: PeterS am 15 November 2013, 12:54:30
Ein Spannungssensor wäre sicherlich noch nützlich (Spannung liegt (nicht) an).
Das müsste sich doch bereits jetzt schon z.B. mit hilfe eines kleinen Relais und einem Tastsensor realisieren lassen. Oder wie genau hattest du dir das gedacht? Evtl. mit Spannungsmessung?
ZitatWie hast du dir die Platine den gedacht ?
Als Trägerplatine fur den Arduino Mini Pro + optionale austauschbare Boards für die Komponenten?
Evtl. sowohl als auch.
Zitat von: herrmannj am 15 November 2013, 13:36:43
+ Piri, Display, Taster ?
Ein Display würde ich auch gerne implementieren. Am besten währ hier natürlich was Stromsparendes (Epaper währ genial. Aber vergleichsweise teuer).
Zitat von: Samsi am 15 November 2013, 14:36:12
Vibrationssensor
MPU-6050 3 Axis Gyroscope Accelerometer (Vielleicht ist das ja genau genug um die Exakte Fenster Position zu bestimmen ;D )
Interessant. Wie währen die Einsatzszenarien bei dir hier?
Zitat von: trilu am 15 November 2013, 14:59:38
... haustürklingel mit mp3 ...
Dafür kann ich dir diesen Bausatz als Grundlage empfehlen:
http://www.elv.de/mp3-tuerklingel-mtk1-komplettbausatz.html
Da steckt auch schon ein AVR drin. Und dafür hab ich schon eine Alternative Firmware geschrieben mit einem Sprachmenü und 2 verschiedenen Melodien für 2 unterschiedliche Klingeltaster. Daran lässt sich auch recht einfach ein Arduino+Funkmodul anschliessen. Der Platz im ingegrierten AVR (Atmega328) könnte knapp werden. Das teil läuft bei uns seit einiger Zeit zuverlässig als Klingel im Batteriebetrieb.
Gruß
Dirk
Ich hab mir mal diese module bestellt. Angeblich kann man seriell als auch per spi ansteuern...
http://www.ebay.de/itm/370668434887
Mal testen. Ist ja nicht teuer :P
Hat schon jemand den aktuellen sketch getestet?
Erzähl dann mal wie das klappt.
Ich habe für MP3-Ausgaben immer den VS1011e eingesetzt. Ist auch in dem Genannten MP3-Gong drinn.
Gruß
Dirk
ZitatEin Display würde ich auch gerne implementieren. Am besten währ hier natürlich was Stromsparendes (Epaper währ genial. Aber vergleichsweise teuer).
Ja, außerdem brauchen die richtig fett ram: http://www.adafruit.com/products/1346.
Die Nokia 5110 Displays gibt es günstig und genügend lib's, dafür halt nur b/w ...
vg
Jörg
ram wäre nicht das problem - davon ist etwa 1k frei. flash wird schon eher das problem, die lib braucht ohne debug und serielle konsole etwa die hälfte.
also 15k sind noch frei. mit debug sind etwa 10k noch frei....
ich hab das epaper display an einem pansamp am laufen und kann auch von fhem verbrauchswerte und temperaturen hin senden und anzeigen. (http://forum.fhem.de/index.php/topic,14063.msg95018.html#msg95018 (http://forum.fhem.de/index.php/topic,14063.msg95018.html#msg95018) und hier http://forum.fhem.de/index.php/topic,14063.msg95612.html#msg95612 (http://forum.fhem.de/index.php/topic,14063.msg95612.html#msg95612)
die version von embedded artists hat flash für icons und grafiken auf dem board und als ram reicht ein spi sram baustein für unter 2 euro. zur not geht es auch mit 1k. es muss also kein avr mit viel ram sein.
das display hält die anzeige auch nach 2 wochen ohne batterie. wichtig ist das der refresh nicht sofort geht sondern etwas dauert. für realtime anzeigen also nicht geeignet, für status übersicht, temperatur, verbrauch alle 10-15 minuten aktualisiert oder Fenster status bei bedarf ist es sehr gut.
es gibt auch versionen mit bis zu 1280x1024 auflösung. dann ist aber wirklich eine cpu mit mehr ram nötig.
gruss
andre
was kostet so ein display?
Zitatram wäre nicht das problem
Je nach Auflösung könnte das aber eins werden.
Meist wird man für das Display einen eigenen Framebuffer benötigen.
Bei 128x64 Pixel und 1 Bit Farbtiefe währen das schon 8 KB Ram.
Aber auch hier könnte man ggf. ein serielles RAM anbinden.
Ich hab ja noch einige kleine Displays von der RPI-LCD-CSM-Platine hier. Damit werde ich demnächst mal experimentieren.
Zitatwas kostet so ein display?
Um die 5€
Gruß
Dirk
nein. ram ist kein problem.
das display kann häppchenweise angesteuert werden. 1k reicht. es dauert dann nur etwas länger.
oder wie gesagt spi sram für 2 euro. das ist dann einen tick schneller. der refresh des displays geht immer noch häppchenweise.
das display kostet in der 2.7'' version inklusive board zum ansteuern und flash etwa 30 euro.
gruss
andre
puh, 30 euro find ich heftig. ein kindle wlan gibts für 50 euro, größeres display und cpu & funk on board :-)
bin nur noch nicht zum patchen gekommen ....
Zitat von: Dirk am 15 November 2013, 17:19:01
Das müsste sich doch bereits jetzt schon z.B. mit hilfe eines kleinen Relais und einem Tastsensor realisieren lassen. Oder wie genau hattest du dir das gedacht? Evtl. mit Spannungsmessung?
Hallo Dirk
Theoretisch kann man mittels Koppelrelais das Ganze relaisieren. Cool wäre halt wenn man dem Spannungswächter eine feste ID verpasst, dann das Teil irgendwo (Klingel, etc.) verbaut und die Spannungsänderungen binär (Spannung an/Spannung aus) per Funk geliefert bekommt.
Der Sensor sollte halt wie immer möglichst klein und wartungsarm sein ::)
Gruss Peter
Zitat von: justme1968 am 15 November 2013, 17:55:08
das display kann häppchenweise angesteuert werden. 1k reicht. es dauert dann nur etwas länger.
Dann muss man das Display aber auch auslesen können?
Meine bisher verbauten Displays waren "dumm" Die konnten Daten nur Empfangen. Da musste man den Framebuffer selber organisieren.
Gruß
Dirk
das display kann man nicht auslesen.
mit 1k gibt es natürlich einschränkungen. etwas senden und so über etwas vorher gesendetes drüber zeichnen das das alte darunter zu sehen bleibt geht nicht. der intergrund in der kompletten zeile muss gelöscht werden. etwas über eine grafik oder ein icon zeichnen das aus dem flash kommt geht ohne probleme.
zeilenweise text ausgeben ist z.b. völlig problemlos.
mit dem spi ram geht das alles dann noch ein bischen besser. sogar eine kopie des alten inhalts zusätzlich zum aktuellen ist möglich . das ist für den refresh günstiger.
dir einschränkung des häppchenweisen refresh bleibt zwar (zumindest wenn alles am gleichen spi bus hängt) aber das display ist sowieso nicht auf geschwindigkeit ausgelegt.
ich hab zuerst alles ohne zusätzlichen ram gemacht. das reicht für text und sehr sehr einfache grafiken und icons.
die version mit spi sram erweiterung kann jetzt auch eine art displayliste von fhem empfangen und auch komplexere dinge darstellen.
die embedet artists wollen eventuell in der nächsten version das sram noch mit auf das board tun.
gruss
andre
das hört sich einfach zu realisieren an - wie genau muss die auflösung sein?
der arduino hat ja adc mit 9bit, wenn dir eine auflösung von 0 -1023 reicht geht das mit boardmitteln.
kleinen trafo - primär mit 230 volt/ sekundär 5 volt und schon kann am adc gemessen werden.
was ist denn die anwendung dafür?
Zitat von: PeterS am 15 November 2013, 18:07:35
Hallo Dirk
Theoretisch kann man mittels Koppelrelais das Ganze relaisieren. Cool wäre halt wenn man dem Spannungswächter eine feste ID verpasst, dann das Teil irgendwo (Klingel, etc.) verbaut und die Spannungsänderungen binär (Spannung an/Spannung aus) per Funk geliefert bekommt.
Der Sensor sollte halt wie immer möglichst klein und wartungsarm sein ::)
Gruss Peter
mit dem ePaper Display ist schon sexy, aber wenn man dann Aufwand (Preis, evtl ram, komplexere Progeammierung) vs mini display mit Backlight vergleicht ?
Logisch ist 'ne Frage der Anwendung wobei ich bei den kleinen Sensoren etc zu möglichsten simplen Varianten tendiere. Wenns größer wird finde ich es besser ein altes smartphone/tab zu recyclen, gibt dann gleich touch wlan etc on-top und oft sowieso vorhanden ansonsten in der bucht die gleiche Liga wie das ePaper Display einzeln.
vg
Jörg
Zitat von: Dirk am 15 November 2013, 17:19:01
Interessant. Wie währen die Einsatzszenarien bei dir hier?
Kommt Drauf an, wie genau das Teil ist oder ob der ständig neu kalibriert werden muss. Mich würde schon interessieren ob meine Fenster auf Kipp stehen oder komplett offen sind. Oder als Neigungssensor fürs Dachfenster. Stellt sich allerdings die Frage ob das teil nicht zu viel Strom verbraucht, so genau hab ich mir das noch nicht angeschaut.
8)
Hier geht es ja richtig dolle ab ;)
Ideen noch und nöcher.
Ich würde mir z.B. ein "universelles" Device, welches "beliebige" Sequenzen senden und/oder empfangen kann, wünschen. Die weitere Verarbeitung (Aktion/Reaktion) könnte man dann dem Arduino bzw. PanStamp überlassen oder Fhem. Wenn ich mir so anschaue, was für eine Sequenz (von der Länge her) mittlerweile mittels Verwendung von prep und abschließendem exec (Stichwort: Temperaturlisten) von Fhem an die Heizungsregler (TC/RT) gesendet werden kann, wäre damit einiges möglich. Oder?
Ansonsten wäre natürlich Hardware wünschenswert, die es von eQ3/ELV für HM so (noch) nicht gibt oder die qualitativ (persönliche Meinung) ... hmmm... suboptimal ist. Da fallen mir auf Anhieb die Sensoren ein, die die relative Luftfeuchtigkeit messen (hier mein Außensensor). Der zeigt maximal 80 % an, obwohl meine anderen Sensoren (WS2300/WS2500) an die 100 % anzeigen.
Just my 2 Cents ;)
Gruß
Thomas
@trilu: Danke für dein Dokument zwecks evtl. Einarbeitung ins Wiki, aber das ist mir einige Hausnummern zu hoch. Ich kenne meine Grenzen und überlasse dann sehr gerne anderen das Feld. Ich möchte mich auf die Anwenderseite und die Dokumentation aus dessen Sicht beschränken. "Bit- und Byteschubser" bin ich nicht. Sorry dafür.
Hi trilu,
Zitat von: trilu am 15 November 2013, 09:03:27... so, mal wieder ein update. ... viel spass beim testen!
Getestet und für gut befunden ;) Läuft alles, wie erwartet (war nach dem letzten Fhem-update etwas anders). Danke.
Eine Bitte: Du kannst (evtl. ?) auch noch dein erstes Posting in diesem Thread ändern. Es wäre evtl. für eine (dauerhafte) Verlinkung (z.B. im Wiki) besser, die jeweils aktuelle/neueste Version der Asksin-Lib jeweils dort rein zu setzen (ob dieses "Dauer-Edit" so bleibt, kann aber nur einer der Foren-Mods beantworten).
Ich hoffe, ich bin nicht unverschämt.
Gruß
Thomas
Hat jemand Ideen für Gehäuse? z.B. für kleinere Sensoren ggf. mit 2 AA oder AAA Zellen als Spannungsversorgung?
Dann könnte ich die Platinen gleich passend machen.
Alternativ ggf. auch was für z.B. die Mehrkanal-Dimmer
Gruß
Dirk
gibt wieder ein Update - diesmal auf der ersten Seite!
ZitatHat jemand Ideen für Gehäuse? z.B. für kleinere Sensoren ggf. mit 2 AA oder AAA Zellen als Spannungsversorgung?
Klar :o
Für Sensoren im Aussenbereich finde ich Kabeldosen ganz ok: http://www.pollin.de/shop/dt/ODMxOTQ0OTk-/Haustechnik/Installationsmaterial/Dosen_Verteiler/Kabelabzweigkasten_WISKA_COMBI_308_IP66.html (http://www.pollin.de/shop/dt/ODMxOTQ0OTk-/Haustechnik/Installationsmaterial/Dosen_Verteiler/Kabelabzweigkasten_WISKA_COMBI_308_IP66.html)
Gibts in verschiedenen Größen, sind Wetterfest und leicht zu beschaffen...
Falls möglich würde ich auch gerne von den Panstamps wegkommen, sind verhältnismässig teuer und schwer zu beschaffen.
Mir wären die Arduino Pro Mini sympatischer, dazu dann ein Funkmodul - sowas hier:
http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html (http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html)
Sind bestellt, aber noch nicht geliefert. Tests stehen noch aus, aber wenn die was taugen kann man sich ja eindecken...
Weiterhin wäre es cool wenn möglichst Module verwendet werden könnten. Z.b. als Netzteil das Innenleben von solchen Steckernetzteilen:
http://www.ebay.de/itm/USB-Netz-Adapter-Netzteil-Netzstecker-Ladegerat-fur-Apple-iPhone-iPod-Samsung-/131006585336 (http://www.ebay.de/itm/USB-Netz-Adapter-Netzteil-Netzstecker-Ladegerat-fur-Apple-iPhone-iPod-Samsung-/131006585336)
Platine ist klein und leicht zu beschaffen. Lötaufwand sind 4 Kabel....
Weil wir gerade dabei sind - hat hier jemand einen Temperatur/Luftfeuchte Sensor von HM?
Ich bräuchte ein wenig Logdateien von so einem Gerät. Dann würde ich mal anfangen einen
Sensor zu implementieren...
Welche Events werden gesendet, wann werden sie gesendet, usw....
Welche Kanäle hat so ein Gerät, welche Listen, welche Register?
Hallo trilu
Anbei die erwünschten Infos:
RegL_00: 01:00 02:01 05:00 0A:F1 0B:47 0C:12 0F:00 00:00 2013-10-09 20:28:34
l> 0C A8 86 70 1C C8 D1 00 00 00 00 4C 4F (l:13)(119246)
WEATHER_EVENT; temp: 00 4C, hum: 4F
Gruss Peter
PS: Wo sehen ich dke Kanäle ?
Mach einfach in fhem ein getconfig, dann fragt fhem die komplette geräteconfig ab.
Das log wäre für mich ein prima anfang 8)
Ach ja, und was für ein Gerät es ist...
Klappt jetzt das pairing bei dir?
Hallo trilu
Modell: HM-WDS10-TH-O
Readings
Activity alive 2013-11-16 12:47:29
Activity: alive 2013-07-15 16:52:18
CommandAccepted yes 2013-10-09 20:28:34
PairedTo 0xF14712 2013-10-09 20:28:34
R-burstRx off 2013-10-09 20:28:35
R-intKeyVisib invisib 2013-10-09 20:28:35
R-pairCentral 0xF14712 2013-10-09 20:28:35 humidity 77 2013-11-16 12:50:03
powerOn - 2013-05-05 09:53:09
state T: 7.9 H: 77 2013-11-16 12:50:03
temperature 7.9 2013-11-16 12:50:03
Gruss Peter
Hallo trilu
Das letze #endif in der AskSin.h führt zu einem Compilingfehler.
Der sketch läuft bei mir nun ohne Änderungen, bis auf das Pairing. Dies führt nun nicht mehr zu einem Hänger !
Die Interrupt-Routine HM::isrGDO0event wird weiter ausgeführt.
Der "r"-Befehl führt bei mir auch zu einem endlosen Blinken der LED13 :o
Gruss Peter
Zitat von: PeterS am 16 November 2013, 21:11:18
Hallo trilu
Das letze #endif in der AskSin.h führt zu einem Compilingfehler.
Gruss Peter
Kann ich bestätigen, einfach auskommentieren ?
Gruss Martin
Hallo
Für meine Anwendung breuchte ich einen stromsparenden Batterie Betrieb.
Dazu möchte ich mal den Mode 1 (Burst mode ) über "setPowerMode(1)" der Lib testen.
Ich nehme an (da wir ja ein Dimmer device haben) wird bei einem Kommando ab fhem (zb. "on", "off") der Burst nicht gesendet.
Wenn ich das richtig verstanden habe, sendet fhem den Burst erst, wenn es sich um einen Batterie betriebenen Aktor handelt.
Stimmen meine Überlegungen ?
Falls ja, wie kann ich fhem sagen dass der Burst bei einem Kommando gesendet werden soll ?
Grüsse Martin
@Rohan
Das Wiki ist wirklich Klasse :D
Im Moment hab ich da erst ein paar Versuche in der Lib. Aber ich kann dir beschreiben was ich vorhabe ;D
Es wird wohl drei Modes geben.
Mode 0 - keine power saving
Mode 1 - Interessant für batteriebetriebene Aktuatoren. Das Funkmodul prüft alle 250 ms ob ein burst signal irgendwo gesendet wird.
Ist keins da, schläft das Funkmodul wieder weiter. Stromaufnahme einige uA.
Findet es ein Burstsignal bleibt es für ein paar Millisekunden wach und wartet auf einen String der die eigene HMID enthält. Kommt eine andere HMID wird wieder geschlafen. Wird die eigene HMID gefunden, dann wird etwas länger wach geblieben.
Mode 2 - Interessant für batteriebetriebene Schalter und Aktoren. Hier ist der RX Mode per default aus. Es gibt eine stayAwake Funktion um den RX Mode für einen definierten Zeitraum einzuschalten. Z.b. um die Konfigurationstaste zu realisieren. Taste wird gedrückt, Funkmodul geht in den RX mode für 20 Sekunden und man kann per FHEM das Gerät konfigurieren oder Peeren. Zusätzlich wird der RX mode für 500 ms nach dem Senden eines Strings eingeschaltet um z.b. einen ACK empfangen zu können. Das ist der sparsamste Modus. Hier braucht das Funkmodul die meisste Zeit nur ein paar uA.
Aber wje gesagt, das ist so noch nicht implementiert. Ich kämpfe zur Zeit wieder mit dem Registerhandling. Hab einen dicken Bug gefunden, der die pairing Probleme von PeterS erklären würde.
Der nächste test sketch wird ein 6 Tasten Schalter. Ich will das List4 Handling einbauen und testen. Zusätzlich eignet er sich um Powermode 2 zu testen.
Viele Grüsse
Horst
Hallo trilu
Ich stehe für Tests bereit, wenn es einen neuen Sketch gibt ;D
Gruss Peter
Vielen Dank für die Beschreibung, der Power Modes.
Klingt vielversprechend :-)
Grüsse Martin
Es gibt mal wieder etwas neues zum testen...
Ich habe den sketch umgebaut als Switch, genauer gesagt emuliere ich einen HM-PB-6-WM55.
Es sind einige Änderungen in der Library zum Thema Pairing und reset. Alles weitere steht im Changelog.
Die Steuerung des Schalters läuft komplett über die serielle Konsole.
Der Schalter hat 6 Channel, gesendet wird ein Tastendruck mit dem Befehl
1 0 b
Die 1 steht für den Channel - es geht also 1 bis 6. Die 0 zeigt an das es ein kurzer Tastendruck war, eine 1 würde einen langen tastendruck anzeigen. Ihr könnt den Schalter wie den echten Schalter konfigurieren, es geht auch burst zu senden.
Neu ist in der register.h die Funktion: mainSettings()
Hier könnt ihr Variablen setzen, die wenn "#define firstLoad;" existiert, in das eeprom übernommen werden.
Der Nachteil ist, es werden bei jedem Reset die konfigurierten Werte im EEprom mit den default Werten überschrieben.
Am besten ist, ihr ladet das Programm beim ersten mal mit definierten firstLoad auf den Arduino, dadurch werden die Werte ins EEprom geschrieben. Überprüfen könnt ihr das mit einem "e" in der seriellen Konsole. Dann kommentiert ihr firstLoad aus und ladet das Programm
erneut auf den Arduino. Die EEprom Werte bleiben jetzt erhalten...
Der Schalter lässt sich auch schön mit der HomeMatic Konfigurationssoftware beschreiben. Leider ist aber bei der Software per default die AES Kommunikation an. d.h. pairen funktioniert, aber dann müsst ihr für jeden Channel auf Standard Kommunikation umstellen.
Mit den power modes hab ich ein wenig angefangen, ist aber noch weit entfernt von funktioniert...
hat einer von euch eine idee wie AES funktioniert?
es fuxt mich schon sehr, das ich nicht weiss, was in dem string steckt, wie verschlüsselt wird und wie eine antwort generiert wird...
oder hat schon mal jemand versucht ein original hm device auszulesen? oder hat jemand vielleicht ein update file?
Zitathat einer von euch eine idee wie AES funktioniert?
Eine Idee hätte ich schon, ob es so gemacht wird, weiss ich nicht.
Nehmen wir mal an der AES Key wäre 1111112222222333333334444444.
Wenn ich jetzt einen Befehl an den Aktor senden würde, z.B. set lampe 100% dann kommt da ja irgend eine Message raus die man per Funk an einen Empfänger schickt z.B. AABBCC an AACCDD01
Wenn der Empfänger jetzt sicher sein soll, das die Message nicht manipuliert ist, würde ich folgendes machen. Ich shcike die Message, also
AABBCC AACCDD01 und danach z.B. die Message noch mal mit dem AES Key durch nen MD5 also so:
MD5(AABBCCAACCDD011111112222222333333334444444) = 7a42db7cc9e13adfdd16f411724f43c5
Dann schicke ich als Funknachricht:
AABBCC 7a42db7cc9e13adfdd16f411724f43c5 an device AACCDD01. Das Device kann die Nachricht ja im Klartext lesen, also es empfängt
AABBCC hängt seine device ID AACCDD01 hintendran und den Key AABBCCAACCDD011111112222222333333334444444 und macht daraus genaus den MD5 und vergleicht es mit dem empfangenen 7a42db7cc9e13adfdd16f411724f43c5. Wenn der Vergleich stimmt, wurde die Nachricht mit dem selben AES key signiert und es kann ein ACK senden.
Problem dabei, der MD5 ist unterschiedlich, je nachdem ob ich MD5(AABBCCAACCDD011111112222222333333334444444) oder MD5(AACCDD01AABBCC1111112222222333333334444444) mache. Es sind also etliche Kombinationen denkbar. Außerdem könnte es auch sein das sie nicht MD5 nehmen sondern etwas anderes. Wenn dann vielleicht noch andere Komponenten einfließen, z.B. das bei der MD5 erstellung noch eine 'geheime' zeichenkette verwendet wird also z.B. MD5(geheimAACCDD01AABBCC1111112222222333333334444444) dann wird man das kaum lösen können.
Viele Grüße
Hallo trilu,
mgernoth hatte hier mit der Analyse schon mal begonnen:
http://forum.fhem.de/index.php/topic,14926.msg96151.html#msg96151
Vieleicht ist das ein Einstieg.
Gruß
Dirk
Hallo trilu
Der Reset-Befehl "r" funktioniert nun bei mir.
reset device, clear eeprom...
reset done
Pairing wird durchgeführt und Fhem erkennt den 6-fach Switch, allerdings stet weiterhin bei Paired: 63 19 63 ?!
Den Schalter-Kanal kann ich genau 1 mal schalten, dann erkennt fhem nichts mehr.
Wie deaktivere bei FHEM die AES-Option/Parameter pro Kanal?
Gruss Peter
Hast du firstload mal auskommentiert?
In register.h ist eine funktion mit der du default-parameter setzen kannst. Schreib statt meiner master Id deine rein und es funktioniert. Aes dürfte fuer den ersten kanal gesetzt sein. Ebenfalls in der mainconfig in register.h. also default richtig setzen, oder firstload auskommentieren 8)
Hallo trilu
Die pairCentral-ID habe ich nun in der register.h umgeschossen und nun wird diese auch angezeigt.
Allerdings frage ich mich nach der Funktion des Befehls "p", wenn man die ID manuell konfiguriert bzw exportiert.
Sollten hier nicht normalerweise das pairing durchgeführt und die Gerätedaten übertragen werden ?
Mit dem Schalter kann ich einmal via "1 0 b" Fhem schalten, dann werden wieder keine Eingangssignale (Wettersensoren, etc.) empfangen ?!
Welcher Wert steckt in den Klammernwerten ?
<- sendStr (247201)
Gruss Peter
Hi Peter,
schalte doch einfach firstLoad aus. Einfach zwei Schrägstriche davor setzen. Ich habe das zum testen eingebaut, so dass ich nicht immer erst peeren muss.
Die Tests die du machst verändern ja nicht die Eepromreihenfolge.
Wenn du p drückst, müsstest du doch in der seriellen Konsole sehen ob du Antworten auf deinen pairing request bekommst?
-> sind empangene Messages für dein Device
<- sind vom Device gesendete Messages
l> sind Log Messages, die nichts mit deinem Device zu tun haben.
Der Wert in den Klammern ist die Systemzeit. Nach jedem Boot des Arduinos startet der millis() timer mit 0 und zählt die Millisekunden mit. Damit kann man das Timing der Strings prüfen. Also z.b. wie lange es dauert bis eine Antwort auf einen Request gesendet wird.
Wenn du 1 0 b sendest, solltest du ein peer eingetragen haben. Drück mal t und poste die config...
Viele Grüsse
Horst
Hallo trilu
firstload hatte ich bereits auskommentiert.
1 0 b -> 6 0 b bzw. 1 1 b 6 1 b führt zu folgendem Peer-Ergebnis:
Peer Database, size: 144 byte
cnl pIdx slcPtr slcEnd phyAddr phyLen list peer
1 0 5 1 9 1 4 22 66 08 01
1 1 6 1 10 1 4 00 00 00 00
1 2 7 1 11 1 4 00 00 00 00
1 3 8 1 12 1 4 00 00 00 00
1 4 9 1 13 1 4 00 00 00 00
1 5 10 1 14 1 4 00 00 00 00
2 0 13 1 18 1 4 22 66 08 02
2 1 14 1 19 1 4 00 00 00 00
2 2 15 1 20 1 4 00 00 00 00
2 3 16 1 21 1 4 00 00 00 00
2 4 17 1 22 1 4 00 00 00 00
2 5 18 1 23 1 4 00 00 00 00
3 0 21 1 27 1 4 00 00 00 00
3 1 22 1 28 1 4 00 00 00 00
3 2 23 1 29 1 4 00 00 00 00
3 3 24 1 30 1 4 00 00 00 00
3 4 25 1 31 1 4 00 00 00 00
3 5 26 1 32 1 4 00 00 00 00
4 0 29 1 36 1 4 00 00 00 00
4 1 30 1 37 1 4 00 00 00 00
4 2 31 1 38 1 4 00 00 00 00
4 3 32 1 39 1 4 00 00 00 00
4 4 33 1 40 1 4 00 00 00 00
4 5 34 1 41 1 4 00 00 00 00
5 0 37 1 45 1 4 00 00 00 00
5 1 38 1 46 1 4 00 00 00 00
5 2 39 1 47 1 4 00 00 00 00
5 3 40 1 48 1 4 00 00 00 00
5 4 41 1 49 1 4 00 00 00 00
5 5 42 1 50 1 4 00 00 00 00
6 0 45 1 54 1 4 00 00 00 00
6 1 46 1 55 1 4 00 00 00 00
6 2 47 1 56 1 4 00 00 00 00
6 3 48 1 57 1 4 00 00 00 00
6 4 49 1 58 1 4 00 00 00 00
6 5 50 1 59 1 4 00 00 00 00
Gruss Peter
hi peter,
danke. du hast zwei peers eingetragen. peer1 ist 22 06 08 01
und peer2 ist 22 06 08 02. das sind beides meine default peers zum testen.
ein 1 o b sendet einen peer string an 22 06 08 an channel 1.
ein 2 o b sendet einen peer string an 22 06 08 an channel 2.
ein 3 0 b wird keinen output liefern, da kein peer eingetragen ist.
viele grüße
horst
Hallo trilu
Du hast Recht, hatte deine peers in der register.h nicht geändert.
Dies habe ich nachgeholt. Erst #define firstLoad; dann //#define firstLoad;
Ein paar Mal 1 0 b 1 1 b, 6 0 b etc. probiert. Danach wird wieder nichts mehr empfangen :-[
Das Pairing legt lediglich die HM-Geäte in Fhem an, aber im Arduino tut sich hier nicht viel (peers anlegen) ?
Gruss Peter
peerdb[0][0] = 0x011247F1;
peerdb[1][0] = 0x021247F1;
peerdb[2][0] = 0x031247F1;
peerdb[3][0] = 0x041247F1;
peerdb[4][0] = 0x051247F1;
peerdb[5][0] = 0x061247F1;
Serial: PS00000001, Model ID: 00 A9 , HMID: 5F B7 4A
Paired: F1 47 12
FreeMem: 915 byte's
Device config, size: 2 byte
cnl lst slcPtr slcEnd phyAddr phyLen
0 0 0 3 0 6
1 1 3 2 6 3
1 4 5 1 9 1
2 1 11 2 15 3
2 4 13 1 18 1
3 1 19 2 24 3
3 4 21 1 27 1
4 1 27 2 33 3
4 4 29 1 36 1
5 1 35 2 42 3
5 4 37 1 45 1
6 1 43 2 51 3
6 4 45 1 54 1
Peer Database, size: 144 byte
cnl pIdx slcPtr slcEnd phyAddr phyLen list peer
1 0 5 1 9 1 4 F1 47 12 01
1 1 6 1 10 1 4 00 00 00 00
1 2 7 1 11 1 4 00 00 00 00
1 3 8 1 12 1 4 00 00 00 00
1 4 9 1 13 1 4 00 00 00 00
1 5 10 1 14 1 4 00 00 00 00
2 0 13 1 18 1 4 F1 47 12 02
2 1 14 1 19 1 4 00 00 00 00
2 2 15 1 20 1 4 00 00 00 00
2 3 16 1 21 1 4 00 00 00 00
2 4 17 1 22 1 4 00 00 00 00
2 5 18 1 23 1 4 00 00 00 00
3 0 21 1 27 1 4 F1 47 12 03
3 1 22 1 28 1 4 00 00 00 00
3 2 23 1 29 1 4 00 00 00 00
3 3 24 1 30 1 4 00 00 00 00
3 4 25 1 31 1 4 00 00 00 00
3 5 26 1 32 1 4 00 00 00 00
4 0 29 1 36 1 4 F1 47 12 04
4 1 30 1 37 1 4 00 00 00 00
4 2 31 1 38 1 4 00 00 00 00
4 3 32 1 39 1 4 00 00 00 00
4 4 33 1 40 1 4 00 00 00 00
4 5 34 1 41 1 4 00 00 00 00
5 0 37 1 45 1 4 F1 47 12 05
5 1 38 1 46 1 4 00 00 00 00
5 2 39 1 47 1 4 00 00 00 00
5 3 40 1 48 1 4 00 00 00 00
5 4 41 1 49 1 4 00 00 00 00
5 5 42 1 50 1 4 00 00 00 00
6 0 45 1 54 1 4 F1 47 12 06
6 1 46 1 55 1 4 00 00 00 00
6 2 47 1 56 1 4 00 00 00 00
6 3 48 1 57 1 4 00 00 00 00
6 4 49 1 58 1 4 00 00 00 00
6 5 50 1 59 1 4 00 00 00 00
Hallo xequtor
Wo hast du dir die CC1101 bestellt ?
Gruss Peter
Hallo,
ich habe diese Module über Aliexpress bestellt (http://www.aliexpress.com/item/5pcs-lot-CC1101-868MHz-wireless-module-distance-for-300m-Free-shipping/1104732817.html) und sie sind gestern angekommen. Der Test mit einem Arduino Mini Pro 3.3V / 8MHz und der aktuellen Version hat funktioniert :).
Viele Grüße,
Peter
Zitat von: PeterS am 27 November 2013, 20:01:14
Hallo xequtor
Wo hast du dir die CC1101 bestellt ?
Gruss Peter
ist schon lange her aber eBay aus China, 4 hab ich hier bestellt http://www.ebay.com/itm/260915795751
da steht 915Mhz aber es ist auch egal da die Freq. programmatisch gesteuert wird.
Zitat von: p2122 am 27 November 2013, 20:11:20
...
Der Test mit einem Arduino Mini Pro 3.3V / 8MHz und der aktuellen Version hat funktioniert :).
Viele Grüße,
Peter
ich kann nicht empfehlen lange Verbindungskabel für den CC1101, manchmal hast Du interfarence und signal loss wenn sie zu lang sind.
Nachdem jetzt die 30 Werktage um waren hab ich mal nachgefragt.
Hongkong post has returned, we have send now with China post....
Man, man, jetzt heisst es wieder warten.
Wie sieht es mit der Reichweite eurer Module aus. Schon mal jemand
direkt verglichen?
Hallo Horst,
die Lieferung meiner Bestellung hat auch sehr lange gedauert (mit Hongkong Post nach Österreich: 3.Okt - 26.Nov).
Wie kann ich die Reichweite am besten testen? Neben einem original Sensor aufstellen und RSSI vergleichen?
Ich plane derzeit kürzere Leitungen und eine Abschirmung für das Modul. Verwenden möchte ich es für die
Adventbeleuchtung im Fenster - ein Helligkeitssensor wäre noch gut, damit es sich nur bei Dunkelheit einschaltet :)
Viele Grüße,
Peter
reichweitentest per rssi ist eins, wobei ich mir nicht sicher bin ob das schon funktioniert. ich schreibe zwar ein paar bits weg, aber ob das so passt ist derzeit ungeprüft.
am einfachsten ist es einen original schalter zu nehmen und die entfernung so lange zu erhöhen bis es schlecht oder gar nicht mehr geht und das selbe mit einem modul zu machen...
für deinen adventskranz kannst du ja schon den dimmer sketch nutzen, der funzt soweit...
viele grüße
horst
Hi Trilu,
heute bin ich auch endlich mal dazu gekommen einen Arduino-Pro-Mini an ein CC1101 Modul zu basteln. Das ganze noch auf dem Steckbrett, das tat aber schon mal.
Tasten drücken usw.
Als erste Anwendung und Platine würde ich mal einen kleinen Umweltsensor Layouten.
Vermutlich auf Basis des Arduino-Pro-Mini.
Als Sensoren hätte ich jetzt gedacht
- BMP180 (Luftdruck)
- TSL2561 (Helligkeit)
- SHT10 (Temperatur / Fechte)
Das sind jeweils I2C Sensoren, so dass das Ankoppeln an den AVR und das Auslesen recht einfach klappt.
Gruß
Dirk
Hi Dirk,
hört sich gut an! Ich habe mittlerer Weile auch die Funkmodule bekommen, kann dir gerne Eins schicken zum Maß nehmen.
Eignen sich die Sensoren für Batteriebetrieb? Wenn ja, wäre es Cool wenn du schon beim Layouten darauf achten könntest, dass sie in eine
wetterfeste Dose passen, am besten mit Platz für zwei Babyzellen. Dann muss man nicht so oft für den Batteriewechsel ans Gehäuse :-)
Viele Grüße
Horst
Bei einem solchen batterietauglichen HM-Umweltsensor hätte ich auf jeden Fall Interesse an 2-3 Stück :-)
Hi Peter,
ich glaube du hast den Unterschied zwischen Peer und Pair noch nicht ganz verstanden :-)
Ein Pair ist die Zentrale, hat 3 Byte und sollte eine eindeutige Adresse besitzen.
Ein Peer sind zwei Geräte die miteinander Verbunden sind.
Z.b. wird ein Schalter mit einem Dimmer gepeert. Das hat den Vorteil das der Schalter den Dimmer direkt ansprechen kann.
Ansonsten würde die Kommunikation vom Schalter an die Zentrale gehen und diese würde die Einstellung an den Dimmer schicken...
Die Peers kannst du am besten mit der HM Config Soft setzen, geht aber auch in FHEM.
Viele Grüße
Horst
Zitat von: PeterS am 26 November 2013, 21:31:57
Paired: F1 47 12
1 0 5 1 9 1 4 F1 47 12 01
2 0 13 1 18 1 4 F1 47 12 02
...
Hi Trilu,
ZitatIch habe mittlerer Weile auch die Funkmodule bekommen, kann dir gerne Eins schicken zum Maß nehmen.
Gerne, meine 433 Mhz Module sehen rein optisch aber genau so wie die 866 Mhz Module aus, die Pinbelegung stimmt auch.
Ich habe aber auch noch eine Bestellung der 868er Module offen und hoffe eigentlich jeden Tag auf die Lieferung.
ZitatEignen sich die Sensoren für Batteriebetrieb?
Das ist der Plan. Allerdings sind die Arduinos dazu nur bedingt geeignet, da die Power-LED sich hier nicht abschalten lässt.
Somit muss die Leiterbahn die die LED und den internen Spannungswandler versorgt dann durchtrennt werden.
Ich will aber 2 Layouts machen. Einmal als Shield und einmal als Version mit standalone AVR.
ZitatWenn ja, wäre es Cool wenn du schon beim Layouten darauf achten könntest, dass sie in eine
wetterfeste Dose passen, am besten mit Platz für zwei Babyzellen.
Ja, Gehäuse wird sicherlich eine Herausforderung. So was hier: http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g250c.html ist zwar schön dicht, aber ohne Loch für Luftdruckmessungen nicht so geeignet. Auch als Außenthermometer wohl nicht so gut, wenn hier noch der Helligkeitssensor im Sommer genutzt werden soll.
Gruß
Dirk
lass uns doch besser solche dosen nehmen
http://www.pollin.de/shop/dt/NzMxOTQ0OTk-/Haustechnik/Installationsmaterial/Dosen_Verteiler/Kabelabzweigkasten_mit_Klemme_WISKA_COMBI_308_IP66.html
da gibts so durchbrüche zum sensoren nach aussen führen...
Dann müssten die Sensoren aber auf je eine extra Platine und dafür bräuchte man dann wiederum kleine Gehäuse.
Als Gehäuse für Luftdruck / Temp / Feuchte währ das hier ganz gut. Das passt dann auch zu den HMS-Geräten und so. Das hätte auch ein Batteriefach.
http://www.elv.de/kleingeraete-gehaeuse.html.
Hier sollten wir noch mal recherchieren.
Vermutlich wird man den Helligkeitssensor außen aber eh nicht in einem Gehäuse mit Temperatur / Luftfeuchte packen.
Gruß
Dirk
ich finde die idee mit helligkeit für draussen aber gar nicht so schlecht - wenns draussen dunkel wird kann man
z.b. die jalousie runter fahren lassen, oder eine flurbeleuchtung angehen, usw...
bei den aussparungen dachte ich nicht an extra platinen, sondern die fühler mit kabel nach aussen führen
und die durchbrüche dann mit silikon abdichten :-)))
dann wäre zumindest platine geschützt und fühlen würden nicht die doseninnentemperatur messen....
Ich glaube Dirk meint, dass er den Helligkeitssensor direkt ins Sonnenlich packen will, was für einen Temperaturfühler eher suboptimal ist...
Kommt aber drauf an, ob man die Sonnenlichthelligkeit oder eher die Umgebungshelligkeit messen will... Ich würde meinen Sensor auch eher irgendwo an die geschützte Nordseite setzen und wenn es dort zu finster wird, meine Innenbeleuchtung schalten.
Zitat von: Dirk am 02 Dezember 2013, 15:20:29
Dann müssten die Sensoren aber auf je eine extra Platine und dafür bräuchte man dann wiederum kleine Gehäuse.
...
Gruß
Dirk
such bei conrad.de nach Kleingeräte-Gehäuse gibts billiger und viel mehr, hab paar vor kurzem gekauft.
Es gibt mal wieder was neues zum testen. Paket liegt im ersten Post...
Ich habe versucht in diesem Sketch einen WM55 nachzubilden.
Hardwareänderungen:
An Digitalpin 4 ist eine Led gegen Masse angeschlossen ( Statusled)
An Digitalpin 8 ist ein Taster gegen Masse angeschlossen ( Config Taster)
An Analogpin A0 - A5 sind weitere 6 Taster gegen Masse angeschlossen ( Funktionstaster)
Softwareänderung:
Für die Led, wie für die Pins gibt es eine eigene Klasse.
Die 6 Funktionstaster lassen sich wie das Original konfigurieren, Tastensperre und Long Press sollten funktionieren.
Ich habe das mit diversen Geräten gepeert und läuft soweit.
Der Konfigurationstaster verhält sich ähnlich wie das Original. Taste kurz betätigen und das Gerät sendet seinen pairing String.
Taste 5 - 6 Sekunden drücken bis die Led anfängt zu blinken, dann Taste kurz loslassen und wieder 5-6 Sekunden die Taste drücken um einen Konfigurationsreset auszulösen. Zur Bestätigung blinkt die Led 3 x kurz.
Powermanagement ist noch nicht implementiert, kommt aber jetzt dran, da ich endlich die Interrupts habe um das Gerät aufzuwecken.
Viel Spass beim testen...
Zitat von: trilu am 02 Dezember 2013, 12:57:14
Ich habe mittlerer Weile auch die Funkmodule bekommen
Viele Grüße
Horst
Hallo trilu,
hast Du schon einen Reichweiten-Test gemacht, vielleicht im Vergleich zum TRX Modul von ELV ?
Falls Dein Angebot noch steht, würde ich Dir gerne ein Funkmodul abnehmen :-)
Grüsse Martin
nein, ich hab noch keins angeschlossen, bin immer noch mit der lib gut beschäftigt.
schick mir mal deine kontaktdaten als private message, dann pack ich dir ein modul in den briefumschlag...
ich hab mich jetzt mal mit den power saving modes beschäftigt, derzeit bin ich bei 100uA und komme nicht weiter runter :(
ich weiss aber auch nicht an was es liegt, getestet habe ich mit einem panstamp, also einzelmessung von cpu und cc1101 nicht möglich.
den cc1101 habe ich über cc1101_idle, gefolgt von einem cc1101_pwdn in den power down mode geschickt. er wird danach auch nicht mehr gepollt, oder so...
die avr habe ich über SLEEP_MODE_PWR_DOWN in den schlaf geschickt, vorher auch schön die einzelnen HW teile abgeschaltet....
ich werd am wochenende mal einen arduino und ein funkmodul zusammen stecken und weiter testen.
ansonsten funzt der letzte sketch prima, über konfig taste aufwecken, konfigurieren, peeren, usw.
über tasten interrupt aufwecken um dimmer zu steuern...
wenn ich jetzt noch die stromaufnahme auf ein paar uA senken könnte, wäre das ding abgeschlossen und wir könnten zum nächsten gerät wechseln.
viele grüße
horst
ich brauche mal eure hilfe. bin gerade dabei eine dokumentation zu machen, ist das der richtige level?
verständlich?
ist erst der anfang, die library spezifischen sachen kommen da noch rein...
Hallo trilu
Der Level ist ok. Besser als bei EQ-3 selbst :-)
Für mich könnte es noch etwas tiefer gehen. ::)
Vielleicht kann man technische Details noch auch in einem separatem Abschnitt oder Kapitel unterbringen?
Gruss Peter
Hallo Zusammen
Da meine Kombination Arduino Nano (5V-16MHz)+CC1101 von ELV immer noch Probleme beim Pairing macht, überlege ich mir welche weitere Kombination sinnvoll wären.
Der Vorteil des Nanos ist die Programmierung und Spannungsversorgung via USB. Für Tests habe ich mir mal einen anderen Level Converter (5-3,3 V) bestellt.
Der Arduino Mini Pro benötigt ein FTDI-Breakout für die Spannungsversorgung + Programmierung :-(
Das Panstamp-Modul benötigt einen panStick zum Programmieren und auch eine separate Spannungsversorgung.
Nutzt ihr alle den Arduino Mini Pro 3,3V oder Panstamp ?
Gruss Peter
Hi,
Zitat von: trilu am 04 Dezember 2013, 17:22:22... bin gerade dabei eine dokumentation zu machen, ist das der richtige level?
Hmmm... Auf der Fhem-Homepage gibt es eine Statistik (mit Weltkarte), wo es die meisten Fhem-Installationen gibt. Der englischsprachige Raum gehört eher zu den weniger vertretenen Bereichen. Deshalb habe ich die Befürchtung, dass deine Doku den falschen Anwenderkreis adressiert.
Aber: Deine Entscheidung.
Gruß
Thomas
Hallo Trilu,
ich finde es gut das du das zusammenfasst und in eine Doku gepackt hast.
Allerdings währ ich vorsichtig diese Doku mit einer Lizenz zu versehen.
Das Protokoll und das Handling drum herum ist ja keine Eigenentwicklung. Daher könnte der "Erschaffer" des Protokolls das ganze missfallen.
Bei der Bibliothek die du geschaffen hast, sieht das ganze natürlich anders aus. Da dieses dein Werk ist.
Viele Grüße
Dirk
Update:
Nach nochmaligem lesen merke ich, das sich die Lizenz wohl auf die Library bezieht.
Vielleicht sollte man den Library-Teil und den Protokollbeschreibungsteil trennen. Damit es keine Missverständnisse gibt.
Hi Peter,
ich habe beides 8)
Ich nutze aber nicht den panstamp Programmierstick. Mir reicht das FTDI Board. Vom Prinzip bevorzuge ich aber die Mini Pro's, die haben einen Spannungsregler on board.
Den panstamp per FTDI board zu programmieren ist aber etwas tricky, du brauchst einen 100nF Kondensator zwischen DTR und Reset, sonst wird es nichts mit dem automatischen programmieren.
Wie gesagt, die panstamps sind ganz nett, aber im Vergleich zu dem China Zeug viel zu teuer. Der Mini Pro kostet zwischen 3 und 5 Dollar, das Funkmodul ist bei etwa 4 bis 5 Dollar, damit kostet dich die Lösung zwischen 7 und 10 Dollar, Versand inklusive. Das FTDI board brauchst du ja für beide Lösungen. Wobei das aber auch nicht die Welt kostet.
Ausserdem brauchst du, egal wie viele Mini Pro's du programmierst, das FTDI board nur einmal.
Du musst nur darauf achten, dass das FTDI board auch 3,3 Volt kann. Es gibt welche die können nur 5 Volt.
Viele Grüße
Horst
Zitat von: PeterS am 04 Dezember 2013, 21:09:33
Da meine Kombination Arduino Nano (5V-16MHz)+CC1101 von ELV immer noch Probleme beim Pairing macht, überlege ich mir welche weitere Kombination sinnvoll wären.
Der Vorteil des Nanos ist die Programmierung und Spannungsversorgung via USB. Für Tests habe ich mir mal einen anderen Level Converter (5-3,3 V) bestellt.
Der Arduino Mini Pro benötigt ein FTDI-Breakout für die Spannungsversorgung + Programmierung :-(
Das Panstamp-Modul benötigt einen panStick zum Programmieren und auch eine separate Spannungsversorgung.
Nutzt ihr alle den Arduino Mini Pro 3,3V oder Panstamp ?
Zitat von: trilu am 04 Dezember 2013, 09:47:47
wenn ich jetzt noch die stromaufnahme auf ein paar uA senken könnte, wäre das ding abgeschlossen und wir könnten zum nächsten gerät wechseln.
Bin gerade neugierig, welches Gerät Du als nächstes machen willst.
Vielleicht einen "einfachen" Batterie-Aktor ? (HM-LC-SW1-BA-PCB)
Interesannt dabei währe, das Aufwecken per Burst aus dem "Sleep-Mode" ;)
Grüsse Martin
Hallo Zusammen,
ich habe mich gestern Abend mal mit den China Funkmodulen beschäftigt. Erster Eindruck: Klasse!!
Ich habe ein Modul auf ein Stück Lochraster geklebt, 8 Pins angelötet und mit einer feinen Litze von 2mm Rater der Module
auf 2,54 mm Lochraster verdrahtet. Testaufbau war Steckbrett mit Arduino Pro Mini 8MHz und Lochrasterfunkmodul.
Reichweite mit Drahtantenne wie die original Module. Schnittstellenverhalten wie Original...
Also absolut geeignet für meine Bastel vorhaben.
Durch die Trennung von Funk und Arduino konnte ich auch ein wenig messen wo mein Problem mit dem Stromverbrauch im sleep mode ist.
Funkmodul geht runter auf ein paar nano Ampere, also nicht mehr Messbar mit meinem Messgerät.
Der Arduino braucht jetzt allerdings etwa 270 uA im deep sleep. ADC, etc sind abgeschaltet. Ich werde jetzt am Wochenende mal den
Spannungsregler und die Led auf dem Pro Mini lahm legen und erneut messen.
ZitatBin gerade neugierig, welches Gerät Du als nächstes machen willst.
Vielleicht einen "einfachen" Batterie-Aktor ? (HM-LC-SW1-BA-PCB)
Gute Idee, den habe ich zu Hause und kann somit 1:1 testen. Zusätzlich will ich eine neue Class bauen mit der man einfach die Ausgänge schalten kann.
Ich habe gesehen es gibt für die ganzen Actuatoren jede Menge Variablen. Für Zeitsteuerung, etc...
Viele Grüße
Horst
Pünktlich zum Wochenende sind auch meine Module gekommen.
Ich werde am Wochenende auch mal ein Reichweitentest machen.
Gruß
Dirk
Hallo,
ZitatIch werde am Wochenende auch mal ein Reichweitentest machen.
Hier die Ergebnisse meines Tests durch ein Paar Wände/Türen zwischen einem HM-LAN und einem HM_HM_LC_SW1_BA_PCB:
HMLAN_RSSI -59: ELV TRX868
HMLAN_RSSI -56: China CC1101-Modul (886Mhz Version)
HMLAN_RSSI -80: China CC1101-Modul (433Mhz Version)
Zum Einsatz kam jeweils eine Drahantenne in identischer Länge wie am ELV TRX868-Modul
Gruß
Dirk
Danke! Das bestätigt meinen ersten Eindruck.
Die Werte des 433 Moduls kommen sicherlich von dem RC Setup auf 433...
Unterm Strich heissen die Werte, die China Module sind mindestens so gut wie die TRX Module. Bleibt abzuwarten wie sich die fehlende Abschirmung auswirkt.
Viele Gruesse
Horst
ZitatDie Werte des 433 Moduls kommen sicherlich von dem RC Setup auf 433...
Ja, das "Netzwerk" aus
Balun, Spulen und Kondensatoren ist hier auf 433Mhz abgestimmt. Daher der viel schlechtere Wert beim 433Mhz Modul.
Davon bin ich aber ausgegangen. Das Modul hatte ich nur als Vergleich genommen.
Gruß
Dirk
Update:
Die Platinen haben ja gar kein Balun. Da hatte ich im Schaltplan vom CUL gespickt.
Die Antennenanpassung ist hier diskret aus Kondensatoren und Spulen aufgebaut.
Zitat von: PeterS am 04 Dezember 2013, 21:09:33
Hallo Zusammen
Da meine Kombination Arduino Nano (5V-16MHz)+CC1101 von ELV immer noch Probleme beim Pairing macht, überlege ich mir welche weitere Kombination sinnvoll wären.
Der Vorteil des Nanos ist die Programmierung und Spannungsversorgung via USB. Für Tests habe ich mir mal einen anderen Level Converter (5-3,3 V) bestellt.
...
wie verbindest Du deinen Level Converter (5-3,3 V) ?
Ich hab paar Konverter aber bin nicht sicher welche Pins wo gehen sollen CC1100 <-> Level Converter <-> Arduino
Die Levelkonverter gehören zwischen die Pins
Miso, Mosi, Sck, Cs, GDO0
Input von AVR gesehen: Miso, GDO0
Output von AVR gesehen: Mosi, Sck, CS
Ein weiteres Problem könnten die 16 MHz Takt sein, die Beeinflussen direkt den SPI Takt.
Eine Lösung könnte sein den Taktteiler anzupassen
Viele Grüsse
Horst
Zitat von: trilu am 08 Dezember 2013, 08:23:03
...
Ein weiteres Problem könnten die 16 MHz Takt sein, die Beeinflussen direkt den SPI Takt.
Eine Lösung könnte sein den Taktteiler anzupassen
Viele Grüsse
Horst
ich hab hier paar ATmega32U4 8Mhz Development Boards soll also kein Problem sein.
Du schreibst output MOSI, SCK,CS aber input MISO,GDO0 (welches ist cc1100 und arduino?) also mit einem Levelkonverter mit 2in 2out pins komme nicht weiter oder?
Input, output ist gesehen vom arduino.
Ich wuerde den level konverter zumindest fuer miso, mosi und sck verwenden. Gdo0 und cs gehen auch ueber widerstände.
Es geht ja hier nur um logik signale. Nimm 1k und pack sie dazwischen...
Mit welcher Frequenz kommen die Daten denn aus den Pins?
Wenn die nicht zu hoch ist, sollte auch ein Levelconverter aus einem einfachen Spannungsteiler ausreichen (2 Widerstände).
Mit meinem 5V - ISP-Programmer z.B. Programmier ich auch 3,3 V AVR's mit einfachen Spannungsteiler ohne Probleme.
Den Levelconverter braucht es auch nur für die Signale die zum CC1101 verlaufen, wie trilu bereits sagte (SI, SCLK, CSN)
Signale zum Arduino können direkt verbunden werden. Die AVR's erkennen 3V auch als High.
Übrigens teste ich derzeit (mangels Alternativen) mit einem 5V/16Mhz Arduino, welcher allerdings nur mit 3V Läuft. (2 AAA-Zellen direkt an VCC) Das Funktioniert bisher prima.
Gruß
Dirk
Update:
Aus: http://www.mikrocontroller.net/articles/Pegelwandler#5_V_.E2.87.94_3.2C3_V
(http://www.mikrocontroller.net/wikifiles/6/64/Pw_st_5-3.png)
Spannungsteiler mit 680 Ω und 1 kΩ. Der Nachteil dieser Lösung ist der relativ hohe Stromverbrauch (~3mA), der relativ geringe Ausgangsstrom (mehr als 200..300 µA sollte man da nicht rausziehen) und die relativ geringe Geschwindigkeit (ca. 10 MHz).
@Dirk - soweit ich weiss, hat der 328 auch einen internen Clock Generator. Den müsstest du per Fuse einschalten koennen. Damit koenntest du den 16MHz AVR auf die 8 MHz bringen. Was dann wieder zu den 3Volt passen wuerde.
Ich werde heute Nachmittag mal schauen auf welchen Takt der SPI gesetzt ist...
Aktuell läuft das Ganze ja erstmal.
Ich hatte im Datenblatt auch mal nach dem Diagramm Versorgungsspannung / Takt welches ich von anderen AVR-Typen kenne gesucht, aber irgendwie nicht gefunden. Daher nehme ich mal an dass die 16 Mhz über den gesamten Versorgungsspannungsbereich funktionieren.
8 Mhz Arduinos für die Zielsysteme sind aber auch noch unterwegs.
Zum testen spielt das bestimmt auch keine grosse rolle. Bei produktiv einsatz waere ich vorsichtiger...
Mehr frequenz heisst mehr verlust, deshalb mehr spannung...
http://i.stack.imgur.com/98hvi.jpg
Ich glaube du suchst diese grafik 8)
es gibt ein neues update zum 6 tasten switch sketch auf der ersten seite.
der power saving mode funktioniert jetzt wie erwartet, stromverbrauch im power mode 3 und 4 ist kleiner 1ua.
also nicht mehr messbar mit meinem messgerät. damit könnte man den switch mit einem satz batterien so lange betreiben, wie
die selbstentladungsrate der batterien her gibt...
Zitathttp://i.stack.imgur.com/98hvi.jpg
Ich glaube du suchst diese grafik
Das ist korrekt.
Zitatstromverbrauch im power mode 3 und 4 ist kleiner 1ua.
Das klingt ja super. Danke für deine Arbeit.
Dann kann ich meine FS20-Selbstbautaster ja nun langsam auf HM umrüsten. :)
Gruß
Dirk
@dirk
gerne doch - bitte teste aber auch noch mal die funktionalität. ich habe meinen selbstbautaster derzeit mit einem dimmer gepeert und das funktioniert einwandfrei. ich habe noch nicht getestet wie es sich mit mehreren peers verhält...
zum thema spi-takt, ich initialisiere derzeit den spi wie folgt
SPCR = _BV(SPE) | _BV(MSTR); // SPI speed = CLK/4
_BV(SPE) - enables spi device
_BV(MSTR) - configure SPI device as a master
SPI2X SPR1 SPR0 SCK Frequenz
0 0 0 fOSC/4
0 0 1 fOSC/16
0 1 0 fOSC/64
0 1 1 fOSC/128
1 0 0 fOSC/2
1 0 1 fOSC/8
1 1 0 fOSC/32
1 1 1 fOSC/64
d.h. ich initzialisiere den spi port mit clk/4
wenn ihr jetzt einen arduino mit 16mhz habt, würde es sinn machen den port mit clk/8 zu initialisieren.
also folgende zeile in asksin.cpp/cc:init zu verwenden:
SPCR = _BV(SPE) | _BV(MSTR) | _BV(SPI2X) | _BV(SPR0);
update: gerade noch mal den stromverbrauch mit arduino pro mini und funkmodul getestet, hier sind es ~30uA mit still gelegter power led. der mehrverbrauch liegt vermutlich am nicht stillgelegtem power regler...
viele grüsse
horst
Hi Host,
ich habe jetzt mal einiges durchprobiert.
Peeren mit einem Aktor geht, allerdings schaltet dieser nicht zuverlässig.
Testobjekt war ein HM_LC_SW1_BA_PCB
Manchmal geht das Schalten, manchmal aber auch nicht. Nachdem ich am Aktor manuell geschaltet hatte lässt sich dieser dann wieder schalten. Sieht aus, als ob da was "synchronistert" werden muss
Beim Pairen mit FHEM gibt es übrigens ein "RESPONSE TIMEOUT:RegisterRead".
Auch beim manuellem getConfig gibts diesen Timeout
Aktuelle Habe ich nur 2 Taster (A0, A1) angeschlossen. Den Config-Taster und die LED natürlich noch.
Bei A1 geht nur der lange Tastendruck. Bei kurzem Tastendruck blinkt nur die Status-LED. Das Debug-Log gibt hier auch nix aus.
A0 macht beides, Kurz und lang.
SPI habe ich auf clk/8 gesetzt.
Gruß
Dirk
Hallo trilu
Der 131208_sketch bringt bei mir neben dem nomalen Header nur ein:
FreeMem: 709 byte's
t:0
Commandos werden keine erkannt und ausgeführt ?!
Downgrade auf 131202_sketch und alles funktioniert (ausser pairing)
Gruss Peter
Hi Peter,
Kommandos per UART wurden bei mir auch nicht angenommen.
Die letzte Version scheint nur auf die externen Taster zu reagieren
Gruß
Dirk
Hallo Zusammen
Habe mal meine neuen "Level Converter" getestet.
http://www.adafruit.com/products/757
Wenn du 2-Teile für 5 Ports dazwischen hängen, geht nur noch die LED13 an und der Serialport protokolliert nix mehr :-(
Hat noch jemand einen Tip für meinen 5V Arduino Nano.
Werde wohl auch auf den Arduino Mini Pro 3,3V umsteigen müssen.
Auch wenn mir die Lösung mit den FTDI Breakout Boards nicht so gefällt.
@Dirk: Nutzt du den Serial-Port, wenn du auf Batteriebetrieb bist ?
Gruss Peter
ZitatNutzt du den Serial-Port, wenn du auf Batteriebetrieb bist ?
Ja, dann sind aber nur RX, TX und GND verbunden.
RX sollte dann aber auch über einen Widerstand angeschlossen werden.
Hier kommen vom USB->UART-Converter ja auch 5V an.
ZitatBeim Pairen mit FHEM gibt es übrigens ein "RESPONSE TIMEOUT:RegisterRead".
Auch beim manuellem getConfig gibts diesen Timeout
Kannst du mir bitte die Logs schicken, bei denen es zum timeout kommt? Das ganze kann ja mehrere Ursachen haben und ich muss zumindest wissen, bei welchen Abfragen es passiert. Ich könnte mir vorstellen das der Schalter schläft, während du dir Register abfragst. Drück einfach mal die Config Taste, dann bleibt das Gerät für 15 Sekunden wach. Normalerweise müsste das für FHEM reichen.
ZitatKommandos per UART wurden bei mir auch nicht angenommen.
Die letzte Version scheint nur auf die externen Taster zu reagieren
Das Eingaben an der seriellen Konsole nicht funktionieren ist klar, die CPU befindet sich im Tiefschlaf, da funktionieren nur Watchdog und externe Interrupts zum wecken...
Wenn ihr über die serielle Konsole die Basisfunktionalität testen wollt, dann schaltet den Power Mode um auf 0. hm.setPowerMode(0); im main sketch.
Über den Config Taster kann man durch kurzes Drücken einen pairing string senden, danach bleibt das Gerät etwa 15 sec wach.
Danach geht es wieder in deep sleep, dabei ist dann auch kein Empfang mehr möglich.
Über den Config Taster kann man auch einen Device Reset initiieren. Dazu den Taster so lang drücken, bis die Led das blinken anfängt, dann den Taster kurz los lassen und erneut für 5-6 Sekunden drücken. Led blinkt zur Bestätigung drei mal schnell und das Device setzt sich komplett zurück. Peers und Pairs werden gelöscht...
ZitatPeeren mit einem Aktor geht, allerdings schaltet dieser nicht zuverlässig.
Testobjekt war ein HM_LC_SW1_BA_PCB
Hast du das Burst Bit im Schalter gesetzt? Du erkennst das auch im Logfile, die Zeile muss dann so aussehen:
<- 0A 01 B0 .....
Interessant ist hier das B0 - das ist eine Message mit gesetztem Burst Bit, ansonsten wäre hier ein A0...
@PeterS
Das mit deinem nicht funktionierendem Pairing lässt mir ja irgendwie keine Ruhe. Bitte beschreibe mal wie du beim pairen vorgehst.
Wichtig um das Device sauber zu pairen ist:
In FHEM darf kein Gerät existieren das die selbe HMID hat, wie das Gerät das du pairen willst. Also zu aller erst, fhem.cfg bereinigen und FHEM neu starten.
Die HMID definierst du in register.h über
static uint8_t HMID[3] = { 0x5F, 0xB7, 0x4A };
Der EEprom des Testgeräts muss aufgeräumt sein. Nimm bitte den letzten Sketch, ändere
hm.setPowerMode(0); im main sketch um. Compilieren und aufspielen....
Jetzt an der seriellen Konsole ein <r> eingeben und return drücken. Jetzt steht sowas wie reset done in der Konsole und dein EEprom sollte ordentlich sein.
Kannst du testen durch Eingabe von <e> return an der Konsole. Hier sollten nur die ersten zwei Byte belegt sein.
Jetzt gehst du in FHEM auf deinen CUL oder HM-Lan und gibst im Feld pairForSec 600 ein und drückst die Set Taste.
In der seriellen Konsole gibst du jetzt ein <p> gefolgt von return ein. Jetzt müsste im Log file etwas passieren, wenn nicht, dann drückst du noch einmal p...
Wenn sich das Log wieder beruhigt hat, drückst du <e> return und schaust dir den EEprom Inhalt an, jetzt müsste deine pair ID im EEprom eingetragen sein.
Kannst du das mal testen?
Zitat von: trilu am 08 Dezember 2013, 09:39:27
Input, output ist gesehen vom arduino.
Ich wuerde den level konverter zumindest fuer miso, mosi und sck verwenden. Gdo0 und cs gehen auch ueber widerstände.
Es geht ja hier nur um logik signale. Nimm 1k und pack sie dazwischen...
ich hab den Level Konverter für MOSI und SCK genommen und 1k/680 für CS und soweit funktioniert.
Hallo trilu
Habe alle Schritte mit der dem 131208_sketch durchgeführt.
Leider ohne verbessertes Ergebnis:
Gruss Peter
Fhem.cfg:
define CUL_HM_HM_PB_6_WM55_F10815 CUL_HM F10815
attr CUL_HM_HM_PB_6_WM55_F10815 .devInfo 060000
attr CUL_HM_HM_PB_6_WM55_F10815 .stc 40
attr CUL_HM_HM_PB_6_WM55_F10815 firmware 1.1
attr CUL_HM_HM_PB_6_WM55_F10815 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815 room CUL_HM
attr CUL_HM_HM_PB_6_WM55_F10815 serialNr PS00000001
attr CUL_HM_HM_PB_6_WM55_F10815 subType remote
define FileLog_CUL_HM_HM_PB_6_WM55_F10815 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815-%Y.log CUL_HM_HM_PB_6_WM55_F10815
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815 room CUL_HM
define CUL_HM_HM_PB_6_WM55_F10815_Btn_01 CUL_HM F1081501
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_01 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_01 peerIDs
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_01 room CUL_HM
define FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_01 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815_Btn_01-%Y.log CUL_HM_HM_PB_6_WM55_F10815_Btn_01
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_01 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_01 room CUL_HM
define CUL_HM_HM_PB_6_WM55_F10815_Btn_02 CUL_HM F1081502
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_02 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_02 room CUL_HM
define FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_02 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815_Btn_02-%Y.log CUL_HM_HM_PB_6_WM55_F10815_Btn_02
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_02 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_02 room CUL_HM
define CUL_HM_HM_PB_6_WM55_F10815_Btn_03 CUL_HM F1081503
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_03 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_03 room CUL_HM
define FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_03 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815_Btn_03-%Y.log CUL_HM_HM_PB_6_WM55_F10815_Btn_03
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_03 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_03 room CUL_HM
define CUL_HM_HM_PB_6_WM55_F10815_Btn_04 CUL_HM F1081504
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_04 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_04 room CUL_HM
define FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_04 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815_Btn_04-%Y.log CUL_HM_HM_PB_6_WM55_F10815_Btn_04
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_04 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_04 room CUL_HM
define CUL_HM_HM_PB_6_WM55_F10815_Btn_05 CUL_HM F1081505
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_05 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_05 room CUL_HM
define FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_05 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815_Btn_05-%Y.log CUL_HM_HM_PB_6_WM55_F10815_Btn_05
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_05 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_05 room CUL_HM
define CUL_HM_HM_PB_6_WM55_F10815_Btn_06 CUL_HM F1081506
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_06 model HM-PB-6-WM55
attr CUL_HM_HM_PB_6_WM55_F10815_Btn_06 room CUL_HM
define FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_06 FileLog ./log/CUL_HM_HM_PB_6_WM55_F10815_Btn_06-%Y.log CUL_HM_HM_PB_6_WM55_F10815_Btn_06
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_06 logtype text
attr FileLog_CUL_HM_HM_PB_6_WM55_F10815_Btn_06 room CUL_HM
Log Serial-Port:
Serial: PS00000001, Model ID: 00 A9 , HMID: F1 08 15
Paired: 00 00 00
FreeMem: 709 byte's
t:0
reset device, clear eeprom...
reset done
EEPROM listing, start: 0, len: 1023
0000 AF 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DEVICE_INFO; fw: 11, type: 00 A9, serial: 50 53 30 30 30 30 30 30 30 31
, class: 40, pCnlA: 06, pCnlB: 00, na: 00
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(27827)
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(28516)
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(29217)
-> NA (29913)
t:30
EEPROM listing, start: 0, len: 1023
0000 AF 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
t:60
t:90
@PeterS
willst du mich ärgern? ::)
Natürlich wird dein pairing so nicht funktionieren, das Device ist doch in FHEM bekannt. Deshalb schrieb ich ja, du musst vorher das Device aus der fhem.cfg löschen, dann FHEM beenden und neu starten.
Zitat<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(27827)
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(28516)
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(29217)
-> NA (29913)
Was du hier siehst sind pairing requests. Es wird drei mal ein String an broadcast (also alle) gesendet, im Abstand von etwa 700ms
und es kommt keine Antwort. Zu erkennen am -> NA (29913)
NA steht für no answer, oder eben timeout.
Wobei es klar ist das FHEM keine Antwort schickt; das Device ist ja in FHEM bekannt...
Lösch bitte das Device in fhem.cfg, starte fhem neu und drück noch mal p...
Viele Grüße
Horst
Hallo trilu
Natürlich will ich dich nicht ärgern, dabei versuche ich natürlich mich beim Pairingvorgang auch nicht zu ärgern. ;D
Die Konfigurationen in Fhem und Arduino wurden komplett platt gemacht.
Die Fhem-Definitionen wurden beim Pairing angelegt, aber die Einträge im Arduino (Eprom) werden nicht erzeugt ?!
Mehr Infos als die Logs habe ich z.Z. auch nicht. Soll ich noch was protokollieren ?
Gruss Peter
Das kann eigentlich nicht sein...
Pairing läuft wie folgt ab:
Device sendet einen broadcast String, der alle möglichen Infos zum Device enthält, wie Seriennummer, model ID, firmware, etc...
FHEM registriert den String und sendet einen ACK zur Bestätigung
FHEM sendet einen config start string
// Cnl PeerID PeerCnl ParmLst
// l> 10 01 A0 01 63 19 63 1E 7A AD 00 05 00 00 00 00 00
Device sendet einen ACK
FHEM sendet einen config write String
// Cnl Data
// l> 13 02 A0 01 63 19 63 1E 7A AD 00 08 02 01 0A 63 0B 19 0C 63
Device sendet einen ACK
FHEM sendet einen config end String
// Cnl
// l> 0B 01 A0 01 63 19 63 1E 7A AD 00 06
Device sendet einen ACK
Jetzt wäre im Device die PairID im EEprom
und FHEM erzeugt das Device in fhem.cfg
Was ich anhand deines Log's sehe kommst du über den Pairing String nicht hinaus.
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(27827)
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(28516)
<- 1A 00 A2 00 F1 08 15 00 00 00 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(29217)
-> NA (29913)
Hi Trillu,
Ich hatte übrigens das Pairing auch mal mit der CCU getestet.
Das funktioniert so noch nicht. Vermutlich fehlt da beim Pairing noch was.
Ab morgen Abend kann ich wieder mittesten.
Gruß
Dirk
ccu hab ich leider keine, ich teste es mit dem hm-usb-cfg und fhem, oder mit der config soft von hm in zusammenspiel mit dem hm-usb-cfg.
wenn da was fehlt bau ich es gerne ein, aber ich bräuchte halt dazu die log files anhand derer ich sehen kann wo es abbricht.
ziel ist ja nach wie vor, so kompatibel wie möglich...
Zitatich teste es mit dem hm-usb-cfg und fhem, oder mit der config soft von hm in zusammenspiel mit dem hm-usb-cfg.
Hatte ich auch getestet, Auch hier findet die Software kein Gerät.
Wenn es aber hier klappt, sollte es mit der CCU auch funktionieren.
Ich hoffe die Tage auf die Lieferung der 3,3V/8Mhz Arduinos. Dann teste ich hier noch mal.
Gruß
Dirk
ich könnte dir auch einen arduino schicken, hab ja ein paar geliefert bekommen
Da hat aber jemand eingekauft :)
Laut Sendungsverfolgung sind die Teile seit ein Paar Tagen schon in DE.
Daher rechne ich jeden Tag mit der Lieferung.
Bei den Funkmodulen komme ich ggf. nochmal drauf zurück.
Da hatte ich erst mal "nur" 5 geordert.
Gruß
Dirk
Zitat von: PeterS am 09 Dezember 2013, 00:06:02
Hallo Zusammen
Habe mal meine neuen "Level Converter" getestet.
http://www.adafruit.com/products/757
Wenn du 2-Teile für 5 Ports dazwischen hängen, geht nur noch die LED13 an und der Serialport protokolliert nix mehr :-(
...
ich hab den Level Konverter für MOSI und SCK genommen und 1k/680 für CS und soweit funktioniert.
wenn ich es richtig verstanden habe, simuliert der Arduino existierende HM-Geräte. Er sieht also nach außen hin - für HMLAN, aber zur Not auch für eine CCU - aus, wie ein richtiges HM-Gerät.
Nun hätte ich mal ne ganz dumme Frage: kann er sich nur als EIN Gerät ausgeben?
wenn es z.B. mal irgendwann einen Sketch für einen HM-SCI-3-FM gibt, der die Schaltzustände von 3 Kontakten übertragen kann, wäre es dann theoretisch möglich mit einem Arduino 2 oder 3 solcher virtuellen Geräte zu simulieren? GPIOs sind ja nun genug vorhanden. Natürlich brauchte dann jedes der virtuellen Geräte eine eigene HM-ID, und würde auch von der Zentrale als einzelne Geräte behandelt werden, aber wäre sowas prinzipiell machbar?
LG
Jan
Zitatwenn ich es richtig verstanden habe, simuliert der Arduino existierende HM-Geräte. Er sieht also nach außen hin - für HMLAN, aber zur Not auch für eine CCU - aus, wie ein richtiges HM-Gerät.
Das sollte eigentlich so sein.
Zitatwenn es z.B. mal irgendwann einen Sketch für einen HM-SCI-3-FM gibt, der die Schaltzustände von 3 Kontakten übertragen kann, wäre es dann theoretisch möglich mit einem Arduino 2 oder 3 solcher virtuellen Geräte zu simulieren.
Das könnte man sicher machen.
Man könnte man auch eigene Geräte bauen die völlig neue Sachen machen. In FHEM muss dann so ein neues Gerät implementiert werden und in der CCU / HMLAN-Software auch.
Das wiederum würde bedeuten für dieses Gerät eine entsprechende XML-Datei zu Schreiben, dann kann man das auch "ganz normal" mit der CCU / der HMLAN-Software benutzen
Das simulieren von mehreren Geräten, also Kanälen sollte kein Problem sein. Zumindest nicht in FHEM.
Die xml's für die HM Soft, sei es für die Config Soft oder die CCU anzupassen sehe ich schon als größere Herausforderung.
Zumindest habe ich sie noch nicht ganz verstanden :-)
Hi trilu,
super was Du hier auf die Beine stellst - hab mir inzwischen eine Handvoll panstamps besorgt und versucht, 131208_sketch_aug05a auf meiner Installation zu übersetzen:
kubuntu 13.10
avr-g++ (GCC) 4.7.2
arduino 1:1.0.5+dfsg2-1
Dabei kommt es zu folgenden Fehlern:
sketch_aug05a.ino:21:32: error: variable 'cmdTab' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
sketch_aug05a.ino:40:25: error: variable 'jumptable' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
Um diese Fehler zu beheben, musste ich an verschiedenen Stellen const einfügen, die nötigen Änderungen habe ich als Patch angefügt, falls Interesse daran besteht.
Was ich gerne realisieren möchte, ist eine batteriegetriebene LED-Leuchte, die möglichst tief schläft, bis sie per config-taster (für ein pairing) oder per burst-signal geweckt wird. Nach dem Schaltvorgang soll sie sich wieder schlafen legen (aus: möglichst tief; an: bis zum nächsten Schaltvorgang oder Ablauf eines konfigurierbaren Timers). Zudem soll sie 1-2 mal pro Tag den Batteriestand melden und den ActionDetector zufriedenstellen können. Hab mich in die Homematic-Devices noch nicht genügend eingelesen, um zu sehen, was dafür alles benötigt wird oder wie am besten vorzugehen ist und wäre von daher sehr dankbar für Einstiegspunkte. Würde im Gegenzug gern versuchen, die Lösung incl. Schaltplan möglichst nachvollziehbar zu dokumentieren. Ist die AskSin Library prinzipiell schon so weit oder gibt es wesentliche Aspekte, die für eine erfolgreiche Umsetzung noch fehlen?
Danke,
Andy.
Hi Andy,
So etwas bastle ich gerade. Die Frage ist allerdings was du unter Tiefschlaf verstehst :o
Um ein Burstsignal empfangen zu können muss ich den Arduino und das Funkmodul alle 250 ms für 10 ms aufwachen lassen. Das heisst für den Stromverbrauch nichts Gutes. Das Modul wird vermutlich bei 0.1 bis 0.3 ma liegen. Das ist schwer an der Grenze für ein Batterie betriebenes Gerät.
Ansonsten bin ich mit dem Schaltmodul fast fertig. Es fehlt noch Trigger 41 für Sensor Peers. Trigger11 für FHEM und Trgger40 für Remotes ist fertig.
Batteriestand messen geht noch nicht. Da fehlt mir noch die zündende Idee. Soll ja möglichst universell sein und Widerstandsteiler in der Spannungszufuhr kostet zu viel Strom.
Wie möchtest du dein Modul ansteuern? Wenn nur über Fhem, dann könnte ich dir heute Abend was schicken.
Viele Grüsse
Horst
Das mit den const schau ich mir mal an...
Hi Horst,
klingt fantastisch :-)
Ansteuern per FHEM würde fürs erste schon reichen, später zoll zwar ein Bewegungsmelder den Trigger liefern ich vermute mal dass es dabei um Trigger41 geht?), aber FHEM kann gern erstmal Vermittler spielen. Bei der Gelegenheit keimt die verwegene Frage auf, ob bei einem Panstamp sowas wie Firmware-Update over-the-air denkbar ist 8) - aber erstmal zu den "einfachen" Dingen... Zum Batteriestand hatte ich auch noch keine wirklich gute Idee, ist aber auch nicht höchste Priorität.
Sobald Du was hast, werd ichs gern testen!
Beste Grüße,
Andy.
so, mal wieder ein update.
ist noch nicht wirklich komplett und getestet. das ganze ist ein relais sketch.
hat einen channel, der als relais, bzw. schalter dient.
trigger11 sollte komplett gehen. trigger11 ist das was von fhem geschickt wird - auch die timer von fhem sollten gehen
trigger40 läuft bei mir auch, muss aber über die homematic config soft gepeert werden, es sind noch keine default werte in der list3
und ich habe nicht getestet wie sich der channel ohne default werte verhält.
trigger41, also sensoren werden noch nicht unterstützt.
ich habe als hardware nur eine led an pin 3 angeschlossen. konfigurieren lässt sich das relais mit den befehlen:
rl[0].config(1,0,3,0,0,0); // configure the relay to monostable, on pin 3
der erste wert, also die 1, gibt den channel an - in diesem beispiel ist es channel 1
der zweite wert, ob es sich um ein monostabiles oder bistabiles relais handelt, 0 steht für monostabil, 1 für bistabil
der dritte wert gibt den pin1 des relais an, der 4 wert den pin2 und so weiter
bei einem monostabilem relais kann man zwei pins zusammen schalten um das relais anzusteuern. damit kann man sich einen transistor sparen, falls die 20ma schaltstrom pro kanal nicht reichen.
bei einem bistabilen relais sind die ersten beiden ersten werte für die einschaltspule, die beiden letzten werte für die ausschaltspule.
eingestellt ist derzeit power mode 0, also kein stromsparen. power mode2 müsste aber auch funktionieren. ist aber nicht wirklich getestet.
rl[0].setCallBack(&relayState,&hm,1,1);
Hallo trilu,
Meine 3,3V / 8Mhz arduinos sind nun endlich da, und ich konnte hiermit jetzt endlich mal ein Paar Tests machen.
Das ganze funktioniert jetzt schon mal besser. Allerdings immer noch nicht ganz ohne Probleme.
Die HMLAN-Software erkennt den Taster nun, aber will einen Sicherheitscode zum anlernen, den er ja nicht haben kann.
Sehr merkwürdig.
FHEM kann nach wie vor die Register nicht auslesen. Ein getConfig bleibt unbeantwortet.
Hast du noch Ideen was ich testen / Anders machen kann / sollte.
Gruß
Dirk
Hallo Dirk,
ZitatDie HMLAN-Software erkennt den Taster nun, aber will einen Sicherheitscode zum anlernen
Das ist interessant. Das liegt bestimmt daran das Du auch einen eignen AES Signierungsschlüssen in der Software gesetzt hast. Wenn ein eigener Key gesetzt ist, dann ist es ja das bestreben der HMLAN Software, den Schlüssel auf alle Geräte zu verteilen. Die Asksin Library wird aber auf dieses schreiben des Schlüssels nicht (richtig) reagieren, da nicht implementiert. Ich vermute deshalb, das die HMLAN Software deshalb denkt, es wäre schone ein anderer Schlüssel gesetzt ohne den der neue nicht akzeptiert wird.
Ich hatte so etwas ähnliches mal mit einem Problematischen Handsender der Probleme mit dem Funkmodul hat. Obwohl der Key in der Software richtig gesetzt war. Hat mich die Software manchmal nach dem Key gefragt wenn ich ihn neu anlernen wollte.
Grüße
@dirk - der sketch ist im power mode 4, d.h. er reagiert auf funkanfragen nicht. Das ding verhält sich wie ein hm remote. Da musst du ja auch den config taster drücken um das gerät für 20 sekunden empfangsbereit zu haben.
Du kannst aber auch im sketch den power mode auf 0 setzen. Dann ist das gerät immer empfangsbereit.
Auch wichtig ist, du brauchst einen gewissen abstand zwischen zwei geräten. Bei mir ist es ungefähr 1m...
Bezüglich des schlüssels. Die hm software geht davon aus, das alle remotes per default AES an haben. Bei der config soft musste ich in die einzelnen kanäle der remote gehen und die signierung ausschalten. Danach gings dann ohne probleme...
Zitat von: Samsi am 23 Dezember 2013, 13:58:04
Das liegt bestimmt daran das Du auch einen eignen AES Signierungsschlüssen in der Software gesetzt hast.
Mit Sicherheit. Währ aber gut wenn wir das fixen könnten. Ich denke es gibt einige Leute die mit eigenem Schlüssel funken.
Und die Geräteverknüpfungen (Peering) macht mir im Moment viel mehr "Spass" als im FHEM :)
Zitat von: trilu am 23 Dezember 2013, 14:19:59
der sketch ist im power mode 4, d.h. er reagiert auf funkanfragen nicht.
Ist klar. Daher hatte ich dann auch den Config-Taster gedrückt. Er mag dann aber immer noch nicht antworten.
ZitatAuch wichtig ist, du brauchst einen gewissen abstand zwischen zwei geräten. Bei mir ist es ungefähr 1m...
Ja, mein HM-LAN ist etwa 3-4m Luflinie entfernt.
ZitatBezüglich des schlüssels. Die hm software geht davon aus, das alle remotes per default AES an haben. Bei der config soft musste ich in die einzelnen kanäle der remote gehen und die signierung ausschalten.
So kenne ich das auch. Aber wie abschalten, wenn der Taster noch gar nicht angelernt ist?
Oder wie meinst du das?
Gruß
Dirk
AES werde ich stand heute nicht implementieren koennen. Ich weiss derzeit nicht wie verschluesselt wird und was unverschluesselt im string steht.
Beim druecken vom config taster wird der pairing string gesendet. Fhem muss dann darauf antworten. Passiert das bei dir? Oder ab wann stockt die kommunikation. Teste einfach mal im powermode 0, dann hast du zumindest kein problem das der funkchip aus wäre.
Um irgendwas zu fixen brauch ich zumindest einen anhaltspunkt wo es hakt. Bei mir funzt das pairing, das peeren und das register lesen, insofern kann ich auch nicht fixen...
Ich nutze die letzte version der um config soft. Zum anlernen geh ich in der config soft auf anlernen, dann geht ein dialog auf und das ding zaehlt von 60 sekunden runter. Dann drueck ich die config taste und im log wird der pairing string gesendet, daraufhin kommen einige Ack und config strings und im dialog fenster steht das ein neues geraet gefunden wurde... thats it
Naechster schritt ist dann, ich oeffne die einzelnen kanaele und nehm den haken bei aes raus.
Danach klappt dann das peeren problemlos.
Zitat von: trilu am 23 Dezember 2013, 15:58:34
AES werde ich stand heute nicht implementieren koennen. Ich weiss derzeit nicht wie verschluesselt wird und was unverschluesselt im string steht.
Das ist klar. So war das auch nicht gemeint.
Aber vielleicht könnte der Aktor "so tun" als ob er den neuen Schlüssel angenommen hat. Quasi nur einen ACK dafür schickt.
Beim anschliessenden Initialen Konfigurationsaustauch sollte der Aktor dann auf allen entsprechenden Kanälen ein Ausgeschaltetes AES signalisieren. Auch sollten sich die entsprechenden Register nicht aktivieren lassen.
Aber vermutlich läuft es auf ein eigenes XML-File heraus, sofern man das Device per HMM-Lan-SW konfigurieren möchte.
ZitatBeim druecken vom config taster wird der pairing string gesendet. Fhem muss dann darauf antworten. Passiert das bei dir?
Das hier wird hesendet:
<- 1A 29 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(300556)
-> 0A 29 80 02 1A CA E5 5F B7 4A 00 (l:11)<0>(300693)
Ich habe den Test noch mal mit der HM-LAN-SW ohne eigenen Schlüssel wiederholt.
So wird der "Taster" erkannt, aber ist noch nicht nutzbar weil:
Konfigurationsdaten stehen zur Übertragung an Also auch hier erfolgt kein Konfigurationsaustausch.
Das EEprom vom Arduino ist auch noch recht leer. Lediglich die HM-LAN-ID ist eingetragen.
ZitatUm irgendwas zu fixen brauch ich zumindest einen anhaltspunkt wo es hakt. Bei mir funzt das pairing, das peeren und das register lesen, insofern kann ich auch nicht fixen...
Ja, der Fluch des Entwicklers :)
Was für Infos kann ich dir noch schicken?
ZitatIch nutze die letzte version der um config soft.
Ich denke die habe ich auch. Grade noch mal runtergeladen und nackig in eine VM eingespielt.
ZitatZum anlernen geh ich in der config soft auf anlernen, dann geht ein dialog auf und das ding zaehlt von 60 sekunden runter. Dann drueck ich die config taste und im log wird der pairing string gesendet, daraufhin kommen einige Ack und config strings und im dialog fenster steht das ein neues geraet gefunden wurde... thats it
Gleiche Vorgehensweise hier.
Aber dann können die "Konfigurationsdaten nicht übertragen werden. Anbei mal ein Log.
<- 1A 34 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(420507)
<0>-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420739)
<0>-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420937)
<0>-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(421136)
<0><- 0A 01 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421206)
<0>-> 13 02 A0 01 1A CA E5 5F B7 4A 00 08 02 01 0A 1A 0B CA 0C E5 (l:20)<0>(421500)
<0><- 0A 02 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421515)
<0>-> 0B 03 A0 01 1A CA E5 5F B7 4A 00 06 (l:12)<0>(421804)
<0>config changed
<- 0A 03 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421810)
<0>-> 10 04 A0 01 1A CA E5 5F B7 4A 00 04 00 00 00 00 00 (l:17)<0>(422105)
<0><- 18 04 A0 10 5F B7 4A 1A CA E5 02 01 00 02 01 0A 1A 0B CA 0C E5 18 00 00 00 (l:25)<0>(422117)
<0>-> 11 04 A0 02 1A CA E5 5F B7 4A 04 BF 29 8F C1 A0 9D 00 (l:18)<0>(422258)
<0>-> 10 0D A0 01 1A CA E5 5F B7 4A 01 04 00 00 00 00 01 (l:17)<0>(422703)
<0><- 12 0D A0 10 5F B7 4A 1A CA E5 02 04 00 08 00 09 00 00 00 (l:19)<0>(422809)
<0>-> 11 0D A0 02 1A CA E5 5F B7 4A 04 76 E0 46 08 69 54 00 (l:18)<0>(422961)
<0>l> 0B 1E A2 58 18 6F 30 18 60 F1 00 00 (l:12)<0>(435093)
<0>l> 0E 1E 82 02 18 60 F1 18 6F 30 01 01 00 00 25 (l:15)<0>(435226)
<0>
Gruß
Dirk
Das mit dem AES ist leider nicht so einfach. Der Master schickt einen AES String und erwartet natürlich einen AES String zurück, dieser wird auch geprüft.
Also irgendwas funktioniert nicht und blöderweise sieht der Antwortstring jedes mal anders aus, also einfach merken geht auch nicht...
Das ist eine perfekte Kommunikation - der ausgehende String ist ein Pairing String,
der zurückkommende ist ein ACK, also alles OK
<- 1A 29 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(300556)
-> 0A 29 80 02 1A CA E5 5F B7 4A 00 (l:11)<0>(300693)
<- 1A 34 A2 00 5F B7 4A 1A CA E5 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)<0>(420507) - pairing string
-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420739) - einleiten der config für kanal 0
-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(420937)
-> 10 01 A0 01 1A CA E5 5F B7 4A 00 05 00 00 00 00 00 (l:17)<0>(421136)
<- 0A 01 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421206) - ACK für das einleiten der config von deinem device
-> 13 02 A0 01 1A CA E5 5F B7 4A 00 08 02 01 0A 1A 0B CA 0C E5 (l:20)<0>(421500) - schreiben der pair id in list0
<- 0A 02 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421515) - ACK von deinem device
-> 0B 03 A0 01 1A CA E5 5F B7 4A 00 06 (l:12)<0>(421804) - message zum beenden der config
config changed - event aus dem main sketch
<- 0A 03 80 02 5F B7 4A 1A CA E5 00 (l:11)<0>(421810) - ACK von deinem device
-> 10 04 A0 01 1A CA E5 5F B7 4A 00 04 00 00 00 00 00 (l:17)<0>(422105) - config param request für channel 0
<- 18 04 A0 10 5F B7 4A 1A CA E5 02 01 00 02 01 0A 1A 0B CA 0C E5 18 00 00 00 (l:25)<0>(422117) - config antwort für channel 0 von deinem device
-> 11 04 A0 02 1A CA E5 5F B7 4A 04 BF 29 8F C1 A0 9D 00 (l:18)<0>(422258) - ACK-proc von der zentrale
-> 10 0D A0 01 1A CA E5 5F B7 4A 01 04 00 00 00 00 01 (l:17)<0>(422703) - anfrage nach list1 channel 1
<- 12 0D A0 10 5F B7 4A 1A CA E5 02 04 00 08 00 09 00 00 00 (l:19)<0>(422809) - antwort von deinem device, es gibt nur register 08 und 09, beide sind leer
-> 11 0D A0 02 1A CA E5 5F B7 4A 04 76 E0 46 08 69 54 00 (l:18)<0>(422961) - ACK-proc von der zentrale
l> 0B 1E A2 58 18 6F 30 18 60 F1 00 00 (l:12)<0>(435093) gehört zu einem anderen gerät, da l> am anfang
l> 0E 1E 82 02 18 60 F1 18 6F 30 01 01 00 00 25 (l:15)<0>(435226)
Was sagt uns jetzt das Log? Du hast am Anfang ein Problem mit der Kommunikation, das Einleiten der config wurde 3 mal gesendet und erst dann beantwortet. Störung im Funk, zu nah an der Zentrale, hier ist vieles denkbar...
Zweites Problem, die config Soft will immer noch AES, ich vermute du hast nicht für alle Channel das AES ausgeschaltet.
ZitatDas mit dem AES ist leider nicht so einfach.
Das war nur eine Idee wie man hier ggf. ansetzen könnte. Das das nicht so einfach geht, ist mir klar.
Eigentlich will ich nur verhindern dass hier überhaupt ein Schlüsseltausch vorgenommen wird.
ZitatZweites Problem, die config Soft will immer noch AES, ich vermute du hast nicht für alle Channel das AES ausgeschaltet.
Tja, und hier versucht sich die Katze in den Schwanz zu beißen.
Also, leere Config der HM-LAN-SW, Also keine weiteren Geräte sind angelernt und kein eigener Schlüssel gesetzt.
EEprom vom Arduino wurde geleert.
AES kann vom Device erst abgeschaltet werden wenn die Initiale kommunikation geklappt hat.
Also wie muss man nun vorgenen?
Vergessen:
ZitatDas ist eine perfekte Kommunikation - der ausgehende String ist ein Pairing String,
der zurückkommende ist ein ACK, also alles OK
Dann sollte anschließend doch Register usw. in Richtung FHEM übertragen werden oder?
Jedenfalls sollte nach "CMDs_processing..." doch noch was kommen?
Ausser "CMDs_done_Errors:1" Passiert hier nix weiter.
nun, dann hast du den rest der kommunikation vergessen zu posten :-)
wenn das device in fhem bekannt ist, kommt manchmal nur ein ACK auf den pairing string.
wenn noch ausstehende befehle da sind, sollten die nach einem pairing kommen. du kannst ja mal get config in fhem drücken und schauen was im log passiert.
mit AES ausschalten meine ich das hier:
wo bei mir standard steht, steht bei dir garantiert noch gesichert. drück mal auf das weisse standard, dann kommt das fenster wie in bild2, hier wechselst du von gesichert auf standard. das musst du bei allen 6 kanälen wiederholen...
Zitatwenn das device in fhem bekannt ist, kommt manchmal nur ein ACK auf den pairing string.
Das Pairing in FHEM klappt scheinbar.
Aber jede weiter Kommunikation klappt wohl nicht.
Was passiert bei dir denn nach einem getConfig?
Kannst du Register vom Device auslesen?
Irgendwo fehlt hier noch was bei mir.
Zitatmit AES ausschalten meine ich das hier:
Das ist mir schon klar.
Aber dieser Schritt kann erst nach dem erfolgreichem Pairing funktionieren.
Nachdem das Device in der SW gefunden wurde, gibt es aber noch "Konfigurationsdaten die zur Übertragung anstehen". Und diese werden auch bei erneutem Drücken der Configtaste nicht übertragen.
Daher findet keine weitere Kommunikation mehr statt.
Alle weiteren Einstellungsversuche incl. der Versuch AES am Kanal abzuschalten wird mit
"Die Übertragung der Daten zum Gerät konnte nicht ordnungsgemäß durchgeführt werden. ..." quitiert.
:-) jetzt weiss ich was du meinst, geht bei mir auch nicht - weder mit original remote oder meinem nachbau.
vermutlich hat martin was an der fhem anbindung gebastelt :-)))))
mit der config soft von hm funzt das ding wie gewohnt....
Ich habe im XML-File aes_default mal auf false gesetzt.
Damit klappt das dann auch mit der HM-LAN-SW.
Konfigurieren usw. Funktioniert also so.
Aber mit ungepatchtem XML-File nicht.
Zitatmit der config soft von hm funzt das ding wie gewohnt....
Jetzt ist die Frage was machst du anders als ich.
Oder hast du die Register für AES im EEPROM vorher deaktiviert?
Versuch doch mal das Anlernen an der HM-LAN-SW mit vorherigem Clearen des EEPROM.
Klappt das bei dir dann?
Nachtrag:
Peeren mit einem HM_LC_SW1_BA_PCB klappt so übrigens auch einwandfrei.
Incl. Burst.
Super Arbeit. Jetzt müssen wir nur noch Rausfinden warum das bei mir mit dem Original-XML nicht klappt.
Die register für AES sind per default deaktiviert. Die hm soft geht aber von AES per default aus. Meine versuche das AES im xml auszuschalten sind gescheitert. Hat die config soft ignoriert.
Ich habe jetzt mal Fhem auf den neuesten Stand gebracht, das eeprom gelöscht und wollte neu anlernen, was soll ich sagen, jetzt hab ich das gleiche problem :'(
Ich vermute, Martin hat was an den Hm modulen gedreht...
Pairing funktioniert. In der fhem.cfg wird das device auch noch angelegt, aber getconfig bleibt hängen. Das passiert aber nicht nur mit meinem device sondern auch mit dem original wm55.
In der hm config soft kann ich das device ganz normal anlernen. Reset des eeproms. Kontrolle mit e, alles 00. Dann in der config soft auf neues gerät anlernen - am device die konfig taste drücken und jede menge log einträge...
Danach dann gesichert auf standard in allen kanälen ändern und dann kann ich wie gewohnt peeren...
Wegen der fhem module habe ich martin mal angeschrieben...
Ganz vergessen zu erwähmen, ich nutze den hm usb cfg stick
ZitatMeine versuche das AES im xml auszuschalten sind gescheitert.
Das zugehörige File währ: rf_rc-4-2.xml
Dieser Eintrag muss auf false gestezt werden:
/device/channels/channel[index:1]/aes_default
Ohne false ist nix mit anlernen
Zitatam device die konfig taste drücken und jede menge log einträge...
Hm, mir verweigert es dann jede weitere Kommunikation eben mit dem hinweis dass vorher noch Daten zu übertragen währen. Was auch nachvollziehbar währ, da AES per default ja aktiv ist und da keine Kommunikation erfolgreich sein sollte.
ZitatGanz vergessen zu erwähmen, ich nutze den hm usb cfg stick
Ich hab einen HM-Lan hier. Vielleicht gibt es da auch bei diesem oder dem USB-Stick einen Bug wodurch sich der Unterschie erklären lies.
Starte mal den Hm lan und die config soft neu, dann sollten die ausstehenden aktionen weg sein.
Nein, die sind erst weg wenn sie zum Gerät übertragen worden. So ist es auch bei anderen Geräten, oder nachdem man das Gerät gelöscht hat.
Ich habe den "Taster" jetzt übrigens mal mit einem Dimmer gepeert. Die langen Tastendrucke sind scheinbar noch nicht ganz korrekt. Das schaue ich mir aber noch mal näher an.
ZitatIch habe den "Taster" jetzt übrigens mal mit einem Dimmer gepeert. Die langen Tastendrucke sind scheinbar noch nicht ganz korrekt. Das schaue ich mir aber noch mal näher an.
Da ist noch ein Bug in HM::sendPeerREMOTE
Der Eventcounter darf sich nur bei jedem kurzen Tastendruck erhöhen.
Beim langen Tastendruck wird der Eventcounter bei jeder Übertragung unverändert gesendet. Erst nach dem loslassen muss der Eventcounter eins hochgezählt werden. Ansonsten funktioniert das Toggledim nicht, und die Lampe "blinkt" beim langen Tastendruck.
Gruß
Dirk
Das sollte kein problem sein zu ändern.
Wie ist die logic des counters?
Short zaehlt immer 1 hoch.
Long zaehlt beim key release eins hoch?
ZitatShort zaehlt immer 1 hoch.
Long zaehlt beim key release eins hoch?
Ja, Short zählt immer.
Long sendet bei jeder Wiederholung den selben Counter. Beim release wird eins hochgezählt.
Ok! Ich bau das mal am 2. Weihnachtsfeiertag um.
Heute und Morgen gehört der Familie.
Euch allen hier ein frohes Weihnachtsfest!
fehler im key counter beseitigt...
zählt jetzt bei einem repeated long key press nicht mehr hoch.
Super.
Das ging ja schneller als gedacht :)
Ich teste das heute Abend und werde berichten.
Gruß
Dirk
Hi Dirk,
War ja auch nur eine Kleinigkeit. Eine Zeile Code...
Das mit dem getconfig wurmt mich viel mehr!
Viele Grüsse
Horst
Hi Horst,
So, habe nun einiges getestet und bin so erstmal begeistert. Dann kann ich mich ja mal ans "customizen" ran machen.
Dafür muss ich mich erst mal in deinen Code reinversetzen.
Ich habe inzwischen deinen Code auf dem Steckbrett ohne Arduino mit "nacktem" Atmega328p zum laufen gebracht. Das ganze ohne externen Quarz, nur mit internem Oszillator.
An zwei AA-Zellen komme ich mit eingeschaltetem Brown-Out (1,8 V) auf ca. 16 µA Standby-Verbrauch, ohne Brown-Out sind es sogar nur 0,16 µA. Sehr schön.
Werde als erstes mal die Batteriespannungsmessung einbauen, oder ist die schon drinn.
Gruß
Dirk
freut mich das ich dich begeistern konnte 8)
mit der batteriespannung bin ich noch am überlegen wie man die am besten implementieren könnte, sie soll ja möglichst universal sein und selbst keinen strom verbrauchen.
das hatte ich mal getestet um VCC direkt im AVR zu messen:
long readVcc() {
long result;
// Read 1.1V reference against AVcc
ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);
delay(2); // Wait for Vref to settle
ADCSRA |= _BV(ADSC); // Convert
while (bit_is_set(ADCSRA,ADSC));
result = ADCL;
result |= ADCH<<8;
result = 1126400L / result; // Back-calculate AVcc in mV
return result;
}
Das funktioniert soweit ganz gut, misst aber erst hinter dem Spannungsregler vom Arduino.
Das heisst, wenn wir einen Arduino mit einem Lipo betreiben wollen, hilft das nicht weiter...
Zum messen der VCC vor dem Spannungsregler hatte ich über einen Widerstandsteiler nachgedacht, der
verbindet aber VCC mit Ground, es fliessen also immer ein paar uA in die Tonne...
Bis ich das fand :-)
http://jeelabs.org/2013/05/16/measuring-the-battery-without-draining-it/
Der nimmt zwei 10 mOhm widerstände, dadurch fliesst ein sehr sehr niedriger Strom, der normalerweise vom Arduino
nicht gut zu messen wäre, packt einen kleinen Kondensator in Reihe, der puffert genügend Strom um zu messen.
Aus meiner Sicht sollten wir uns ein Modul bauen, das sich konfigurieren lässt,
1. Batteriespannung = VCC (Meßmethode 1)
2. Batteriespannung > VCC (Widerstandsnetzwerk)
Wenn Methode 2 dann noch das Spannungsteiler Verhältnis als Parameter
Ich bau mal in das HM Modul einen Parameter den wir dann befüllen können, so dass bei allen Stausmeldungen der Batterie Status mitgeschickt wird...
Was hältst du davon?
Brown-Out sollte eigentlich im Power Mode 2-4 automatisch ausgeschaltet werden. Dazu gibts in der HM::power_poll folgendes Statement:
sleep_enable(); // enable the sleep mode
MCUCR |= (1<<BODS) | (1<<BODSE); // turn off brown-out enable in software
MCUCR &= ~(1<<BODSE); // must be done right before sleep
sleep_cpu(); // goto sleep
Falls das so nicht funktioniert muss ich da noch mal ran...
Viele Grüße
Horst
Hallo Horst,
hast Du gesehen, er hat dort auch eine Schaltung mit einem Mosfet die gar keinen Strom verbraucht:
http://jeelabs.org/2013/05/17/zero-powe-battery-measurement/
;)
Für Batteriebetriebene Schaltungen, wenn es auf das letzte µA ankommt, würde ich ohnehin hinter dem Spannungsregler vom Arduino versorgen. Und diesen und die Arduino-LED Hardwareseitig abklemmen. Der Spannungswandler Verbrät nämlich auch einiges. Mit einer LiPo-Zelle als Spannungversorgung klappt das natürlich nicht.
Für die Batteriemessung kannst du die Versorgungsspannung VCC als Referenz (Aref) des ADC reinstellen. Damit kannst du die interne Bandgapreferenz messen und die resultierende Spannung ausmessen:
http://www.mikrocontroller.net/articles/Pollin_Funk-AVR-Evaluationsboard#Die_Versorgung_muss_stimmen
ZitatDas heisst, wenn wir einen Arduino mit einem Lipo betreiben wollen, hilft das nicht weiter...
Für meine seit Jahren mit einer CR2450-Zelle laufenden FS20-Taster nutze ich einen Zusätzlichen Transistor um nach jedem Tastendruck den Spannungsteiler zur Batteriemessung zu aktivieren. Da kannte ich den Trick mit der internen Bandgapreferenz noch nicht.
Das würde hier gehen. Braucht aber ein Paar zusätzlich Bauteile
ZitatBrown-Out sollte eigentlich im Power Mode 2-4 automatisch ausgeschaltet werden. Dazu gibts in der HM::power_poll folgendes Statement
Lässt sich Brownout auch über Register abschalten? ich hatte das immer mit den entsprechenden Fuse-Bits gemacht.
Zitat
hast Du gesehen, er hat dort auch eine Schaltung mit einem Mosfet die gar keinen Strom verbraucht:
Genau so hatte ich das beim FS20-Taster gemacht.
Gruß
Dirk
Ich will ja nicht nur einen Schalter mit der Lib bedienen. Bei einem batteriebetriebenen Schalter, oder auch Sensor sollten wir sicherlich die interne Methode wählen.
Aber ich denke auch an die Einsatzmöglichkeit als Actuator, da brauchen wir vermutlich eine externe Möglichkeit.
Mir gefällt einfach die Lösung mit den zwei Widerständen und dem Kondensator, sowas bekomme ich auch aufs Steckbrett. Das mit dem Mosfet ist sicherlich eleganter :-)
Bei der Lösung mit den Widerständen kommt man rechnerisch auf 0,3uA - Selbstentladung von Lipo ist 1-3% pro Jahr, bei angenommenen 2000mAh sind das 2,2uA pro Stunde.
Mit der einfachen Widerstandslösung bleiben wir also unter der Selbstentladung ....
Der Bod lässt sich beim 328 über Fuse Bits ein und ausschalten, oder aber temporär vor dem Schlafen. Ich habe in der Lib den temporären Ansatz gewählt, da ich ja zur
Laufzeit nicht weiß ob er eingeschaltet ist. Beim temporären Ausschalten ist das egal, war er aus, bewirkt der Befehl nichts.
War er an, dann wird er nur beim Schlafen ausgeschaltet und beim Aufwachen wieder aktiviert...
Viele Grüße
Horst
@Dirk
ich habe mir heute mal die neue Version von 10_CUL_HM.pm aus dem trunk geholt. Anfangs hatte ich weiterhin Probleme mit dem getConfig.
Device aus der cfg gelöscht, Fhem neu gestartet und jetzt läuft es wie Butter...
Kannst ja mal testen
Viele Grüße
Horst
ZitatDevice aus der cfg gelöscht, Fhem neu gestartet und jetzt läuft es wie Butter
Es sieht schon besser aus, Allerdings war der Start etwas "holprig".
Mit was für eine IDE arbeitest du eigentlich?
Die Arduinoe-IDE reicht zum Kompilieren und bissl zum Testen Zum richtigen Entwickeln ist diese IDE aber Sch...
Eclipse bekomme ich nicht zum Kompilieren.
Gruß
Dirk
Ich habe mir zum Start auch das dümmste Device ausgesucht. Ich habe letztens mal diesen PCB Schalter emuliert, das ging deutlich besser...
Ich nutze das Atmel Studio 6.1 mit visual micro plugin.
Das geht ganz gut und hält den Code übersichtlich. Nutzt aber zum Kompilieren die Arduino Soft und somit sollte es ziemlich kompatibel sein.
http://visualmicro.codeplex.com
Zitat von: trilu am 26 Dezember 2013, 15:34:34
Der Bod lässt sich beim 328 über Fuse Bits ein und ausschalten, oder aber temporär vor dem Schlafen.
Auch schön. Das hatte ich gar nicht gesehen.
Du hast da aber einen Fehler, daher bleibt der BOD an. Und das hate ich auch im Stromverbrauch gemessen.
Du muss den BOD so ausschalten:
MCUCR = (1<<BODS)|(1<<BODSE);
MCUCR = (1<<BODS);
Somit braucht der AVR bei mir nur noch 0,16 µA bei 3V
Ich versuche grade mal noch eine 2. Status-LED einzubauen
Ich würde bei mir nämlich gerne 2 Status-LED's (bzw. einen 2-Farbige) einsetzen.
Daraus könnten sich dann solche Statusanzeigen ergeben:
Beim Senden: Gelb (beide LED-Chips, rot und grün, sind an)
Beim ACK: Grün
Bei Fehler: Rot
Gruß
Dirk
Danke, bau ich ein.
Hast du dir mal das Atmel Studio angeschaut?
Wegen der Leds, vielleicht koennten wir daraus eine Klasse machen. Ich muss ja dann noch ein paar Trigger in das HM Modul bauen.
Viele Gruesse
Horst
ZitatHast du dir mal das Atmel Studio angeschaut?
Ja, hatte aber keine Lust mir knapp 800MB runter zu laden.
Habe es jetzt einigermaßen im Eclipse ans laufen bekommen. Muss aber auch in der Arduino-IDE Kompilieren.
Mal sehen ob ich das noch hinbekomme.
Ich mache grade schon mal ein Paar Versuche mit den LED's
Mal sehen ob ich das mit meinen rudimentären C++ Kenntnissen hinbekomme.
Zitatvielleicht koennten wir daraus eine Klasse machen
Du hast die LED-Sachen ja schon schön in einer Klasse gekapselt.
Ich erweitere die nur grade so, das man eine 2. LED angeben kann.
Gruß
Dirk
Beim Atmel Studio macht das Kompilieren dann das Visual Micro Plugin. Ich muss also nicht zwischen verschiedenen Programmen waehlen.
Du nutzt aber Linux, oder?
Mit Eclipse unter Windows bin ich damals gescheitert :'(
Ich nutze Eclipse unter Windows schon recht lange. Zuerst im Javascript- und PHP-Umfeld (inzwischen PhpStorm). Aktuell für Android und Perl (FHEM) Entwicklung.
Daher wollte ich das bei einer IDE belassen.
Ich werde mir das Atmel Studio zusammen mit dem Visual Micro aber auch noch mal ansehen.
Ich wollte aber erstmal schnell was am laufen haben.
Hi Horst,
Ich habe mich mal an das LED-Handling gemacht.
Man kann nun 2 LED's bzw eine Dual-Color-Led als Status-LED anschliessen.
Pin4 ist bei mir grün
Pin5 ist bei mir rot
Nach Anlegen der Spannungsversorung blinkt es zunächst 3x rot.
Nach dem Drücken der Config-Taste blinkt es rot, währen der Datenübertragung blinkt die grüne LED. Dadurch kann man nun auch sehen wenn Daten z.B. beim Peering ausgetauscht werden.
Nach dem Drücken einer Taste blinkt bei jedem Sendeversuch die grüne und rote LED Eine Duocolor-LED zeigt dann gelb an.
Nach einem Ack vom Aktor blinkt es einmal kurz grün. Man kann nun also sehen ob der Befehl erfolgreich am Aktor ankam.
Falls es kein ACK vom Aktor gibt, dann blinkt es nach dem Letzten Sendeversuch rot.
Update:
Eine einfache Batteriemessung ist jetzt auch mit drinn.
Hier wird AVCC als Reference genommen und gegen die interne Bandgap-Reference gemessen.
Der Arduino-Mini-Pro hat die entsprechende Aussenbeschaltung schon (100 nF an AREF gegen Masse und VCC an AVCC)
Da ich meine Testschaltung mit 2 AA-Zelen betreibe, habe ich die Spannung für Batterie leer im Sketch auf 2,35 V eingestellt.
Die Batteriespannung wird vor jedem Tastendruck gemessen und wenn zu klein wird der batLow-Event mitgeschickt.
Gruß
Dirk
Abend,
wir haben die Library gestern und heute auf dem 30C3 auf den Homemativ HM-LC-Sw1PBU-FM geportet. Dazu waren allerdings ein paar Änderungen an der Lib notwendig. Ich habe das ganze mal auf Github eingecheckt:
https://github.com/jabdoa2/Asksin-HM-LC-Sw1PBU-FM
Grobe Changelog:
- add quirks for Atmega 644
- change ports for M-LC-Sw1PBU-FM
- change interrupt handlers
Leider ist das ganze nicht mehr zur Ursprungslib kompatibel. Ggf sollte man den Button und Interruptkram von der Homematic Lib trennen. Für die SPI Pins könnte man Ifdefs machen.
Gruß,
Jan
@dirk - Danke, werde ich mir gleich mal anschauen. Vielleicht sollten wir auch einen github eröffnen. Sonst wird es sehr schnell unübersichtlich mit den Änderungen. Ich habe nur keine Ahnung wie github, etc funktioniert. Cool wäre eine Lösung die mir die Änderungen gleich ins Atmel Studio zieht...
@jan - freut mich einen neuen Mitstreiter gefunden zu haben :-)
Ich hatte mir auch schon überlegt die Peripherie von der Lib zu trennen. Habe mich aber dagegen entschieden da das ganze ein Framework werden soll. Ich stelle mir das so vor:
Man definiert in einem externen Script die Funktionalität die man haben möchte, das Script generiert dann die Register.h und ein xml File für die HM config Software.
Register.h kommt zum Sketch und die verschiedenen Channel sind automatisch konfiguriert.
Dank Martin gibts das Script schon, also den Register.h Teil. Das xml generieren fehlt noch.
Das ganze kann also HW unabhängig sein, aber die Peripherie Module müssen im Paket bleiben. Gerne aber ifdef hardwareunabhängig...
Ich werde das Script gleich mal posten...
Weiter vorne hatte ich mal einen pcb sketch gepostet, da wäre auch das Schaltmodul für deinen Unterputzschalter drin :-)
Viele Grüsse
Horst
ZitatVielleicht sollten wir auch einen github eröffnen
Unbedingt. Das macht die Zusammenarbeit viel einfacher.
Kannst ja mal ein Repo bei Github anlegen. Alternativ kann ich das gerne auch bei mir machen.
ZitatIch habe nur keine Ahnung wie github, etc funktioniert.
Das gibt es ganz gute Tuturials.
Du hast lokal ein Repository, darin arbeitest du, committest Änderungen usw.
Das ganze sollte man dann von Zeit zu Zeit in das Remote-Repo puschen. Damit z.B. andere hier weiter arbeiten können.
ZitatCool wäre eine Lösung die mir die Änderungen gleich ins Atmel Studio zieht...
https://gallery.atmel.com/Products/Details/2398da3e-aba5-45ed-b3a0-d0714a6dc661
Es gibt auch Plugins für Eclipse. Auch Tools für Windows z.B. Tortoise GIT https://code.google.com/p/tortoisegit/
Zitat... Habe mich aber dagegen entschieden da das ganze ein Framework werden soll.
Das eine muss das andere ja nicht ausschließen
Ich bin auch immer ein Freund gekapselter Modulbausteine.
Gruß
Dirk
Moin,
um das ganze zu vervollständigen habe ich auch mein Arduino Target auf github hochgeladen. Basiert auf Sanguino und ist für den Atmel 644 auf dem HM-LC-Sw1PBU-FM angepasst: https://github.com/jabdoa2/jabduino
Ich sehe das mit der Lib wir Dirk. Mein Vorschlag wäre pro Klasse ein File zu machen (bzw 2 mit Header). Dann hätten wir:
- HM: mit aller Funktionalität für Homematic.
- CC: mit aller Funktionalität für CC1100/CC1101
- LD: mit LED Kram
- BK: mit dem Button Kram
- InputParser: serial kram
Dann könnten wir die Namen noch etwas lesbarer machen:
- HM -> Homematic
- LD -> LED
- BK -> ButtonPress
Konkret habe ich aktuell folgende Probleme:
- Die Logik in BK funktioniert so nicht für meinen Controller. Da ist viel Magie drin die ich nicht durchschaue und die sich bei mir mit den Ports und Indexes verrechnet. Ggf ist das für meinen Anwendungsfall auch etwas zu aufwändig. Interrupthandling funktioniert auch nicht auf jedem Controller gleich und ich musste es anpassen. Das ist also relativ spezifisch pro Gerät.
- Das schalten eines HM-LC-Sw1-Pl funktioniert nicht wirklich zuverlässig. Manchmal geht es und dann auch wieder nicht. Im Sniffer sieht es aber ganz gut aus. Hast du eine Idee woran das liegen kann? Kein Burst? Timing?
Gruß,
Jan
Hi Jan,
ich schaue mir das heute mal mit dem Github an und wenn es für mich eine handhabbare Lösung gibt mehrere Files über mehrere Rechner aktuell zu halten, dann können wir die Lib gerne über mehrere Files aufdröseln.
Eigentlich sollte das Interrupthandling doch über Arduino transparent sein? Klar das der 644 mehr Interrupts hat, aber auch das müsste über Arduino.h geregelt sein:
In der BK::config suche ich den Interrupt und die PCMask zum Arduino Pin und schreibe beides ins Interrupt Register
danach den Pin und Port zum Arduino Pin und schreibe ihn in ein Array, damit ich ihn später, wenn der entsprechende Interrupt auslöst, griffbereit habe.
Danach gibts dann das Interrupt Handling in der pcInt Funktion.
Hier suche ich dann nach dem bit das den Interrupt ausgelöst hat und schreibe ihn in das Struct zur entsprechenden BK Instanz.
Per Polling schau ich mir regelmäßig das Struct an und prüfe ob es etwas zum abarbeiten gibt. Vielleicht solltest du einfach mal die entsprechenden PCINTX_vect für den 644 mit einbauen.
Der Rest, so lange Arduino compatibel sollte von der BK Class abgedeckt sein...
So aus der Ferne ist es schwer zu beurteilen was bei dir nicht läuft. Poste doch mal ein paar Logs und ich schau sie mir an.
Aber wie gesagt, zu aller erst, würde ich versuchen die 644'er int vectoren zu definieren und zu testen...
Viele Grüße
Horst
Hi,
die Interruptvektoren habe ich ja definiert. Das klappt so weit auch. Habe zwei Probleme beim Schalten identifiziert:
- Nach einem Neustart hält er die Nachricht für eine Wiederholung, wenn der Taster nur einmal gedrückt wurde. Ich vermute mal, dass es die gleiche Sequencenummer ist.
- Ansonsten geht es relativ zuverlässig. Selten klappt es nicht. Ich kann das aber noch nicht zuverlässig nachstellen
Abseits davon scheint beim Empfang irgendwas nicht zu klappen. Z.b. bei einem getConfig in FHEM bekomme ich folgenden Output in der Seriellen Konsole:
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157168)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157770)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2158372)
Er scheint aber keine Antwort zu senden. Oder ist das noch nicht implementiert?
Btw: Ich habe noch zwei Mitstreiter mit der gleichen Hardware die sicher in den nächsten Tagen auch noch weiter dran schrauben werden.
Gruß,
Jan
Hi Jan,
klar das die lib damit nicht viel anfangen kann - hier wird eine burst message vom gerät 12 1A B1
an uns gesendet.
"12" => { txt => "HAVE_DATA"},
Die Message habe ich noch nicht implementiert, da ich sie noch nie gesehen habe. Hast du ein original device und kannst mir die Antwort darauf sniffen?
Ich bau das dann gerne ein...
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157168)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2157770)
-> 09 49 B1 12 1A B1 50 5F B7 4A (l:10)(2158372)
Hi,
das ist FHEM wenn ich getConfig aufrufe. Vorher hab ich burstAccess auf Auto gestellt. Ansonsten hat FHEM nie irgendwas an das Gerät geschickt. Ich bekomme alle 30s ein t:xxx auf dem Serial. Sollte er da ein Wakeup schicken? Afaik müsste er ja eins von beiden tun: Entweder periodisches Wakeup oder auf Burst reagieren.
Nachtrag: power mode habe ich 0 gesetzt, weil es noch Probleme gab beim Sleep mit der CPU. Hat ja auch keine Batterie.
Beim Pairing sieht das bei mir so aus:
<- 1A 01 A2 00 5F B7 4A 1A B1 50 11 00 A9 50 53 30 30 30 30 30 30 30 31 40 06 00 00 (l:27)(2411407)
-> 0A 01 80 02 1A B1 50 5F B7 4A 00 (l:11)(2411546)
-> 10 55 A0 01 1A B1 50 5F B7 4A 00 05 00 00 00 00 00 (l:17)(2411823)
-> 10 55 A0 01 1A B1 50 5F B7 4A 00 05 00 00 00 00 00 (l:17)(2412023)
<- 0A 55 80 02 5F B7 4A 1A B1 50 00 (l:11)(2412105)
-> 13 56 A0 01 1A B1 50 5F B7 4A 00 08 02 01 0A 1A 0B B1 0C 50 (l:20)(2412408)
<- 0A 56 80 02 5F B7 4A 1A B1 50 00 (l:11)(2412423)
-> 0B 57 A0 01 1A B1 50 5F B7 4A 00 06 (l:12)(2412720)
config changed
<- 0A 57 80 02 5F B7 4A 1A B1 50 00 (l:11)(2412744)
-> 10 58 A0 01 1A B1 50 5F B7 4A 00 04 00 00 00 00 00 (l:17)(2413041)
<- 18 58 A0 10 5F B7 4A 1A B1 50 02 01 00 02 01 0A 1A 0B B1 0C 50 18 00 00 00 (l:25)(2413056)
-> 11 58 A0 02 1A B1 50 5F B7 4A 04 6E F8 5E 10 71 4C 02 (l:18)(2413197)
Wenn ich danach ein getConfig in FHEM anstoße passiert genau nichts. Es sei denn ich aktiviere BurstAccess. Was geht da schief?
Gruß,
Jan
schau dir mal die power modes an, derzeit sind 4 stück drin
power mode 0 - default, keine power savings
power mode 2 - device wacht alle 250ms auf und lauscht ob es ein burst signal gibt, wenn nicht schläft es weiter
power mode 3 - gerät wacht alle 8 sekunden auf, dann könnte es einen sensor auslesen um dann wieder weiter zu schlafen, RX bleibt aber aus
power mode 4 - gerät schläft bis es von einem interrupt geweckt wird, RX ist aus
in power mode 3 und 4 muss man eine taste drücken um etwas zu senden, danach geht das funkmodul in RX um die bestätigung zu empfangen.
hier hilft also kein burst signal. burst hilft nur bei power mode 2.
power mode 3 und 4 soll für schalter und sensoren sein, da wird getconfig gelesen wenn das gerät einen pairing string gesendet hat, also die config taste gedrückt wurde...
das ganze ist in fhem über die model ID hinterlegt.
das t:xxx war für mich zum testen. der millis() timer ist ja normalerweise im tiefschlaf auch aus, damit würde ich aber die referenz für viele zeitgesteuerte funktionen verlieren,
z.b. das wiederholte senden einer nachricht, etc... deshalb fülle ich den millis() timer manuell durch die watch dog referenz :-)
gerade mal nachgeschaut, der 644 hat eigentlich nur einen pcint vektor mehr...
versuch mal so:
ISR(PCINT3_vect) {
pcInt(3);
}
und in void pcInt(uint8_t iPort)
if (iPort == 3) pcMskByte = PCMSK3;
setzen
das müsste eigentlich reichen :-)
Hi,
das habe ich in meinem Code ja schon drin (siehe github). Damit klappt das auch. Allerdings waren in der Klasse BK Klasse offsets drin die es bei mir gebrochen haben. Hab ich im github Code geändert. Bsp hier:
uint8_t pinPort = digitalPinToPort(tPin) - 2;
Warum ist das - 2? Für mich würde hier nur -1 Sinn machen und damit funktioniert es bei mir auch (damit der Index bei 0 statt bei 1 anfängt).
Die Powermodes habe ich auch so verstanden. D.h. aktuell muss ich immer den Config Taster drücken, wenn er von FHEM irgendwas empfangen soll? Kann ich das irgendwie einfach ändern? Oder muss ich die modelId ändern bzw in FHEM den Code?
Ich versuche gerade noch einen Aktorchannel einzufügen damit ich den Aktor im HM-LC-Sw1PBU-FM ansteuern kann. Ggf werde ich dazu mal einen anderen Aktor sniffen (für die FHEM Commands).
-2 deshalb
digitalPinToPort(A0) liefert bei einem 328 den Port PC, damit 3
Arduino Pin 8 liefert den Port PB, also 2
Arduino Pin 4 liefert den Port PD, aslo 4
Damit ist der kleinste Port beim 328 der PB, PB -2 fängt dann bei 0 an :-)
Hat der 644 einen PA?
Den Aktorchannel gibt es schon, das ist die RL class. Die wird dir nur mit dem Setup in der register.h nichts helfen.
Ich hatte mal vor ein paar Tagen einen Test sketch gepostet zum testen der Relay Class.
Hi,
der 644 hat einen PA. Ich habe meinen Code jetzt auf deinen neuen rebased. Jetzt würde ich gerne 3 Kanäle haben:
1 + 2: Remote
3: Aktor
Kann ich das Perlscript irgendwie bekommen um die Register.h zu erstellen? So werde ich leider nicht daraus schlau.
Gruß,
Jan
Hi trilu,
ich habe deinen Code gemerged. Das Repository habe ich renamed da Arduino Namingconventions hat. Man findet es jetzt unter: https://github.com/jabdoa2/Asksin_HM_LC_Sw1PBU_FM (mit _ statt -).
Schalten geht jetzt zuverlässig mit dem HM-LC-Sw1-Pl. Der Aktor ist vorbereitet, aber es gibt noch Bugs. Sobald ich den folgenden Code drin habe:
// init relay stuff
rl[0].config(3,0,12,0,0,0); // configure the relay to monostable, on pin 12
//rl[0].setCallBack(&relayState,&hm,1,1);
Rebootet das Device wenn man einen meiner Buttons drückt nach ca 1s. Sehr strange. Versuche ich zu debuggen gerade.
Gruß,
Jan
Sag mal, schläfst du irgend wann mal?
Ich muss noch ein paar Feinheiten im Script korrigieren. Ich denke ich bin bis Mittag soweit...
Die Buttonauswertung funktioniert noch nicht 100%ig.
Wenn man z.B. die Longpesszeit auf 1s einstellt, funktioniert Longpress nicht mehr.
Das würde ich mir heute aber mal ansehen.
Ich würde gerne auch einbauen dass man auch durch 1-fach-, 2-fach-, 3-fach-Tastendruck je einen unterschiedlichen Kanal auslösen kann.
Dafür würde ich BK::config so erweitern, dass an den Callback die Anzahl der "Doppelklickts" mit übergeben werden.
Dann kann man das weitere in buttonState machen. Oder hast du da einen anderen Vorschlag?
Ich habe Eclipse übrigens auch zum kompilieren bekommen.
Somit macht das ganze so gleich viel mehr spass.
HM6TastenSwitch.ino braucht dafür noch ein eigenes Header-File (HM6TastenSwitch.h) in dem auch dir Funktionsdeklarationen drinn sind.
Gruß
Dirk
Moin,
es ist Congress da schläft man immer zu komischen Zeiten. Habe den Bug gefunden. Hatte ein Memory Allocation Problem bei mir (hatte zu wenig Instanzen der BK Class instanziert). Zusätzlich habe ich zwei andere Dinge gefixt: in der AskSin.h sind kein static Variables mehr. Die werden sonst zwei mal allokiert. Außerdem habe ich alle ";" am Ende von defines entfernt, weil das Fehler verursacht.
Gruß,
Jan
Ich habe jetzt mal einen GIT für die Library erstellt, derzeit ist erst mal nur das versprochene Paket destillRegs hochgeladen.
destillRegs beruht auf der Idee von martin876 hier im Forum, ist ein Perl Script um einen großen Teil der Register.h automatisch zu erstellen.
Das Paket besteht im Wesentlichen aus 3 Teilen:
destillRegs, das Perl Script
devDefinition.pm, um die eigentliche Funktionalität des Devices zu konfigurieren
RegConfig.pm, enthält alle derzeit bekannten Variablen der HM Devices
Alle 3 Files müssen in einem Directory sein, Aufruf ist dann einfach "perl destillRegs.pl"
Was dann auf der Konsole raus kommt, muss in die Register.h kopiert werden.
Für den Anfang ist es am einfachsten sich an einem bestehenden Device zu orientieren, nehmen wir mal einen HM_HM_LC_SW1_BA_PCB
Um so ein Gerät zu emulieren, geht ihr in Fhem auf das Device und lasst euch die Register per "get CUL_HM_HM_LC_SW1_BA_PCB_1FB74A regList" anzeigen.
Das sieht dann so aus:
list: register | range | peer | description
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: ledMode | literal | | LED mode options:on,off
0: lowBatLimitBA | 5 to 15V | | low batterie limit, step .1V
0: pairCentral | 0 to 16777215 | | pairing to central
1: sign | literal | | signature (AES) options:on,off
3: lgActionType | literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
3: lgCtDlyOff | literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtDlyOn | literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtOff | literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtOn | literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtValHi | 0 to 255 | required | Condition value high for CT table
3: lgCtValLo | 0 to 255 | required | Condition value low for CT table
3: lgMultiExec | literal | required | multiple execution per repeat of long trigger options:on,off
3: lgOffDly | 0 to 111600s | required | off delay
3: lgOffTime | 0 to 111600s | required | off time, 111600 = infinite
3: lgOffTimeMode | literal | required | off time mode options:minimal,absolut
3: lgOnDly | 0 to 111600s | required | on delay
3: lgOnTime | 0 to 111600s | required | on time, 111600 = infinite
3: lgOnTimeMode | literal | required | on time mode options:minimal,absolut
3: lgSwJtDlyOff | literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
3: lgSwJtDlyOn | literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
3: lgSwJtOff | literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
3: lgSwJtOn | literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
3: shActionType | literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
3: shCtDlyOff | literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtDlyOn | literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtOff | literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtOn | literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtValHi | 0 to 255 | required | Condition value high for CT table
3: shCtValLo | 0 to 255 | required | Condition value low for CT table
3: shOffDly | 0 to 111600s | required | off delay
3: shOffTime | 0 to 111600s | required | off time, 111600 = infinite
3: shOffTimeMode | literal | required | off time mode options:minimal,absolut
3: shOnDly | 0 to 111600s | required | on delay
3: shOnTime | 0 to 111600s | required | on time, 111600 = infinite
3: shOnTimeMode | literal | required | on time mode options:minimal,absolut
3: shSwJtDlyOff | literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
3: shSwJtDlyOn | literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
3: shSwJtOff | literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
3: shSwJtOn | literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
Das ist jetzt der Input für das File "devDefinition.pm". Übersetzt sieht das dann so aus:
#----------------define reglist types-----------------
package usrRegs;
my %listTypes = (
regDev =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
},
regChan =>{ sign =>1,
lgActionType =>1,
lgCtDlyOff =>1,
lgCtDlyOn =>1,
lgCtOff =>1,
lgCtOn =>1,
lgCtValHi =>1,
lgCtValLo =>1,
lgMultiExec =>1,
lgOffDly =>1,
lgOffTime =>1,
lgOffTimeMode =>1,
lgOnDly =>1,
lgOnTime =>1,
lgOnTimeMode =>1,
lgSwJtDlyOff =>1,
lgSwJtDlyOn =>1,
lgSwJtOff =>1,
lgSwJtOn =>1,
shActionType =>1,
shCtDlyOff =>1,
shCtDlyOn =>1,
shCtOff =>1,
shCtOn =>1,
shCtValHi =>1,
shCtValLo =>1,
shOffDly =>1,
shOffTime =>1,
shOffTimeMode =>1,
shOnDly =>1,
shOnTime =>1,
shOnTimeMode =>1,
shSwJtDlyOff =>1,
shSwJtDlyOn =>1,
shSwJtOff =>1,
shSwJtOn =>1,
},
);
# -----------assemble device -----------------
Das neue Gerät hat damit zwei Kanäle - Channel 0, als System Kanal und Channel 1, als Schalt Kanal.
Wenn man das ganze jetzt per Script laufen lässt, also "perl destillRegs.pl" bekommt man sowas:
//- -----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ----------------------------------------------------------------------------------------------
struct s_chDefType{
unsigned char type;
unsigned short phyAddr;
unsigned short sliceIdx;
};
struct {
unsigned char nbrChannels;
s_chDefType chDefType[2];
} const devDef = {
2 // number of channels
,{
{1,0,0} // chn:0 type:regDev
,{0,6,4} // chn:1 type:regChan
}
};
struct s_sliceStrTpl {
unsigned char regAddr;
unsigned char nbrBytes;
unsigned short phyAddr;
};
// regAddr,nbrBytes,phyAddr
const s_sliceStrTpl sliceStr[] = {
{0x02, 0x01, 0x0000}, // chn:0 lst:0
{0x05, 0x01, 0x0001},
{0x0a, 0x03, 0x0002},
{0x12, 0x01, 0x0005},
{0x08, 0x01, 0x0006}, // chn:1 lst:1
{0x02, 0x0b, 0x0007}, // chn:1 lst:3
{0x82, 0x0b, 0x0012},
{0x02, 0x0b, 0x001d},
{0x82, 0x0b, 0x0028},
{0x02, 0x0b, 0x0033},
{0x82, 0x0b, 0x003e},
{0x02, 0x0b, 0x0049},
{0x82, 0x0b, 0x0054},
{0x02, 0x0b, 0x005f},
{0x82, 0x0b, 0x006a},
{0x02, 0x0b, 0x0075},
{0x82, 0x0b, 0x0080},
};
struct s_listTpl {
unsigned char ListNo;
unsigned char nbrOfSlice;
unsigned char nbrPeers;
};
struct {
unsigned char nbrLists; // number of lists for this channel
struct s_listTpl type[2]; // fill data with lists
} const listTypeDef[2] = {
{ 2 // type regChan
,{
{1,1,1}
,{3,2,6}
}
}
,{ 1 // type regDev
,{
{0,4,1}
,{0,0,0}
}
}
};
//- -----------------------------------------------------------------------------------------------------------------------
// - peer db config -------------------------------------------------------------------------------------------------------
#define maxChannel 1
#define maxPeer 6
static uint32_t peerdb[maxChannel][maxPeer];
const uint8_t peermax[] = {6};
//- -----------------------------------------------------------------------------------------------------------------------
// - Channel device config ------------------------------------------------------------------------------------------------
struct s_regDev {
uint8_t :7;
uint8_t intKeyVisib :1; // reg:0x02, sReg:2.7
uint8_t :6;
uint8_t ledMode :2; // reg:0x05, sReg:5.6
uint8_t pairCentral[3]; // reg:0x0A, sReg:10
uint8_t lowBatLimitBA; // reg:0x12, sReg:18
};
struct s_peer_regChan { // chn:1, lst:3
uint8_t shCtDlyOn :4; // reg:0x02, sReg:2
uint8_t shCtDlyOff :4; // reg:0x02, sReg:2.4
uint8_t shCtOn :4; // reg:0x03, sReg:3
uint8_t shCtOff :4; // reg:0x03, sReg:3.4
uint8_t shCtValLo; // reg:0x04, sReg:4
uint8_t shCtValHi; // reg:0x05, sReg:5
uint8_t shOnDly; // reg:0x06, sReg:6
uint8_t shOnTime; // reg:0x07, sReg:7
uint8_t shOffDly; // reg:0x08, sReg:8
uint8_t shOffTime; // reg:0x09, sReg:9
uint8_t shActionType :2; // reg:0x0A, sReg:10
uint8_t :4;
uint8_t shOffTimeMode :1; // reg:0x0A, sReg:10.6
uint8_t shOnTimeMode :1; // reg:0x0A, sReg:10.7
uint8_t shSwJtOn :4; // reg:0x0B, sReg:11
uint8_t shSwJtOff :4; // reg:0x0B, sReg:11.4
uint8_t shSwJtDlyOn :4; // reg:0x0C, sReg:12
uint8_t shSwJtDlyOff :4; // reg:0x0C, sReg:12.4
uint8_t lgCtDlyOn :4; // reg:0x82, sReg:130
uint8_t lgCtDlyOff :4; // reg:0x82, sReg:130.4
uint8_t lgCtOn :4; // reg:0x83, sReg:131
uint8_t lgCtOff :4; // reg:0x83, sReg:131.4
uint8_t lgCtValLo; // reg:0x84, sReg:132
uint8_t lgCtValHi; // reg:0x85, sReg:133
uint8_t lgOnDly; // reg:0x86, sReg:134
uint8_t lgOnTime; // reg:0x87, sReg:135
uint8_t lgOffDly; // reg:0x88, sReg:136
uint8_t lgOffTime; // reg:0x89, sReg:137
uint8_t lgActionType :2; // reg:0x8A, sReg:138
uint8_t :3;
uint8_t lgMultiExec :1; // reg:0x8A, sReg:138.5
uint8_t lgOffTimeMode :1; // reg:0x8A, sReg:138.6
uint8_t lgOnTimeMode :1; // reg:0x8A, sReg:138.7
uint8_t lgSwJtOn :4; // reg:0x8B, sReg:139
uint8_t lgSwJtOff :4; // reg:0x8B, sReg:139.4
uint8_t lgSwJtDlyOn :4; // reg:0x8C, sReg:140
uint8_t lgSwJtDlyOff :4; // reg:0x8C, sReg:140.4
};
struct s_dev_regChan {
uint8_t sign :1; // reg:0x08, sReg:8
};
struct s_regChan {
s_dev_regChan list1;
s_peer_regChan peer[6];
};
struct s_regs {
s_regDev ch_0;
s_regChan ch_1;
};
struct s_EEPROM {
unsigned short magNbr;
uint32_t peerdb[maxChannel][maxPeer];
s_regs regs;
};
//- -----------------------------------------------------------------------------------------------------------------------
//- struct to provide register settings to user sketch --------------------------------------------------------------------
struct s_cpy_regChan {
s_dev_regChan l1;
s_peer_regChan l3;
};
struct s_regCpy {
s_regDev ch0;
s_cpy_regChan ch1;
} static regMC;
static uint16_t regMcPtr[] = {
(uint16_t)®MC.ch0,
(uint16_t)®MC.ch1.l1,
(uint16_t)®MC.ch1.l3,
};
//- -----------------------------------------------------------------------------------------------------------------------
//- Device definition -----------------------------------------------------------------------------------------------------
// Channels: 2
// highest List: 3
// possible peers:6
//- Memory usage
// Slices:17
// EEPROM size:189 fits internal
// const size: 92
Was jetzt für eine funktionierende Register.h fehlt, ist der Header, also das hier:
//- settings of HM device for HM class -------------------------------------------------------------------------------------
const uint8_t devParam[] PROGMEM = {
/* Firmware version 1 byte */ 0x15, // don't know for what it is good for
/* Model ID 2 byte */ 0x00, 0x6C, // model ID, describes HM hardware. we should use high values due to HM starts from 0
/* Serial ID 10 byte */ 'P','S','0','0','0','0','0','0','0','2', // serial ID, needed for pairing
/* Sub Type ID 1 byte */ 0x10, // not needed for FHEM, it's something like a group ID
/* Device Info 3 byte */ 0x41, 0x01, 0x00 // describes device, not completely clear yet. includes amount of channels
};
static uint8_t HMID[3] = { 0x5F, 0xB7, 0x4B }; // very important, must be unique. identifier for the device in the network
static uint8_t maxRetries = 3; // how often a string should be send out until we get an answer
static uint16_t timeOut = 700; // time out for ACK handling
"Model ID" muss korrekt gefüllt sein, da sonst FHEM nicht weiss, was das für ein Gerät ist und somit autoconfig nicht funktioniert. Eine Übersicht der bekannten Geräte findet ihr in der "HMConfig.pm"
Unser Gerät hat dort eine Zeile wie folgt:
"006C" => {name=>"HM-LC-SW1-BA-PCB" ,st=>'switch' ,cyc=>'' ,rxt=>'b' ,lst=>'3' ,chn=>"",},
Hier findet sich auch die Model ID (006C) wieder. Das ganze ist ein "switch", das rxt=b heisst, dass das Gerät burst braucht und es hat eine List3.
"Serial ID" ist eine beliebige 10 stellige Seriennummer.
"Sub Type ID", keine Ahnung, spielt für FHEM keine Rolle, muss aber für die HM Config Software richtig gesetzt sein, sonst wird das Device dort nicht erkannt.
"Device Info", hier habe ich auch wenig Infos. Das zweite Byte gibt die Anzahl der Channel an. Muss aber auch für die HM Config Software richtig gesetzt sein.
Am einfachsten bekommt man die Infos aus dem Pairing String eines original Devices.
"HMID, maxRetries und timeOut" sollten selbsterklärend sein...
Ganz unten gibt es noch den Teil für First load. Das ist eigentlich nur zum testen, da ich nicht bei jeder Änderung Lust hatte, das Device neu zu konfigurieren.
Hier passiert also nichts anderes als das setzen von diversen Config Variablen. Geschrieben werden die Werte nur wenn
#define firstLoad; auskommentiert ist.
Das sind Parameter die ihr nicht verändern dürft.
static s_regs reg;
*regPtr = (uint16_t)®
*peerPtr = (uint16_t)&peerdb;
Diese Parameter gehören zum ch_0, also der Device Ebene und werden wie folgt gesetzt:
reg.ch_0.intKeyVisib = 0;
reg.ch_0.pairCentral[0] = 0x63;
reg.ch_0.pairCentral[1] = 0x19;
reg.ch_0.pairCentral[2] = 0x63;
Genauso kann man auch peers per Hand setzen. Die Byte Reihenfolge ist aber umgedreht, da hier eine Konversation von Byte Array nach Long statt findet.
Der erste Klammerwert ist der Kanal, der zewite die Reihenfolge innerhalb des Kanals...
peerdb[0][0] = 0x01086622;
peerdb[1][0] = 0x02086622;
So, das war es jetzt mal fürs erste...
Ach ja, der Github ist zu finden unter: https://github.com/trilu2000/AskSin
@Dirk - Entschuldige, ganz übersehen...
ZitatDie Buttonauswertung funktioniert noch nicht 100%ig.
Wenn man z.B. die Longpesszeit auf 1s einstellt, funktioniert Longpress nicht mehr.
Das würde ich mir heute aber mal ansehen.
Ich würde gerne auch einbauen dass man auch durch 1-fach-, 2-fach-, 3-fach-Tastendruck je einen unterschiedlichen Kanal auslösen kann.
Dafür würde ich BK::config so erweitern, dass an den Callback die Anzahl der "Doppelklickts" mit übergeben werden.
Dann kann man das weitere in buttonState machen. Oder hast du da einen anderen Vorschlag?
Ich bin so ganz hin und her gerissen, einerseits gefällt mir die Idee sehr gut, auf der anderen Seite gibt es ja von HM so eine Tastensperre. Also man muss 2 mal kurz drücken
um einen short key press zu bekommen.
Ich wollte die config der BK Class schon mal aufsplitten, bin nur noch nicht dazu gekommen. Sie sollte ähnlich der Relay Class werden.
Einmal ein config für die Funktionalität
und ein setCallBack für die Funktions Pointer
Wenn du ein Flag bei der config mit einbaust, ala multiPress und die Rückgabewerte definierst, sollte es kompatibel bleiben...
Mal eine Frage an alle Arduino Wissenden
Derzeit besteht ja das Framework aus drei Teilen. Einmal der Mainsketch, dann die Register.h und dann die Lib
Wenn ich jetzt die Lib in das library Verzeichnis von Arduino packen will und die Gerätschaften als Example, dann soll ja die Register.h mit in den Example Ordner.
Blöderweise referenziert aber die AskSin.h auch auf die Register.h und findet sie dann nicht mehr, da sie ja im Example Ordner liegt.
Wisst ihr wie man das umgehen kann?
Viele Grüße
Horst
Moin,
so ich habe die Funktionalität vom HM-LC-Sw1PBU-FM jetzt in einer ersten Version fertig bekommen. Das Perlscript hilft mir dabei erstmal nicht ganz so viel, da es den Aktor so ja nicht gibt. Ich habe jetzt erstmal ein neues Gerät erfunden in FHEM. Ich habe es remoteAndSwitch genannt. Ist noch nicht perfekt (alle Funktionen auf allen 3 Channels), aber erstmal funktioniert damit alles. Code ist im git. Den FHEM Patch schicke ich die Tage auch noch wenn er noch etwas gereift ist.
Gruß,
Jan
Zitatauf der anderen Seite gibt es ja von HM so eine Tastensperre. Also man muss 2 mal kurz drücken
um einen short key press zu bekommen.
Ja, die nutze ich auch an meinen Schlüssel-FB's für die Keymatic.
Das ganze ließe sich auch entsprechend in Register ablegen und konfigurierbar machen wie sich der "Doppelklick" verhalten soll.
Aktuell will ich das für meine Taster verwenden (die derzeitige FS20-Version hat nur eine Taste aber 3 Kanäle). Und da ich hier derzeit dein HM-PB-6-WM55 Beispiel benutze, würde ich die "Doppelklickzeit" für den ersten Kanal "mißbrauchen".
Daher soll das nur optional in die BK-Klasse rein.
ZitatIch habe jetzt mal einen GIT für die Library erstellt
Cool, da können wir ja langsam anfangen den Code zusammen zu bringen?
Konntest du dir den LED-Teil schon mal ansehen?
Hast du übrigens noch ein Paar CC1101-Module übrig? Für die Taster die ich grade baue reichen meine hier nicht.
Ansonsten würde ich noch mal eine Bestellung lostreten
Gruß
Dirk
Noch was,
Beim langen Tastendruck werden normalerweise alle 250ms entsprechende Events an die Devices geschickt.
Aktuell sendest du die Dimm-Befehle auch abhängig der Longpress-Zeit. Das würde ich mir dann auch mit ansehen.
Soll ich die BK und LED-Klasse gleich auslagern wenn ich da einmal drann bin?
Gruß
Dirk
Aktuell habe ich noch das Problem, dass wenn ich den Aktor per FHEM steuere (set on/off) dann bleibt FHEM auf set_on oder set_off. Dabei sieht das Funk fast genau so aus wie bei einem original Aktor:
AskSin:
0E 39 B0 11 1A B1 50 5F B7 4A 02 03 C8 00 00 (l:15)(6655901)
0E 39 80 02 5F B7 4A 1A B1 50 01 03 C8 00 00 (l:15)(6655924)
manchmal auch so:
0E 3B B0 11 1A B1 50 5F B7 4A 02 03 00 00 00 (l:15)(6798434)
0E 3B 80 02 5F B7 4A 1A B1 50 01 03 00 00 00 (l:15)(6798456)
0E 09 A4 10 5F B7 4A 1A B1 50 06 03 00 00 00 (l:15)(6799736)
0A 09 80 02 1A B1 50 5F B7 4A 00 (l:11)(6799878
beim original Aktor sieht es so aus:
0E 37 A0 11 1A B1 50 21 D6 3B 02 01 C8 00 00 (l:15)(6596712)
0E 37 80 02 21 D6 3B 1A B1 50 01 01 C8 00 18 (l:15)(6596837)
oder:
0E 3D A0 11 1A B1 50 21 D6 3B 02 01 00 00 00 (l:15)(7005079)
0E 3D 80 02 21 D6 3B 1A B1 50 01 01 00 00 14 (l:15)(7005204)
Irgendwelche Ideen was da noch nicht klappt?
Gruß,
Jan
@Dirk
ZitatBeim langen Tastendruck werden normalerweise alle 250ms entsprechende Events an die Devices geschickt.
Aktuell sendest du die Dimm-Befehle auch abhängig der Longpress-Zeit. Das würde ich mir dann auch mit ansehen.
Soll ich die BK und LED-Klasse gleich auslagern wenn ich da einmal drann bin?
Klar, bau um. Ich brauche nur noch eine Lösung um das Ding übersichtlich zu halten. In den Library Ordner von Arduino bekomme ich es momentan nicht, da
das mit der Referenz zur Register.h nicht klappt. Macht mich gerade wahnsinnig!!!
@Jan
sieht eigentlich gut aus, FHEM sendet einen Schaltbefehl für Ein (C8) an Channel 3
und das Device sendet einen ACK Status von Channel 3 zurück.
AskSin:
0E 39 B0 11 1A B1 50 5F B7 4A 02 03 C8 00 00 (l:15)(6655901)
0E 39 80 02 5F B7 4A 1A B1 50 01 03 C8 00 00 (l:15)(6655924)
Der einzige Unterschied hier ist, das an Channel 1 gesendet wird
und die Antwort den RSSI enthält. Der ist aber nicht notwendig...
beim original Aktor sieht es so aus:
0E 37 A0 11 1A B1 50 21 D6 3B 02 01 C8 00 00 (l:15)(6596712)
0E 37 80 02 21 D6 3B 1A B1 50 01 01 C8 00 18 (l:15)(6596837)
Ich tippe auf ein Problem in der Device Config von FHEM...
Hallo Jan,
Zitat von: jab am 29 Dezember 2013, 18:31:36
Aktuell habe ich noch das Problem, dass wenn ich den Aktor per FHEM steuere (set on/off) dann bleibt FHEM auf set_on oder set_off.
Da hat Martin Heute etwas nachgebessert => Link (http://forum.fhem.de/index.php/topic,16718.msg119609.html#msg119609). Ging zwar um ein anderes Device, aber das gleiche Erscheinungsbild. Die "device on"-Message wurde nicht an Fhem übergeben zwecks Steuerung der Ausgabe bzw. kam nicht im Log an. Vlt. hilft das Update ja auch hier?!
Gruß
Thomas
kann man eigentlich unter c, also arduino ein #include mit einer variablen setzen
also sowas wie
#define my_header "Register_sonstwas.h"
#include my_header ?
das define würde ich gerne im main sketch machen und global an asksin.h übergeben und dort das include machen?
Hi,
@trilu: Naja der c/c++ präprocessor kann fast alles. Ob es eine gute Idee ist ist eher die Frage ;-).
Habe jetzt das meiste hinbekommen. Der set_on / set_off Bug ist leider bestehen geblieben. Muss ich noch in FHEM gucken.
Selbst peering mit sich selber funktioniert. Also mit sich selbst per Funk. Sieht so aus:
0B 14 B4 40 5F B7 4A 5F B7 4A 02 08 (l:12)(389765)
0E 15 A4 10 5F B7 4A 1A B1 50 06 03 00 00 00 (l:15)(391667)
0A 15 80 02 1A B1 50 5F B7 4A 00 (l:11)(391809)
Eine Frage habe ich noch: Wenn ein Remote Event beim Aktor ankommt schickt er denn irgendwann ein StatusUpdate an die Zentrale? Da sehe ich irgendwie nichts im Funk. Wenn ich einen anderen Aktor schalte sieht das so aus:
0B 25 B4 40 5F B7 4A 21 D6 3B 01 07 (l:12)(2391298)
0E 25 80 02 21 D6 3B 5F B7 4A 01 01 C8 00 24 (l:15)(2391431)
0B 29 A0 01 1A B1 50 21 D6 3B 01 0E (l:12)(2393303)
0E 29 A4 10 21 D6 3B 1A B1 50 06 01 C8 00 14 (l:15)(2393432)
0A 29 80 02 1A B1 50 21 D6 3B 00 (l:11)(2393556)
Ist das schon implementiert? Ansonsten würde ich das übernehmen.
Gruß,
Jan
Peering mit sich selbst muss auch gehen, dass war so geplant, sonst könnte man seine eigenen Geräte ja nicht verknüpfen :-)
Ich muss nur noch mal an die send_poll und receive_poll ran, hier sollen die Strings einfach nur kopiert werden, so dass nicht jedes mal gesendet wird.
Das ist noch ungetestet und vermutlich fehlerhaft.
Der Aktuator muss nach einer peer message seinen Status an die Zentrale melden, dazu gibt es zwei Scenarien:
1. Der Aktuator schaltet verzögert - sieht man am ACK Status l> 0E EA 80 02 1F B7 4A 63 19 63 01 01 C8 40 4B
Vorletztes byte - die 40 signalisiert das es sich um einen verzögerten Schaltbefehl handelt, das kommt immer wenn ein Timer gesetzt ist
Hier wird der Status an die Zentrale zwei mal gesendet, einmal als Status 40 und nach dem Schaltvorgang mit Status 00
2. Der Aktuator schaltet sofort, dann wird nach dem Schalten der Status gesendet
In der relay class ist das auch so implementiert. Konfigurierbar über minDelay und randomDelay
void RL::setCallBack(void msgCallBack(uint8_t, uint8_t, uint8_t), HM *statCallBack, uint8_t minDelay, uint8_t randomDelay) {
randomDelay ist notwendig wenn man mehrere Geräte hat und der Strom ausfällt, bzw. wieder kommt und alle Geräte ihren Status melden.
Wäre kein random drin, würden alle zeitgleich senden, damit würde definitiv und trotz wiederholung, keine Message ankommen.
Kannst du mir einen Tip geben, wie ich die Library (AskSin.cpp und AskSin.h) in den Library Ordner bekomme und trotzdem Zugriff auf die Register.h im Sketch Ordner bekomme?
Du kannst ja einfach beides im Sketch includen. Erst die Register.h dann die Library. Wichtig ist dann nur die Reihenfolge.
Das mit dem setCallBack gucke ich mir an. Aktuell gibt das ja nur eine Nachricht aus. Ich habe mal die relayState so angepasst:
void relayState(uint8_t cnl, uint8_t curStat, uint8_t nxtStat) {
Serial << "c:" << cnl << " cS:" << curStat << " nS:" << nxtStat << '\n'; // some debug message
if (cnl == 3) rl[0].sendStatus();
}
Macht das Sinn so? Oder ist der überflüssig? Auf FHEM Seite bin ich noch etwas ratlos über der set_on und set_off.
Gruß,
Jan
Hallo Horst
ich habe mal versucht das große Asksin-Modul etwas zu zerlegen.
Das ganze war doch schwieriger als erwartet.
Was auch immer sich die Arduino-IDE-Entwickler dabei gedacht haben dass im Sketch-Verzeichniss keine Unterverzeichnisse berücksichtigt werden?
Folgende Module sind jetzt separiert und Teil einer Homematic-Library
- Buttons
- cc110x
- StatusLed
Das Ganze ist nur als Idee gedacht. Vielleicht magst du da ja so übernehmen.
Die Bugs in Buttons hab ich noch nicht fixen können.
Gruß
Dirk
Moin,
können wir die Lib in ein git packen? Ich würde die dann auch bei mir als git submodule einbinden und meine Änderungen als Pullrequest schicken. Die getrennten Klassen sehen schon sehr gut aus. Gefällt mir!
Zusätzlich würde ich gerne noch eine Hardware.h einfügen um alle Pins und Interrupts zu definieren.
Gruß,
Jan
hab jetzt die letzte version von dirk in meinen git gepackt.
hoffe das passt so, bin git neuling!
was mich immer noch stört ist, dass die lib nicht in den library ordner kann, damit wären wir arduino kompatibel.
ich bekomme die register.h einfach nicht in die AskSin.h verlinkt - das ordner management von Arduino ist echt blöd...
https://github.com/trilu2000/AskSinLib
brauchen wir wirklich eine hardware.h - ich fände es besser die pins einfach per funktion an die module zu übergeben?
ähnlich wie beim button, led oder relay modul
cc1101 nutzt eigentlich nur SPI und der ist von arduino definiert, einzig cs und gdo0 pin müssten übergeben werden.
hm nutzt interrupt0 von pin2, den pin kann man im init übergeben, den interrupt zum pin kann man über arduino rausfinden.
Hi,
wir brauchen keine Hardware.h. Generell sollten wir irgendwo die Hardware definieren. Wenn man das beim Init der Klassen übergibt ist das sicherlich auch ok. Für die Interrupts brauchen wir allerdings schon irgendeine Lösung, denn das ist ja unterschiedlich.
Gibt es einen Grund warum die AskSin.h/cpp nicht in der Lib ist? Die sollte am Ende ja auch bei allen gleich sein.
Gruß,
Jan
Ich finde gerade keine Funktion von Arduino die mir den Interrupt zum Pin zurück gibt. Also machen wir es so, dass der Pin und der Interrupt übergeben werden...
AskSin.h/cpp ist nicht in der Lib weil ich keine Möglichkeit finde, die Register.h zu übergeben.
Register.h ist ja Device abhängig, sollte also nicht in den Lib Ordner, sondern in den Sketch Ordner. Blöderweise beruht aber die AskSin.h/cpp auf Angaben aus der Register.h.
Soweit ich das die letzten beiden Tage sehe, gibt es keine Möglichkeit die #defines und structs an AskSin Ordnerübergreifend zu definieren. Falls du eine Möglichkeit findest dann immer her damit!!!!!!!
Hi trilu,
geht es alternativ die Lib in einen Unterordner zu packen? Das ist für mich auch einfacher da ich das dann per git submodul direkt einbinden kann.
Gruß,
Jan
nö, arduino scheint auch keine unterordner zu unterstützen - ich bin gerade echt gefrustet...
Hi,
ich hab noch eine Idee. Wir machen einen Unterordner mit der Lib und entwickeln sie dort. Dazu bauen wir ein Makefile wie dieses hier http://www.iesensor.com/blog/2013/07/09/notesarduino-ide-can-not-include-libraries-within-project-subfolders/ mit dem wir dann die Lib in den Mainfolder präprozessen. Dann können wir auch alles was wir in c auch könnten.
Gruß,
Jan
verstehe ich nicht ganz, unser problem ist es ja nicht die AskSin.h/cpp in einen Unterordner zu legen, dass könnten wir ja jetzt schon.
Unser Problem ist die Verknüpfung zwischen der Register.h und der AskSin.h
AskSin.h in einen Unterordner, würde bedeuten dass die Register.h auch in den Unterordner muss. Das würde per softlink der Register.h auch gehen,
aber dann müsste bei jedem neuen Sketch der softlink neu gemacht werden - auch blöd...
Hi trilu,
wenn die Lib in einem Unterordner liegt kannst du die Register.h ja includen mit include "../Register.h". Damit das in Arduino geht baut man ein Makefile dass dann beides zusammenbaut (präprozessor) damit die IDE damit klar kommt.
Gruß,
Jan
Nur kurz mal als Frage: In Git selber kann man keine Links anlegen? In Subversive geht das, somit könnte so eine Datei direkt über solch einen Link mehrfach verwendet werden.
Gesendet von meinem Xperia Pro mit Tapatalk
hab das mal getestet, aber das mit dem Makefile scheint bei mir nicht zu klappen - wo muss dass hin?
Hi trilu,
ich habe das mal exemplarisch angepasst. Wichtig ist, dass die Einrückungen Tabs sind. Make ist da penibel. Das Makefile liegt im sketch Ordner. Die Lib liegt im Unterordner "lib" und wird dann in das File "LibAskSin.h" zusammengefasst. Im Sketch bindet man dann nur noch letztere ein.
PREPROCESS=g++ -E -C -x c -iquote ./lib
OUTPUT=LibAskSin.h
# -E : Stop after preprocessing.
# -C : Don't discard comments.
# -x c : Treat the file as C code.
# -iquote ./src : Use ./src for the non-system include path.
all: process
clean:
rm $(OUTPUT)
process:
$(PREPROCESS) lib/*.h lib/*.cpp -o $(OUTPUT)
Gruß,
Jan
vermutlich bin ich zu doof...
ich habe jetzt mal das Makefile erzeugt.
Ordnerstruktur ist:
HM6TastenSwitch
HM6TastenSwitch.ino
Makefile
lib
LibAskSin.h
AskSin.h/cpp
usw.
Egal wie ich es drehe, ich bekomme ein ungültiges Verzeichnis wenn ich die LibAskSin.h vom main sketch aufrufen will.
Packe ich die LibAskSin.h ins sketch Verzeichnis, dann wird sie gefunden, aber ich bekomme dann die Meldung das er den Rest, der in der LibAskSin.h angegeben ist nicht findet...
@dirk
habe gerade zwei Probleme gefixt. Die Wiederholrate eines long repeated keypress ist jetzt bei 300ms.
Long Keypress Time > 1 Sekunde hat wegen des Tiefschlafs der CPU nicht funktioniert. Ich halte die CPU jetzt einfach für 2 Sekunden wach nachdem eine Taste gedrückt wurde. Die Zeit verlängert sich dann jeweils, solange etwas gesendet wird...
Ach ja, das Batteriemessen habe ich nach Helpers ausgelagert, damit bleibt der Main sketch übersichtlicher...
Viele Grüße und guten Rutsch
Horst
Hi trilu,
Die generiert lib liegt danach wie das Makefile im Sketch Ordner. Dann müsste es gehen.
Gruß
Jan
Ich habe noch ein Bisschen Modularisiert.
Jetzt ist alles entsprechend ausgelagert und damit etwas übersichtlicher.
ABER:
Das mit dem Makefile funktioniert bei mir auch nicht.
Daher ist Register.h hier im Moment im Library-Ordner.
Mein Vorschlag:
Sämtliche Register, Einstellungen usw. auch in eine Klasse Kapseln und die von außen entsprechen mit "reingeben"
Dann sollte das unabhängig werden.
Die Batteriemessung ist hier noch im Sketch. Das mit den Konstanten will ich da noch ändern und das auch eine Klasse packen die von außen entsprechend konfiguriert wird. So bekommen wir das etwas unabhängiger.
Zitathabe gerade zwei Probleme gefixt.
Hab ich schon mit übernommen.
zu Git:
Ich würde das etwas Strukturieren. Vielleicht so:
/Devices/ - Hier kommen die Sketches der einzelnen Devices rein (jeweils in einen Ordner) (z.B. HM6TastenSwitch)
/Lib/ - Hier kommt die Library rein
Gruß
Dirk
Hi Dirk,
So eine Struktur wollte ich ja eigentlich auch, aber wenn ich nach lib kapsle, dann kommt Arduino damit nicht klar.
Momentan ist der Git nach Arduino Standard. Du musst im Library Ordner von Arduino nur ein Verzeichnis erzeugen und den Git eins zu eins reinkopieren.
Viele Grüsse
Horst
Ich habe Batteriemessung im vorherigen Beitrag noch mal angepasst.
getBatteryVoltage ist wieder in Helpers allerdings ohne Klasse.
Die Bandgap-Reference-Spannung wird der Funktion als Parameter übergeben, somit configurierbar.
Mit der Configuration der ADC-Register müsste man sich ggf. noch was überlegen.
Gruß
Dirk
Zitat
So eine Struktur wollte ich ja eigentlich auch, aber wenn ich nach lib kapsle, dann kommt Arduino damit nicht klar.
Das ist klar. Es ging mir auch "nur" um die logische Trennung.
Also ein Library-Ordner, der muss dann ins Libs-Verzeichniss und je ein Ordner für die "Geräte". Als eine Art "Sammelstelle"
Gruß
Dirk
ZitatMein Vorschlag:
Sämtliche Register, Einstellungen usw. auch in eine Klasse Kapseln und die von außen entsprechen mit "reingeben"
Dann sollte das unabhängig werden.
Für die peer database bekomme ich das hin, aber für das eeprom Handling sehe ich da nicht viele Chancen.
Weil auch so eine Kapsel will ja übergeben werden und dazu muss die Struktur bekannt sein. Bekanntmachen geht über die Register.h...
Völlig ärgerlich.....
ZitatDas ist klar. Es ging mir auch "nur" um die logische Trennung.
Also ein Library-Ordner, der muss dann ins Libs-Verzeichniss und je ein Ordner für die "Geräte". Als eine Art "Sammelstelle"
Aber die haben wir doch jetzt schon - kopier das ganze Verzeichnis in den Library Ordner, innerhalb des Ordners gibts die Struktur Examples, das ist Arduino Standard, aber du kannst den hinlegen wo immer du willst...
Kopie oder Hardlink, geht beides. Mir lässt das mit dem Makefile ja keine Ruhe. Ich werde da Morgen noch ein wenig spielen....
Zitat... Aber die haben wir doch jetzt schon - kopier das ganze Verzeichnis in den Library Ordner
Mir ging es eher um die Sketches für die unterschiedlichen Devices. Oder sollen die dann alle in examples?
Können wir auch machen.
ZitatMir lässt das mit dem Makefile ja keine Ruhe.
Ich finde das Konzept der Arduino-IDE hier auch ziemlich bescheiden.
Abend,
Das Makefile geht bei mir unter Linux ganz gut. Unter lib liegen dann alle Header und cpp Files. Der Präprozessor erzeugt dann daraus ein File und legt es in den Sketch Ordner. Letztes wird in der IDE eingebunden. Als Nebeneffekt kann der Compiler sogar noch etwas besser optimieren.
Was für einen Fehler bekommst du denn? Ggf kannst du auch den avr-g++ nehmen oben im Makefile.
Gruß
Jan
Zitatbei mir unter Linux ganz gut
Das war das "Zauberwort"
Wir haben hier ein Windows-System.
Die IDE verhält sich bei mir so, als ob kein Makefile da währ.
Hallo Zusammen,
nachdem ich die letzten 2 Tage nur gesucht und gelesen habe wie Arduino IDE funktioniert, GCC Kompendium, etc studiert habe und immer noch keine passende Lösung für das Problem bzgl der Register.h und AskSin.h/cpp in einem Library Ordner habe. Habe ich mich entschlossen das Register Handling für die AskSin noch einmal neu zu machen.
Bei der Gelegenheit gehe ich auch den Interrupt an und baue ihn etwas universeller ein.
Deshalb bitte in nächster Zeit keine Änderungen in der AskSin.h/cpp
Viele Grüße
Horst
Moin trilu,
ich habe einen Bug in der RL/Relay Klasse gefunden. Wenn man lgActionType auf 0 setzt sollte er keine Aktionen durchführen. Das funktioniert nur solange nxtStat==0. Wenn man allerdings shActionType=1 setzt dann kann nxtStat durchaus einen anderen Wert annehmen. In poll_rly wird dann die (lastTrig == 40) Logik aufgerufen und er schaltet das Relay.
Lange Rede kurzer Sinn: In trigger40 muss ein nxtStat=0 gesetzt werden:
if (actTp == 0) { // off
nxtStat=0;
} else if ((actTp == 1) && (lngIn == 1)) { // jmpToTarget
// SwJtOn {no=>0,dlyOn=>1,on=>3,dlyOff=>4,off=>6}
if (curStat == 6) nxtStat = srly->lgSwJtOff; // currently off
Soll ich dir einen Pushrequest auf github schicken oder bist du eh gerade am Refactorn?
Gruß,
Jan
Hi trilu,
ich habe noch eine Kleinigkeit entdeckt in der AskSin.cpp:
// check if we have to add another peer, if not return the status of adding the first peer
if (peer[4] == 0) return ret;
daraus habe ich folgendes gemacht:
// check if we have to add another peer, if not return the status of adding the first peer
if (peer[4] == 0 || peer[3] == peer[4]) return ret;
Wenn ich in FHEM peerChan 0 xxx single mache wird bei der Quelle (=remote) der zweite Channel auf 0 gesetzt. Beim Ziel (=Aktor) wird der zweite Channel auf den ersten gesetzt. Keine Ahnung was richtig(er) ist. Ist auch kein richtiger Bug, da er danach ja eh nochmal checkt ob der peer schon existiert.
@martin: Ist das gewollt, dass das unterschiedlich ist?
10 7B A0 01 1A B1 50 20 85 57 01 01 20 85 57 03 00 (l:17)
10 7C A0 01 1A B1 50 20 85 57 03 01 20 85 57 01 01 (l:17)
Ich implementiere gerade Defaults für die Register Listen wenn man peers hinzufügt. Das haben die Originalaktoren ja auch. Also ein Default für Aktorchannels (Liste 3) und einen für Remotechannels (Liste 4).
Gruß,
Jan
kurzer status mal zwischendurch - ich bin jetzt fast fertig mit dem neuen eprom handling und dem dazugehörigen destillRegs script.
damit liegt die asksin library in zukunft im arduino library ordner und die sketches wo auch immer, die abhängigkeit der register.h
ist dann zum sketch und nicht mehr zur lib. bei der gelegenheit konnte ich auch gleich noch ein bischen ram einsparen :-)
ich werde jetzt in den nächsten tagen die funktionen der asksin lib ins neue format bringen und hoffe das es dann bald eine neue plattform
zum weiter testen geben wird.
aussehen wird die register.h dann in zukunft so:
//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
0x01,0x02,0x0a,0x0b,0x0c,0x18,
0x04,0x08,0x09,
0x01,
}; // 10 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
// 0x01,0x02,0x0a,0x0b,0x0c,0x18,
uint8_t burstRx; // 0x01, s:0, e:0
uint8_t :7; // l:0, s:7
uint8_t intKeyVisib :1; // 0x02, s:7, e:8
uint8_t pairCentral[3]; // 0x0a, s:0, e:0
uint8_t localResDis; // 0x18, s:0, e:0
};
struct s_regChanL1 {
// 0x04,0x08,0x09,
uint8_t :4; // l:0, s:4
uint8_t longPress :4; // 0x04, s:4, e:8
uint8_t sign :1; // 0x08, s:0, e:1
uint8_t :7; // l:7, s:0
uint8_t dblPress :4; // 0x09, s:0, e:4
uint8_t :4; //
};
struct s_regChanL4 {
// 0x01,
uint8_t peerNeedsBurst :1; // 0x01, s:0, e:1
uint8_t :6; //
uint8_t expectAES :1; // 0x01, s:7, e:8
};
struct s_regDev {
s_regDevL0 l0;
};
struct s_regChan {
s_regChanL1 l1;
s_regChanL4 l4;
};
struct s_regs {
s_regDev ch0;
s_regChan ch1;
s_regChan ch2;
s_regChan ch3;
s_regChan ch4;
s_regChan ch5;
s_regChan ch6;
} regs; // 60 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel device list table --------------------------------------------------------------------------------------------
s_cnlDefType cnlDefType[] PROGMEM = {
// cnl, lst, pMax, sIdx, sLen, pAddr, pPeer, *pRegs; // pointer to regs structure
{0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)®s.ch0.l0},
{1, 1, 0, 0x06, 3, 0x0006, 0x0000, (void*)®s.ch1.l1},
{1, 4, 6, 0x09, 1, 0x0009, 0x0000, (void*)®s.ch1.l4},
{2, 1, 0, 0x06, 3, 0x000f, 0x0000, (void*)®s.ch2.l1},
{2, 4, 6, 0x09, 1, 0x0012, 0x0018, (void*)®s.ch2.l4},
{3, 1, 0, 0x06, 3, 0x0018, 0x0000, (void*)®s.ch3.l1},
{3, 4, 6, 0x09, 1, 0x001b, 0x0030, (void*)®s.ch3.l4},
{4, 1, 0, 0x06, 3, 0x0021, 0x0000, (void*)®s.ch4.l1},
{4, 4, 6, 0x09, 1, 0x0024, 0x0048, (void*)®s.ch4.l4},
{5, 1, 0, 0x06, 3, 0x002a, 0x0000, (void*)®s.ch5.l1},
{5, 4, 6, 0x09, 1, 0x002d, 0x0060, (void*)®s.ch5.l4},
{6, 1, 0, 0x06, 3, 0x0033, 0x0000, (void*)®s.ch6.l1},
{6, 4, 6, 0x09, 1, 0x0036, 0x0078, (void*)®s.ch6.l4},
}; // 143 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
RPDB::s_devDef dDef = {
6, 13, sliceStr, cnlDefType,
}; // 6 byte
//- ----------------------------------------------------------------------------------------------------------------------
// - eeprom definition ---------------------------------------------------------------------------------------------------
// define start address and size in eeprom for magicNumber, peerDB, regsDB, userSpace
RPDB::s_eeprom ee[] = {
{0x0000, 0x0002, 0x0092, 0x00ce,}
{0x0002, 0x0090, 0x003c, 0x0000,}
}; // 16 byte
@jan
ich hatte mir auch schon mal gedanken gemacht zur default befüllung wenn geppeert wird.
was ich gerne noch in die AskSin implementieren würde, ist eine art registrar für channel module.
damit würde man dem channel modul die asksin lib bekannt machen und der asksin lib das channel modul.
dadurch könnte man beim hinzufügen eines neuen peers einen event auslösen und als rückantwort vom channel modul gibt es die defaultwerte...
so ein registrar hätte dann auch den charm, das statusanfragen, etc nicht aus jedem modul als string oder funktionsaufruf verschickt werden,
sondern das modul meldet wenn sich ein status geändert hat und die asksin lib entscheidet ob der status gesendet wird, oder ein ack
oder was auch immer....
viele grüße
horst
ganz vergessen, es wird auch eine neue default betankung beim booten, bzw nach einem reset geben
das format sieht dann so aus:
//- -----------------------------------------------------------------------------------------------------------------------
// - defaults definitions -------------------------------------------------------------------------------------------------
uint8_t regs01[] PROGMEM = {0x00,0x00,0x65,0x19,0x63};
uint8_t regs02[] PROGMEM = {0xff,0xff,0xff};
uint8_t regs03[] PROGMEM = {0x10,0x02,0x03,0x04};
uint8_t regs04[] PROGMEM = {0x11,0x02,0x03,0x04};
uint8_t regs05[] PROGMEM = {0x12,0x02,0x03,0x04};
uint8_t regs06[] PROGMEM = {0x13,0x02,0x03,0x04};
uint8_t regs07[] PROGMEM = {0x13,0x02,0x03,0x05};
uint8_t regs08[] PROGMEM = {0x15,0x02,0x03,0x04};
uint8_t regs09[] PROGMEM = {0x20,0x02,0x03,0x04,0x00,0x00,0x00,0x00,0x22,0x02,0x03,0x04,0x00,0x00,0x00,0x00,0x24,0x02,0x03,0x04,0x25,0x02,0x03,0x04};
uint8_t regs10[] PROGMEM = {0x30,0x02,0x03,0x04,0x31,0x02,0x03,0x04,0x32,0x02,0x03,0x04,0x33,0x02,0x03,0x04,0x34,0x02,0x03,0x04,0x35,0x02,0x03,0x04};
uint8_t regs11[] PROGMEM = {0x40,0x02,0x03,0x04,0x41,0x02,0x03,0x04,0x42,0x02,0x03,0x04,0x43,0x02,0x03,0x04,0x44,0x02,0x03,0x04,0x45,0x02,0x03,0x04};
uint8_t regs12[] PROGMEM = {0x50,0x02,0x03,0x04,0x51,0x02,0x03,0x04,0x52,0x02,0x03,0x04,0x53,0x02,0x03,0x04,0x54,0x02,0x03,0x04,0x55,0x02,0x03,0x04};
uint8_t regs13[] PROGMEM = {0x60,0x02,0x03,0x04,0x61,0x02,0x03,0x04,0x62,0x02,0x03,0x04,0x63,0x02,0x03,0x04,0x64,0x02,0x03,0x04,0x65,0x02,0x03,0x04};
s_defaultRegsTbl defaultRegsTbl[] = {
// peer(0) or regs(1), channel, list, peer index, len, pointer to payload
{1, 0, 0, 0, 5, regs01},
{1, 6, 4, 0, 1, regs02},
{0, 1, 4, 0, 4, regs03},
{0, 1, 4, 1, 4, regs04},
{0, 1, 4, 2, 4, regs05},
{0, 1, 4, 3, 4, regs06},
{0, 1, 4, 4, 4, regs07},
{0, 1, 4, 5, 4, regs08},
{0, 2, 4, 0, 24, regs09},
{0, 3, 4, 0, 24, regs10},
{0, 4, 4, 0, 24, regs11},
{0, 5, 4, 0, 24, regs12},
{0, 6, 4, 0, 24, regs13},
};
RPDB::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
13, defaultRegsTbl
};
hier setze ich z.b die Id der zentrale
uint8_t regs01[] PROGMEM = {0x00,0x00,0x65,0x19,0x63};
wohin die lib das schreiben soll erfährt sie hier:
// peer(0) or regs(1), channel, list, peer index, len, pointer to payload
{1, 0, 0, 0, 5, regs01},
es wird also in den regs bereich geschrieben, für channel 0, list0, peer index 0
damit lassen sich dann default werte für den ersten start setzen, oder nach einem device reset...
Hallo Horst,
darf ich bei der Gelegenheit nochmal das Thema Variablen Deklaration und PROGMEM abschneiden :-) In neueren Versionen des avr-gcc scheint es zwingend nötig zu sein, diese als const zu deklarieren, was sicher nicht verkehrt ist, da diese Variablen ja durch PROGMEM im read-only Speicher landen und somit als nicht veränderlich gesehen werden müssen. Das hat auch Auswirkung auf die ein oder andere Funktion, die nicht zu verändernde Argumente ebenfalls als const deklarieren sollte.
Nur ein Gedanke am Rande :-)
beste Grüße,
Andy.
Klar darfst du 8)
Ich hatte das Thema schon wieder komplett verdrängt, da meine Arduino mit Avr gcc 4. 3. 2 arbeitet und da macht es anscheinend keinen Unterschied.
Ich bau das aber ein... Ist ja eigentlich nur eine Kleinigkeit
Viele Grüsse
Horst
Mal wieder ein Update nach längerer Zeit. Da es mich so sehr gestört hat, das die AskSin.h/cpp nicht von der Register.h getrennt werden konnte, hatte ich mich entschlossen die Library noch einmal von vorne anzufangen. Auf dem github ist jetzt das Ergebnis.
Ich habe die Register.h und die Definition des Devices komplett umgestellt. Eigene Register.h kann wie gehabt mit destillRegs.pm generiert werden.
Zusätzlich habe ich mal ein Dummy Modul mit reingepackt, daran sollte man gut erkennen wie das Registrieren eines Moduls in der AskSin lib arbeitet.
In diesem Modul gibt es ein Default Load wenn ein neues Peer hinzugefügt wird. Auch sonst sollte jede Kommunikation aus so einem Channelmodul möglich sein.
Ich werde die Tage noch ein Relais und ein Sensor Modul bauen. Die Library habe ich gerade gegen die HM Config Soft getestet und sie sollte ohne Probleme laufen.
Einzig, ihr müsst in der Datei: rf_rc-4-2.xml
supports_aes="false"
2x auf false setzen...
Peeren des Devices mit einem Dimmer und einem PCB Schaltmodul hat auch problemlos geklappt. Sogar das nötige Burst Signal für das Schaltmodul funzt...
Viel Spass beim testen
Horst
Zitat von: trilu am 01 Februar 2014, 19:54:41
Ich werde die Tage noch ein Relais und ein Sensor Modul bauen.
Horst
Hallo trilu
Neues Relais Modul..., da hätte ich doch eine Bitte:
Kannst Du beim neuen Relais Modul einen Taster vorsehen (programmieren), damit man am Aktor selber, das Relais auch schalten kann. Wie das beim HM_LC_SW1_BA_PCB auch der Fall ist.
Schön währe auch, wenn der PowerMode 2 (für den Batteriebetrieb) funktioniert ;-)
Grüsse Martin
jau, das mit dem taster hatte ich auch schon gemerkt, ich weiss nur noch nicht wie ich es umsetze.
hast du den power mode2 schon getestet? ich hatte bisher erst 0 und 4 getestet :-)
Moin,
Man kann doch den Taster einfach mit dem Gerät selber peeren. Mache ich bei mir auch so und funktioniert super.
Gruß
Jan
@trilu
Bei mir hat der Relais-Sketch mit Power Mode 0 immer funktioniert.
Sobald ich den im Mode 2 gesetzt habe, konnte ich den Aktor nur innerhalb weniger Meter vom CUL entfernt schalten.
Ist aber schon ein Weilchen her als ich das ausprobiert habe.
Das Umsetzen mit einem Taster ist wirklich nicht einfach, man müsste wohl einen Interrupt-Pin für den Taster vom Arduino verwenden, und den Aktor falls er dann im Sleep-Mode (Power Mode 2) ist aufwecken, das Relais schalten und den Status über Funk senden, dannach den Aktor wieder schlafen legen.
Ich glaube PIN 2 (wo jetzt die LED drann ist) ist währe ein externer Interrupt möglich.
@jab
Ja, das würde wohl gehen, ist aber eine teure Lösung ;-)
Güsse Martin
bei der pcb ist das über den config taster gelöst. das button modul ist ja bereits fertig und wird auch über interrupts angesteuert. sind pin change interrupts, also von jedem pin verwendbar.
das mit dem internen pairen funktioniert bereits, aber nur ab channel 1. der config taster ist aber channel 0 und dahinter liegt keine peer liste....
möchte ich auch ungern machen, ich hätte das zeug gerne hm kompatibel.
ich schau mir mal die original pcb an und versuche zu verstehen wie hm das macht. da gibts bestimmt ein flag in list0 über das das verhalten konfiguriert wird...
Gibt es hier jemanden der Eins der beiden Geräte sein Eigen nennt und mir ein paar Infos dazu liefern könnte?
HomeMatic Funk-Temperatursensor, außen
HomeMatic Funk-Temperatur-/Luftfeuchtesensor OTH
Viele Grüße
Horst
Zitat von: trilu am 02 Februar 2014, 16:12:28
Gibt es hier jemanden der Eins der beiden Geräte sein Eigen nennt und mir ein paar Infos dazu liefern könnte?
HomeMatic Funk-Temperatursensor, außen Ja.
Viele Grüße
Horst
Gruss,
Joachim
ZitatGibt es hier jemanden der Eins der beiden Geräte sein Eigen nennt und mir ein paar Infos dazu liefern könnte?
Ansonsten haben die Heizungstermostate auch einen "Wetter-Kanal" auf dem Temperatur und Feuchte gesendet werden.
Hier ist übrigens das erste Ergebniss von der Lib welches seit etwa 1-2 Wochen auch produktiv im Einsatz ist :)
http://forum.fhem.de/index.php/topic,19657.0.html
Vielen Dank noch mal an Trilu.
Gruß
Dirk
ok, dann fang ich mal an ein sensor modul für temperatur zu stricken.
kann mir dafür jemand bitte die register liste auslesen?
in fhem auf das device gehen und get regList eingeben...
zusätzlich stellt sich mir die frage, werden die sensor werte zyklisch gesendet, oder nur nach änderung?
wie sieht so eine message aus?
viele grüße
horst
Moin Horst,
die Werte werden zyklisch gesendet nach einer bekannten Formel. Das ist nur wichtig wenn man den Sensor mit bekannten Geräten wie dem HM-CC-RT-DN peert. Kannst du alles 1:1 von FHEM übernehmen: http://forum.fhem.de/index.php/topic,17485.0.html
Was mir noch aufgefallen ist: Du killst deine git History andauernt. Ist das absicht? Macht es für andere schwer auf den Code aufzubauen, da man nicht rebasen kann.
Gibts schon was neues bzgl der Relay Klasse? Vorher kann ich meinen Code nicht umbauen.
Gruß,
Jan
ne, an der relay class bin ich gerade dran.
mit dem github kenne ich mich nicht besonders aus, hatte wieder mal probleme, bzw irgendwelche fehlermeldungen
und dachte mir, fang halt noch mal neu an :-)
sobald du darauf aufbaust verspreche ich, ihn nicht zu killen :-)
allerdings kann es dann sein, dass ich ab und an mal unterstützung brauche...
Zitat von: trilu am 02 Februar 2014, 18:57:18
ok, dann fang ich mal an ein sensor modul für temperatur zu stricken.
kann mir dafür jemand bitte die register liste auslesen?
in fhem auf das device gehen und get regList eingeben...
zusätzlich stellt sich mir die frage, werden die sensor werte zyklisch gesendet, oder nur nach änderung?
wie sieht so eine message aus?
viele grüße
horst
get regList:
list: register | range | peer | description
0: pairCentral | 0 to 16777215 | | pairing to central
Bei beiden Sensoren gleich.
2014-02-02_18:55:05 SolarkollektorTemperatur T: 10.2
2014-02-02_18:57:38 SolarkollektorTemperatur T: 10.2
2014-02-02_18:59:56 SolarkollektorTemperatur T: 10.1
2014-02-02_19:02:00 SolarkollektorTemperatur T: 10.1
2014-02-02_19:04:53 SolarkollektorTemperatur T: 10.1
2014-02-02_19:07:32 SolarkollektorTemperatur T: 10.1
2014-02-02_19:09:57 SolarkollektorTemperatur T: 9.9
2014-02-02_19:12:07 SolarkollektorTemperatur T: 9.9
2014-02-02_19:15:07 SolarkollektorTemperatur T: 9.7
2014-02-02_19:17:52 SolarkollektorTemperatur T: 9.7
2014-02-02_19:20:23 SolarkollektorTemperatur T: 9.7
2014-02-02_19:22:39 SolarkollektorTemperatur T: 9.6
2014-02-02_19:24:41 SolarkollektorTemperatur T: 9.6
2014-02-02_19:27:33 SolarkollektorTemperatur T: 9.4
2014-02-02_19:30:10 SolarkollektorTemperatur T: 9.4
2014-02-02_19:32:33 SolarkollektorTemperatur T: 9.2
2014-02-02_19:34:41 SolarkollektorTemperatur T: 9.2
2014-02-02_19:37:39 SolarkollektorTemperatur T: 9.1
2014-02-02_19:40:22 SolarkollektorTemperatur T: 9.1
2014-02-02_19:42:51 SolarkollektorTemperatur T: 8.9
2014-02-02_19:45:06 SolarkollektorTemperatur T: 8.9
2014-02-02_19:47:06 SolarkollektorTemperatur T: 8.7
2014-02-02_19:49:56 SolarkollektorTemperatur T: 8.7
2014-02-02_19:52:31 SolarkollektorTemperatur T: 8.6
2014-02-02_19:54:52 SolarkollektorTemperatur T: 8.6
Joachim
list: register | range | peer | description
0: burstRx | literal | | device reacts on Burst options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
Gesendet von meinem iPad mit Tapatalk HD
@jab
Die Formel ist:
# int32_t result = (((_address << 8) | messageCounter) * 1103515245 + 12345) >> 16;
# return (result & 0xFF) + 480;
Das Resultat sind die Anzahl der 250ms steps
damit wäre das timing geklärt, das ist easy zu implementieren...
wie sehen die messages aus. ich gehe davon aus, das wenn ein sensor kanal geppeert ist, 41 messages verschickt werden
also sowas:
"41" => { txt => "Sensor_event", params => {
BUTTON => '00,2,$val=(hex($val)&0x3F)',
LONG => '00,2,$val=(hex($val)&0x40)?1:0',
LOWBAT => '00,2,$val=(hex($val)&0x80)?1:0',
NBR => '02,2,$val=(hex($val))',
VALUE => '04,2,$val=(hex($val))',} },
value ist klar, das ist die temperatur in 10tel
was ist NBR?
viele grüße
horst
sorry, sehe gerade es gibt noch eine 70'er message - die scheint besser zu passen
"70" => { txt => "WeatherEvent", params => {
TEMP => '00,4,$val=((hex($val)&0x3FFF)/10)*((hex($val)&0x4000)?-1:1)',
HUM => '04,2,$val=(hex($val))', } },
Ja die Formel ist bekannt und in FHEM auch so implementiert. Funktioniert auch so. Habe ich mit meinen Sensor verifiziert.
Es gibt in der Tat verschiedene messages die man schicken kann. Martin hat dazu in dem verlinkten thread was geschrieben.
Gruß
Jan
auf dem github gibts ein update - habe die relay klasse umgesetzt und funzt ganz gut!
https://github.com/trilu2000/AskSin
ist noch nicht ganz fertig, aber zum testen reicht es allemal.
ich möchte die relay klasse noch von "außen" schaltbar machen und der button klasse ein config flag mit delegate zur relay klasse mitgeben,
damit wäre dann das relay auch direkt schaltbar.
weiterhin fehlt in der relay klasse der trigger 41 - also die verbindung zu sensoren, aber auch das wird noch kommen.
aber zuerst fange ich jetzt mal mit dem temperatur und feuchtesensor an :-)
module basteln macht jetzt, wo der rest einigermassen geht, richtig spass 8)
bin gerade am konzipieren für die sensor class und wie immer liegt der teufel im detail.
ich brauche einen sensor für temperatur und luftfeuchte. meine erste wahl viel auf den DHT22.
Laut spezifikation arbeitet der aber nur zwischen 3.3-6V DC
das würde ausschliessen das ich den sensor mit zwei AA batterien betreiben kann. also blöd...
ok, zur not gehen 3 batterien, aber dann muss ein spannungsregler vor den arduino und das funkmodul...
kennt ihr einen bezahlbaren, leicht anzusteuernden, wenig strom verbrauchenden, temperatur und luftfeuchtigkeitssensor????
Ich wollte den Sensor mit einem SHT10 aufbauen. 2,4 - 5,5 V
Allerdings nicht soo günstig. Geht aber noch.
http://www.aliexpress.com/item/SHT10-100-NEW-SENSIRIO-MODULE-SENSOR-TEMP-HUMIDITY/636054795.html
Gruß
Dirk
liesst sich gut, hast du den schon zu hause liegen?
stromaufnahme, standby verbrauch, etc scheint ok zu sein - genauigkeit zwischen 0,5 und 1 grad
ist auch ok...
library zur ansteuerung gibt es auch, ok, gekauft :-)
habe gerade mal gesucht wo ich so ein teil auf die schnelle bekommen könnte - beim großen c
gibts den sht11 für schlappe 33 euro.
Ja, allerdings genau einen.
Ich hatte bei ALI einen 10er Pack bestellt. Aber nur einen bekommen.
Disput läuft noch.
Kann ich dir aber schicken.
Wenn du willst auch noch einen Helligkeitssensor TSL2561
http://www.aliexpress.com/item/TSL2561T-Digital-light-sensor-TSL2561-Large-amount-of-the-price/1410658269.html
ich müsste zu hause noch ein paar bmp085 als luftdrucksensor haben, können wir ja tauschen :-)
wenn du ihn mir schicken könntest, dann würde ich mit feuchte/temp anfangen, ich denke hier ist der bedarf der größte.
die original wettersensoren finde ich einfach zu teuer, zusätzlich sollte so ein modul kein größeres problem darstellen...
halten wir mal fest -
sht10 für feuchte und temp
bmp085 oder nachfolger für luftdruck
tsl2561 für helligkeit
Ich Habe noch jede Menge bmp180 hier rumliegen. Aus diesem Projekt:
http://forum.fhem.de/index.php/topic,13771.msg85901.html#msg85901
Die sind Codemäßig kompatibel mit dem bmp085
Ich werde die nächsten Tage mal ein Layout für ein Shield machen.
Mit bmp180, sht10 und tsl2561. Man braucht ja nur das zu bestücken was man möchte.
das ist gut - lochraster finde ich nicht hübsch :-)
wenn du platinen machen lässt, denk an mich.
funkmodul ist klar, zusätzlich wäre es cool wenn man einen arduino pro mini
drauf lösten könnte, die feinen pins der neumodernen bauteile machen mich fertig ....
Hier mal eine Frage für mich als "Anfänger" ;-)
Sehe ich das Richtig, dass die aktuellen Libary-Files nun bei Github abzuholen sind, und nicht mehr im ersten Post hier zu finden sind ?
Sorry.. ist vielleicht eine blöde Frage ;-)
Ich habe mal das AskSin-master.zip von Github heruntergeladen, das Zip enpackt und das File HM_LC_SW1_BA_PCB.ino aus dem Ordner HM_LC_SW1_BA_PCB mit der Arduino ide geladen.
Beim Versuch HM_LC_SW1_BA_PCB.ino zu zu kompelieren habe ich folgenden Fehler bekommen:
In file included from HM_LC_SW1_BA_PCB.ino:2:
Register.h:5: error: 'uint8_t' does not name a type
Register.h:13: error: 'HM' has not been declared
Register.h:13: error: expected constructor, destructor, or type conversion before 'dParm'
Gruss Martin
anfänger :-))))
du hast recht, ich muss mal den link in das erste post packen.
du musst den inhalt von AskSin-master.zip in den library ordner von arduino entpacken. entweder in den library ordner
der applikation, also hier: C:\Program Files\arduino-1.0.5\libraries
oder im user bereich: C:\Users\xxxx\Documents\Arduino\libraries
dann lädst du die arduino shell neu, gehst auf examples unter asksin lädst den entsprechenden sketch
und versuchst noch einmal zu kompilieren...
Danke Dir trilu,
Nun hats funktioniert :-)
Ein Stolperstein war noch, dass die Arduino-Ide mit dem Bindestrich bei "AskSin-master" nicht
zurechtgekommen ist.
Ich musste nach "AskSinmaster" umbenennen.
Grüsse Martin
Jetzt wo du es sagst. Kann mich noch erinnern das ich wegen so einem mist auch schon kurz vor dem verzweifeln war...
Habe mich mich damit auch eine Stunde rumgeärgert und danach einen Pullrequest gestellt. Wurde angenommen. Im nächsten Release von der Arduino IDE ist es gefixt und Bindestriche in Ordnernamen funktionieren :-).
Gruß,
Jan
Mein Pairing sieht so aus:
<- 1A 03 A2 00 4F B7 4C 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27)
<- 1A 03 A2 00 4F B7 4C 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27)
<- 1A 03 A2 00 4F B7 4C 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27)
-> NA (192458)
b> 0F 3A 86 10 23 4E 0F 00 00 00 0A 88 C7 0F 00 18 (l:16)
pair/peer did not fit, exit
Ich habe bisher nur den Beispielsketch mit meinen frisch eingetroffenen Panstamps getestet. Ist das Problem bekannt?
soweit ich das sehe ist es kein bug - es werden in der register.h default werte für die master id gesetzt.
das hatte ich für mich zum testen drin, hatte keine lust immer wieder neu zu pairen.
lösung deines problems, in der register.h, ziemlich weit unten
HM::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
3, defaultRegsTbl
};
Aus der 3 eine 0 machen, damit wird nichts mehr default geladen.
Danch kompilieren, auf den panstamp laden und in der seriellen konsole ein r return eingeben.
Mit dem r wird dann ein reset ausgelöst, der eeprom geleert, usw.
danach kannst du neu pairen...
Ich habe mal versucht einenWDS10-TH-O nachzubilden, incl. dem Timing für einen Thermostat.
Der zugehörige Sketch ist im Example Ordner unter HM_WDS10_TH_O.
Derzeit liefert der Sketch keine realen Werte da ich noch keinen Temperatur/Luftfeuchtigkeitssensor habe, deshalb kommen Random Werte
auf Basis des Message Zählers.
Was mir aber helfen würde, da ich keinen Thermostat oder ähnliches habe, wenn jemand das Ding mal versuchen würde zu peeren
und prüft ob die Kommunikation so stimmt.
Viele Grüße
Horst
Cool. Schaue ich am Wochenende mal rein.
ZitatDerzeit liefert der Sketch keine realen Werte da ich noch keinen Temperatur/Luftfeuchtigkeitssensor habe ...
Ich schicke deinen Umschlag mit dem Sensor heute los. Sollte morgen bei dir sein.
Gruß
Dirk
hi dirk,
so war das nicht gemeint :-)
ist aber sehr nett von dir!!!!!!
viele grüße
Hallo trilu,
Ich bin gerade dabei den HM-LC-SW1-BA-PCB Sketch zu testen.
Das Pairing hat schon mal geklappt, fhem hat brav das Gerät angelegt. :-)
Schalten funktioniert auch schon mal. :-)
In der .ino Datei habe ich gesehen, dass da noch eine noch eine Status LED drinn ist.
hm.statusLed.config(4, 6);
Sind das zwei LED´s auf PIN4 und PIN6 ?
Falls ja, für was sind die gedacht ?
Und was ist mit:
hm.battery.config(1,0,1000);
Das prüfen der Batterie-Spannung ?
Falls ja, wie funktioniert das ?
Und was ist mit:
#include <Buttons.h>
Wozu ?
Ist das für einen Configurations-Taster, oder hat das was mit Peering zu tun ?
Grüsse Martin
hm.statusLed.config(4, 6); // configure the status led pin
hm.statusLed.set(STATUSLED_BOTH, STATUSLED_MODE_BLINKFAST, 3);
ja, das ist eine statusled. ursprünglich hatte ich sie mir gebastelt um das powermanagement besser testen zu können,
dirk hat sie dann erweitert so dass es jetzt wirklich eine statusled geworden ist.
das modul ist fest in der asksin verdrahtet, zum normalen nutzen reicht es aus, sich zu entscheiden ob man
einfarbig, also eine led - oder zweifarbig den status signalisiert haben möchte.
über .config(pin1, pin2) legt man die pins vom arduino fest. im beispiel oben liegt eine led an pin 4, die andere an pin 6.
über .set legt man das verhalten fest. hier gibt es folgende modes:
#define STATUSLED_1 1
#define STATUSLED_2 2
#define STATUSLED_BOTH 3
ich denke die modi sind selbsterklärend.
das sind die möglichen muster, auch hier denke ich selbsterklärend:
#define STATUSLED_MODE_OFF 0
#define STATUSLED_MODE_ON 1
#define STATUSLED_MODE_BLINKSLOW 2
#define STATUSLED_MODE_BLINKFAST 3
#define STATUSLED_MODE_BLINKSFAST 4
#define STATUSLED_MODE_HEARTBEAT 5
der letzte wert in .set gibt die anzahl der blinker an. also STATUSLED_MODE_BLINKSLOW und eine 3 lässt die led 3 mal langsam blinken.
hm.battery.config(1,0,1000); // set battery measurement
hm.battery.setVoltage(31); // voltage to 3.1 volt
ist in der tat um die batterie spannung zu messen und den status an die zentrale über den ACK status zu schicken.
void config(uint8_t mode, uint8_t pin, uint16_t time);
derzeit ist nur ein modus implementiert, das ist der interne adc modus des atmel. es kann nur gegen betriebsspannung gemessen werden, in unserem fall die 3 volt.
deshalb erster parameter auf 1 für den internen modus. 0 würde heissen, wir wollen nichts messen.
der zweite wert gibt den pin an, ist beim internen modus aber nicht notwendig. der dritte wert gibt das timing in millisekunden an. in dem beispiel wird folglich jede sekunde gemessen.
mit .setVoltage wird der grenzwert in zehntel volt eingestellt. in dem beispiel sind das 3.1 volt, fällt die batteriespannung unter 3.1 volt signalisieren wir fhem das die batterie alle ist.
#include <Buttons.h> jap, das ist die klasse die für den config taster zuständig ist. in dem HM6Tasten beispiel nutze ich die klasse auch für die schalttaster. um deine frage zu beantworten, in dem von dir genutzeten sketch ist es nur der config taster, also nichts zu tun mit peer.
in dem anderen beispielsketch, als kanal taster hat es sehr wohl was mit den peers zu tun...
viele grüsse
horst
Vielen Dank für die ausführliche Beschreibung.
Noch ne letze Frage zum Config-Taster:
button[0].config(8, NULL);
Denke, die 8 ist der Pin. geschaltet wird gegen GND ?
Hat der Config-Taster denn schon eine Funktion ? oder was passiert beim Betätigen ?
Gruss Martin
jap, die 8 ist der pin und der taster schaltet gegen masse.
beim betätigen wird dann der pairing string gesendet. also ähnliches verhalten wie bei
den original hm geräten. taster drücken und gerät wird angelernt ...
Ich suche gerade die Funktion "HM_Set_Cmd" in der .ino Datei ?
Da müsste doch obige Funktion sin der .ino sein, wenn von fhem on,off.. gesendet wird.
Oder funtioniert das nun anders ?
Grüsse Martin
das "HM_Set_Cmd" gibts in der form nicht mehr. das war eine der grösseren änderungen an der lib. in der lib gibt es jetzt einen registrar in dem sich die channel module registrieren müssen. sämtliche kommunikation läuft jetzt zwischen dem channel modul und der lib direkt.
ich wollte den anwender ein wenig entlasten 8)
Danke für die Antwort,
bin immer noch am grübeln...:-)
Um ein Magnetventil zu schalten, breuchte ich Impulse mit bekannter Länge auf zwei weiteren Digitalen-Pins.
Ich dachte, ich könne den HM-LC-SW1-BA-PCB Sketch schnell etwas umschreiben.
Aber ohne die Funktion "HM_Set_Cmd" weiss ich nicht so recht wie ich das anstellen soll.
Irendwie müssete folgender Code an der richtigen Stelle noch rein.
Einschalten:
digitalWrite(14,LOW);
digitalWrite(15,HIGH);
delay(250);
digitalWrite(14,LOW);
digitalWrite(15,LOW);
Ausschalten:
digitalWrite(14,HIGH);
digitalWrite(15,LOW);
delay(65);
digitalWrite(14,LOW);
digitalWrite(15LOW);
Kannst Du mir da weiterhelfen ?
Grüsse Martin
du möchtest aber nicht die pins parallel schalten?
das würde ich dir zumindest nicht empfehlen, ich hatte mit sowas auch mal experimentiert.
das problem ist, du produzierst einen kurzschluss für einige micro sekunden.
nehmen wir an du hast zwei pins - sagen wir 4 und 5.
im ausgangszustand sind beide pins auf low. jetzt schaltest du pin 4 auf high, damit fliesst jetzt strom zwischen
pin4 high und pin5 low. wenn du jetzt auf high ohne pullup geschaltet hast, dann sind das jetzt 20-30ma die da fliessen.
ich habe in der relay class einen bistabilen modus bereits vorgesehen, schau einfach mal rein...
relay[0].regInHM(1,&hm); // register relay class in HM to respective channel
relay[0].config(0,3,0,5,5); // configure the relay to monostable, therefore only one HW pin needed
der erste config parameter gibt den modus an - 0 ist monostabil, 1 ist bistabil
der nächste parameter, also die 3 gibt den ersten pin an, bei bistabil also den einschalt pin.
dritter parameter ist bei bistabil der ausschaltpin.
die beiden hinteren parameter geben das timing für die messages vor, daran musst du nichts ändern.
falls du, so wie ich glaube, das ventil über die polung, bzw. flussrichtung schaltest, dann kannst du dir das in den relay sketch einbauen.
void MyClassName::adjRly(uint8_t tValue) {
if (curStat == nxtStat) return; // nothing to do
if (hwType == 0) { // monostable - on
if (hwPin[0] > 0) digitalWrite(hwPin[0],tValue); // write the state to the port pin
} else if ((hwType == 1) && (tValue == 1)) { // bistable - on
if (hwPin[0] > 0) digitalWrite(hwPin[0],1); // port pin to on
delay(50); // wait a short time
if (hwPin[0] > 0) digitalWrite(hwPin[0],0); // port pin to off again
} else if ((hwType == 1) && (tValue == 0)) { // bistable - off
if (hwPin[1] > 0) digitalWrite(hwPin[2],1); // port pin to on
delay(50); // wait a short time
if (hwPin[1] > 0) digitalWrite(hwPin[2],0); // port pin to off again
}
reicht dir die beschreibung so?
Hallo trilu,
nein die Pins möchte ich nicht paralell schalten.
Ja, das Ventil wird über die Polung geschaltet.
Das mit dem bistabilen Modus, tönt doch ganz gut :-)
Das heisst für mich, ich müsste "nur" die gepostete Funktion "adjRly(uint8_t tValue)" in der Relais-Klasse etwas umbauen.
Gruss Martin
Ja, genau. Wenn du willst kannst du ja einen neuen modus ins relay basteln. ...
ok, werd ich versuchen.
Danke Dir trilu.
Grüsse Martin
@Dirk
Ich habe die Sensoren gestern bekommen und den SHT10 gleich mal auf Lochraster gelötet.
Die Lötpads sind echt klein :-))))
Musste dann auch gleich mal einbinden und erste Versuche starten:
Temperature = 19.86 C, Humidity = 54.36 %, Dewpoint = 10.38 C
Temperature = 19.82 C, Humidity = 53.86 %, Dewpoint = 10.20 C
Temperature = 19.78 C, Humidity = 52.86 %, Dewpoint = 9.88 C
Temperature = 19.74 C, Humidity = 53.36 %, Dewpoint = 9.98 C
Temperature = 19.70 C, Humidity = 52.36 %, Dewpoint = 9.66 C
Temperature = 19.70 C, Humidity = 51.86 %, Dewpoint = 9.52 C
Temperature = 19.66 C, Humidity = 52.85 %, Dewpoint = 9.77 C
Temperature = 19.66 C, Humidity = 51.85 %, Dewpoint = 9.48 C
Temperature = 19.62 C, Humidity = 51.85 %, Dewpoint = 9.44 C
Temperature = 19.58 C, Humidity = 51.84 %, Dewpoint = 9.41 C
Temperature = 19.58 C, Humidity = 51.84 %, Dewpoint = 9.41 C
Temperature = 19.58 C, Humidity = 51.34 %, Dewpoint = 9.26 C
Temperature = 19.54 C, Humidity = 50.84 %, Dewpoint = 9.08 C
Temperature = 19.54 C, Humidity = 50.84 %, Dewpoint = 9.08 C
Temperature = 19.54 C, Humidity = 50.84 %, Dewpoint = 9.08 C
Temperature = 19.50 C, Humidity = 50.83 %, Dewpoint = 9.04 C
Temperature = 19.50 C, Humidity = 50.83 %, Dewpoint = 9.04 C
Temperature = 19.50 C, Humidity = 50.83 %, Dewpoint = 9.04 C
Temperature = 19.50 C, Humidity = 50.33 %, Dewpoint = 8.89 C
Temperature = 19.50 C, Humidity = 50.33 %, Dewpoint = 8.89 C
Temperature = 19.50 C, Humidity = 50.33 %, Dewpoint = 8.89 C
Temperature = 19.46 C, Humidity = 50.33 %, Dewpoint = 8.85 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.50 C, Humidity = 49.83 %, Dewpoint = 8.74 C
Temperature = 19.46 C, Humidity = 49.82 %, Dewpoint = 8.71 C
Temperature = 19.46 C, Humidity = 49.82 %, Dewpoint = 8.71 C
Sensor läuft schon mal, jetzt muss er nur noch ins Class Modul und das PowerManagement muss
getestet werden. Der nächste Sensor wird dann der Luftdruck...
Danke noch einmal für die Sensoren!
Viele Grüße
Horst
ZitatSensor läuft schon mal, jetzt muss er nur noch ins Class Modul und das PowerManagement muss
getestet werden.
Sehr schön.
ZitatDer nächste Sensor wird dann der Luftdruck...
Da kannst du in das Modul "51_I2C_BMP180.pm" schauen.
Da hab ich den Code schon mal geschrieben. Ist halt Perl. Sollte aber einfach sein das nach C++ zu portieren.
Gruß
Dirk
SHT10 ist eingebunden, anbei ein Update der lib.
Beispielsketch ist zu finden unter Examples/HM_WDS10_TH_O
Der Sketch emuliert den Außensensor mit Temperatur und Luftfeuchte.
Timing sollte auch für die Verknüpfung mit dem Heizkörperregler passen. Im Beispiel ist der Datenpin des SHT10 auf pin 7,
der Clock Pin liegt auf pin9.
Einstellen lässt sich das ganze über sht10.config(7,9,0);
Der letzte Wert ist das Timing - eine 0 heisst, es wird die interne Timing Funktion verwendet, die das Timing aus Message ID
und HM ID berechnet. Falls ihhr ein eigenes Timing nutzen wollt, so könnt ihr einen x-beliebigen Millisekundenwert eintragen.
Ich werde mich in den nächsten Tagen ran setzen und versuchen eine WDC7000 nachzubilden. Hier wird es dann auch den Luftdruck geben...
<- 0C 00 A2 70 6F B7 4C 00 00 00 00 E8 1D (l:13)(2064)
<- 0C 00 A2 70 6F B7 4C 00 00 00 00 E8 1D (l:13)(2766)
<- 0C 00 A2 70 6F B7 4C 00 00 00 00 E8 1D (l:13)(3467)
-> NA (4165)
<- 0C 01 A2 70 6F B7 4C 00 00 00 00 EB 1D (l:13)(168814)
<- 0C 01 A2 70 6F B7 4C 00 00 00 00 EB 1D (l:13)(169517)
<- 0C 01 A2 70 6F B7 4C 00 00 00 00 EB 1D (l:13)(170217)
-> NA (170915)
<- 0C 02 A2 70 6F B7 4C 00 00 00 00 EC 1B (l:13)(301565)
<- 0C 02 A2 70 6F B7 4C 00 00 00 00 EC 1B (l:13)(302268)
<- 0C 02 A2 70 6F B7 4C 00 00 00 00 EC 1B (l:13)(302968)
-> NA (303667)
<- 0C 03 A2 70 6F B7 4C 00 00 00 00 EF 1C (l:13)(483815)
<- 0C 03 A2 70 6F B7 4C 00 00 00 00 EF 1C (l:13)(484517)
<- 0C 03 A2 70 6F B7 4C 00 00 00 00 EF 1C (l:13)(485218)
-> NA (485916)
<- 0C 04 A2 70 6F B7 4C 00 00 00 00 F0 1C (l:13)(651819)
<- 0C 04 A2 70 6F B7 4C 00 00 00 00 F0 1C (l:13)(652519)
<- 0C 04 A2 70 6F B7 4C 00 00 00 00 F0 1C (l:13)(653219)
-> NA (653918)
<- 0C 05 A2 70 6F B7 4C 00 00 00 00 F0 1B (l:13)(805318)
<- 0C 05 A2 70 6F B7 4C 00 00 00 00 F0 1B (l:13)(806019)
<- 0C 05 A2 70 6F B7 4C 00 00 00 00 F0 1B (l:13)(806719)
-> NA (807417)
<- 0C 06 A2 70 6F B7 4C 00 00 00 00 F1 1B (l:13)(944318)
<- 0C 06 A2 70 6F B7 4C 00 00 00 00 F1 1B (l:13)(945018)
<- 0C 06 A2 70 6F B7 4C 00 00 00 00 F1 1B (l:13)(945719)
-> NA (946417)
<- 0C 07 A2 70 6F B7 4C 00 00 00 00 F2 1A (l:13)(1069068)
<- 0C 07 A2 70 6F B7 4C 00 00 00 00 F2 1A (l:13)(1069768)
<- 0C 07 A2 70 6F B7 4C 00 00 00 00 F2 1A (l:13)(1070469)
-> NA (1071167)
<- 0C 08 A2 70 6F B7 4C 00 00 00 00 F3 1B (l:13)(1243318)
<- 0C 08 A2 70 6F B7 4C 00 00 00 00 F3 1B (l:13)(1244018)
<- 0C 08 A2 70 6F B7 4C 00 00 00 00 F3 1B (l:13)(1244719)
-> NA (1245417)
<- 0C 09 A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1403068)
<- 0C 09 A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1403768)
<- 0C 09 A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1404469)
-> NA (1405167)
<- 0C 0A A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1548318)
<- 0C 0A A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1549019)
<- 0C 0A A2 70 6F B7 4C 00 00 00 00 F4 1B (l:13)(1549719)
-> NA (1550417)
<- 0C 0B A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1679319)
<- 0C 0B A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1680019)
<- 0C 0B A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1680719)
-> NA (1681418)
<- 0C 0C A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1859817)
<- 0C 0C A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1860519)
<- 0C 0C A2 70 6F B7 4C 00 00 00 00 F4 1A (l:13)(1861220)
-> NA (1861918)
<- 0C 0D A2 70 6F B7 4C 00 00 00 00 F5 1A (l:13)(2025820)
<- 0C 0D A2 70 6F B7 4C 00 00 00 00 F5 1A (l:13)(2026520)
<- 0C 0D A2 70 6F B7 4C 00 00 00 00 F5 1A (l:13)(2027220)
-> NA (2027919)
So sehen die Messages des neuen Moduls aus. Ein Update im Git mache ich dann heute Abend...
Viele Grüße
Horst
Hallo zusammen,
auch ich lese hier sehr interessiert mit und bin begeistert, wie weit das Projekt ist.
Mein Ziel ist es derzeit, mit den RFM22b-Modulen Homematic zu sprechen, um günstig µC-Projekte mit fhem/Homematic verheiraten zu können. Die Hürde, dass die RFM22-Module eine etwas andere Ansteuerung benötigen, habe ich inzwischen genommen und kann sie zumindest zum Mitlesen und dekodieren der Nachrichten benutzen. Kompatible Nachrichten senden ist der nächste Schritt.
Volle HM-Kompatibilität (alle Channels, zig Peer-Möglichkeiten) ist mir nicht so wichtig, möglichst kleine Controller dagegen schon. Mich macht derzeit hier die Code-Größe von ca. 6-8k stutzig. Bringt Arduino so viel Overhead mit, oder sind es die Debugging-Ausgaben? Mein Code hat derzeit ca. 2k, davon ist allerdings 50% Debugging (usart, einige Strings, alle möglichen Ausgaben per serieller Schnittstelle). Wenn ich alle usart-Ausgaben entferne komme ich auf 1k (Daten in struct einlesen, Adresse vergleichen, msg-type & 0x80 sowie Payload-Byte 2 auf 0xc8 prüfen und dann LED einschalten). Mit rudimentärem Pairing und Ack-Handling sollten knapp 2k drin sein.
Ideal fände ich, ggfls. sogar die kleinen 8-beinigen Tinys verwenden zu können, die haben allerdings max. 8k Speicher (und 256 Bytes sram ;-)) Für einen einfachen Ein-Aus-Schalter, der sich auch am Gerät bedienen lässt, gleichzeitig aber auch per fhem steuerbar ist, sollte es reichen.
Hat jemand eine Ahnung, wie klein die Arduino-Codebase zu bekommen wäre? Kann man die Projekte ggfls. zusammenführen?
Sebastian
Hi Sebastian,
Herzlich willkommen.
Um ehrlich zu sein, ich habe keine Ahnung warum der Code mittlererweile so gross ist. Ich habe ziemlich genau vor einem Jahr mit den Arduinos und C++ begonnen. Die Debug Strings brauchen schon eine Menge Flash, aber selbst wenn ich die abschalte bleibt eine Menge Code übrig. Aber das selbe Problem hat HM wohl auch, sonst würden sie nicht einen 644 einsetzen :o
Die beiden Projekte zusammen fahren sollte aber einfach sein, ich habe versucht die Lib so flexibel wie Möglich aufzubauen. Für die Kommunikation mit dem Funkmodul gibt es eine eigene Klasse, das ist die CC1101.h/cpp. Da drin sind alle relevanten Funktionen zur Ansteuerung des Funkmoduls.
Es gibt im wesentlichen drei Funktionen die du von aussen zugänglich machen musst.
.init - wird von HM.init aufgerufen um das Modul zu initialisieren.
.send - das ist die Funktion um codierte Strings zum senden zu übergeben.
.recv - hier wird HM signalisiert, das ein String im Empfangsbuffer liegt
Ich suche später noch einmal genau nach den Funktionen und stell sie hier rein.
Zur Einbindung in das Framework würde es dann reichen einfach ein Flag zu setzen und es wird die entsprechende HW ausgewählt.
Die Register und Kommunikationsfunktionen liegen dann alle in der AskSinMain.h/cpp und müssten 1:1 funktionieren.
Wenn du willst, schalte ich dich dann für den git frei. Darfst auch gerne an der AskSin Code und Grösse optimieren.
Attiny halte ich für fast ausgeschlossen, für Peers, etc braucht es einfach ein wenig eeprom Speicher. Der Vorteil von HM ist ja, das die Geräte nicht über eine Zentrale reden müssen, sondern direkt kommunizieren können. Um das variabel zu halten und bequem über eine Software konfigurieren zu können, braucht es einen gewissen Protokolloverhead.
Viele Grüsse
Horst
Edit: So gerade noch einmal nachgeschaut - wir brüchten eine rm22 class mit folgenden Funktionen:
void config(uint8_t csP, uint8_t mosiP, uint8_t misoP, uint8_t sckP, uint8_t gdo0P, uint8_t int_gdo0); // set the respective pins
hier wird letztendlich nur Konfiguriert - Die Funktion wird vom Main Sketch aufgerufen, du bist also frei welche Parameter du übergeben möchtest.
void init(); // initialize CC1101
Wie weiter oben beschrieben. Wird von hm.init aufgerufen.
uint8_t sendData(uint8_t *buf, uint8_t burst); // send data packet via RF
Wird von HM aufgerufen um codierte Strings zu senden. Codier Routine ist in HM. Burst ist 0 oder 1 und schaltet einfach nur das Sendemodul für 250ms ein.
Ist notwendig um mit Devices, die im Standby sind, zu sprechen. Wenn Burst0, dann Sende Teil einschalten und String sofort in den Sendebuffer des Moduls schreiben.
uint8_t receiveData(uint8_t *buf); // read data packet from RX FIFO
Funktion um den Empfangsbuffer des Funkmoduls auszulesen und in den übergebenen Buffer zu schreiben.
Das etwas empfangen wurde, wir in der AskSinLib derzeit über Interrupt 0 and Pin2 signalisiert, ich weiss nicht, ob dein Funkmodul das kann?
Schau mal nach und sag Bescheid. Wie gesagt, es würde mich freuen, wenn wir weitere Funkmodule mit in die Lib integrieren könnten.
Und Mitstreiter zur Code Optimierung sind auch herzlich Willkommen....
Moin trilu,
Zitat von: trilu am 04 März 2014, 08:10:15
Hi Sebastian,
Herzlich willkommen.
Um ehrlich zu sein, ich habe keine Ahnung warum der Code mittlererweile so gross ist. Ich habe ziemlich genau vor einem Jahr mit den Arduinos und C++ begonnen. Die Debug Strings brauchen schon eine Menge Flash, aber selbst wenn ich die abschalte bleibt eine Menge Code übrig. Aber das selbe Problem hat HM wohl auch, sonst würden sie nicht einen 644 einsetzen :o
Die beiden Projekte zusammen fahren sollte aber einfach sein, ich habe versucht die Lib so flexibel wie Möglich aufzubauen. Für die Kommunikation mit dem Funkmodul gibt es eine eigene Klasse, das ist die CC1101.h/cpp. Da drin sind alle relevanten Funktionen zur Ansteuerung des Funkmoduls.
Dass ELV/eQ3 überall Megas einsetzen, ist mir bekannt. Im 1-Kanal-Bausatz ist ein Mega328 drin, allerdings ist der im TFQP32 mit 0,8mm Pinabstand schon ziemlich fummelig zu löten. Die 8-beinigen Tinys mit 1,27mm lassen sich dagegen wunderbar verbauen (wobei die nur mit HVSP sinnvoll einzusetzen sind, damit man den RESET-Pin als I/O benutzen kann, sonst wird´s etwas knapp mit Ein-/Ausgängen).
Zitat von: trilu am 04 März 2014, 08:10:15
Es gibt im wesentlichen drei Funktionen die du von aussen zugänglich machen musst.
.init - wird von HM.init aufgerufen um das Modul zu initialisieren.
.send - das ist die Funktion um codierte Strings zum senden zu übergeben.
.recv - hier wird HM signalisiert, das ein String im Empfangsbuffer liegt
Ich suche später noch einmal genau nach den Funktionen und stell sie hier rein.
Zur Einbindung in das Framework würde es dann reichen einfach ein Flag zu setzen und es wird die entsprechende HW ausgewählt.
Die Register und Kommunikationsfunktionen liegen dann alle in der AskSinMain.h/cpp und müssten 1:1 funktionieren.
Wenn du willst, schalte ich dich dann für den git frei. Darfst auch gerne an der AskSin Code und Grösse optimieren.
Attiny halte ich für fast ausgeschlossen, für Peers, etc braucht es einfach ein wenig eeprom Speicher. Der Vorteil von HM ist ja, das die Geräte nicht über eine Zentrale reden müssen, sondern direkt kommunizieren können. Um das variabel zu halten und bequem über eine Software konfigurieren zu können, braucht es einen gewissen Protokolloverhead.
Die Diskussion über den EEPROM-Speicher habe ich verfolgt. Allerdings meine ich, dass man zumindest für einfache Schalter mit weniger auskommen kann:
- Serien-Nr. etc kann in´s Flash, es reicht, wenn ich die beim Kompilieren festlege
- Adresse der Zentrale (3 Bytes)
- Adresse(n) der Peers (x * 3 Bytes)
- aktueller Zustand (1 Byte)
Selbst mit 256 Bytes EEPROM kann ich da schon einige Peers unterbringen. Wie gesagt, für mich muss es nicht das komplette HM-Protokoll mit allen Channels etc. werden. "Kopieren" von bekannten Devices empfiehlt sich mE trotzdem, damit die Teile auch mit CCUs einsetzbar sind. Aber bei unsupporteten Features kann dann ja einfach NACK gesendet werden, wenn ich das richtig verfolgt habe.
Bisher habe ich meinem Nachbau-Empfänger eine ID eines zuvor gepairten Schalters verpasst. Er liest die Kommunikation mit und schaltet parallel zum "Original" ein und aus. Das funktioniert, solange der original-Schalter auch aktiv ist und brav die ACKs sendet; ohne die ACKs funktioniert es genau ein mal ;-)
Als nächstes werde ich also die Senderoutine und "eigene" ACKs einbauen, dann kann der "vorgepairte" Schalter eingesetzt werden. Pairing ist dann die nächste Baustelle. Aber das kennst Du ja 8)
Zitat von: trilu am 04 März 2014, 08:10:15
Edit: So gerade noch einmal nachgeschaut - wir brüchten eine rm22 class mit folgenden Funktionen:
void config(uint8_t csP, uint8_t mosiP, uint8_t misoP, uint8_t sckP, uint8_t gdo0P, uint8_t int_gdo0); // set the respective pins
hier wird letztendlich nur Konfiguriert - Die Funktion wird vom Main Sketch aufgerufen, du bist also frei welche Parameter du übergeben möchtest.
Ist das Arduino-spezifisch? Ich kenne das so, dass man die Pins in der Header-Datei konfiguriert. Dort steht dann z.B.
#define MOSI PB0
#define SCK PB2
Im restlichen Proramm wird dann anstatt der direkten PIN-Bezeichnung nur MOSI bzw. SCK verwendet. Die Ersetzung wird beim Kompilieren einmalig vorgenommen, Speicher wird hinterher nicht mehr dafür benötigt. Da sich die Parameter auch zur Laufzeit nicht ändern (die Verdrahtung ist nun mal so, wie sie ist...), sehe ich keinen Grund, hierfür eine Funktion vorzusehen.
Zitat von: trilu am 04 März 2014, 08:10:15
void init(); // initialize CC1101
Wie weiter oben beschrieben. Wird von hm.init aufgerufen.
uint8_t sendData(uint8_t *buf, uint8_t burst); // send data packet via RF
Wird von HM aufgerufen um codierte Strings zu senden. Codier Routine ist in HM. Burst ist 0 oder 1 und schaltet einfach nur das Sendemodul für 250ms ein.
Ist notwendig um mit Devices, die im Standby sind, zu sprechen. Wenn Burst0, dann Sende Teil einschalten und String sofort in den Sendebuffer des Moduls schreiben.
uint8_t receiveData(uint8_t *buf); // read data packet from RX FIFO
Funktion um den Empfangsbuffer des Funkmoduls auszulesen und in den übergebenen Buffer zu schreiben.
Ja, das lässt sich 1:1 abbilden. Wie gesagt, senden muss ich noch machen ;-)
Die Routinen sind etwas aufwendiger, da CRC-Berechnung und data whitening in Software realisiert werden muss. Data whitening habe ich schon, da auch für den Emfpang nötig. CRC kommt.
Was meinst Du mit "codier routine ist in HM"? Diese XOR-Geschichte habe ich bisher von der Empfangsroutine direkt erledigen lassen, sodass meine Receive-Routine direkt eine Struct hm_message befüllt. Denn meines Erachtens nach werden nirgendwo die verschlüsselten Daten benötigt, die können also direkt beim Emfpang dekodiert bzw. codiert werden. Je nach dem, was das Modul selbst kann (CRC, data whitening), ist es evtl. nötig, das hier zu erledigen, da bin ich mir allerdings noch nicht sicher. Bedeutet zwar evtl. etwas doppelten Code, aber nicht im AVR, sondern nur auf dem PC ;-)
Zitat von: trilu am 04 März 2014, 08:10:15
Das etwas empfangen wurde, wir in der AskSinLib derzeit über Interrupt 0 and Pin2 signalisiert, ich weiss nicht, ob dein Funkmodul das kann?
Schau mal nach und sag Bescheid. Wie gesagt, es würde mich freuen, wenn wir weitere Funkmodule mit in die Lib integrieren könnten.
Und Mitstreiter zur Code Optimierung sind auch herzlich Willkommen....
Ja, es gibt einen frei konfigurierbaren Interrupt-Pin. Auch einen Wakeup-Timer gibt es (für burst/Stromspar-Modus), so weit bin ich aber noch nicht.
Sebastian
Hallo,
kurzes Update zum RFM22:
Ich habe den CRC-Code implementiert und bin in der Lage, mit dem RFM22 Pakete zu senden, die der CC1101 versteht. Die ersten ACKs auf Schaltbefehle aus FHEM habe ich erfolgreich gesendet, allerdings noch ein bißchen hakelig (FHEM sendet die Befehle mehrfach, eines der ACKs wird dann schließlich akzeptiert), das könnte ein Timing-Problem sein, da ich bisher die gesendeten Befehle unmittelbar nach dem Empfang über die serielle ausgebe, bevor ein ACK gesendet wird.
Code-Größe bisher einschließlich Debugging ca. 2,5k, ich rechne mit etwa 1,5k ohne Debugging-Code. Mal sehen, was für Pairing etc. noch draufgeht. Aber es gibt ja Tinys mit 4k oder gar 8k ;-)
Sebastian
Versuch mal in deinem Debug Code das Timing mit einzubauen, also eine Millis() Ausgabe nach der Seriellen String Ausgabe.
HM hätte den ACK gerne nach spätestens 300ms, hört sich wenig an, ist im Falle Arduino aber eine halbe Ewigkeit.
Was mir noch einfällt, schau mal welche RSSI Werte du bekommst, wenn die Frequenz oder Modulation nicht passt, dann
geht der Empfangsstärkewert in den Keller.
Das eigentliche Funkgedöns macht bei meiner Code Größe auch nicht so viel aus, das String und Registerhandling pumpt
den Code auf. Am meissten ist es, das Register auslesen und die Peer Geschichte, also alle Peers lesen und die Registerwerte (List3/List4)
der einzelnen Peers.
Moin,
es lag am Timing; wenn ich das ACK versende, bevor ich die empfangene Message mit 2.400 Baud ausgebe, bekomme ich keine Fehler.
Inzwischen ist auch das Pairing halbwegs implementiert, d.h., das Device sendet nach 1s Druck auf eine Taste eine Pairing-Message, meldet sich als 1-Kanal-Schaltaktor-Bausatz und holt sich so die ID der Zentrale. Schalten per FHEM geht danach, allerdings wird der Status immer als "50%" angezeigt. Ich muss also meine Config noch aufräumen und getConfig noch implementieren.
ATtiny, ich komme: Code-Größe mit Debugging-Ausgaben 2,6k. Ich vermute, dass die Arduino-Variante einige Libs immer dazulinkt, egal, ob sie benötigt werden oder nicht. Jedenfalls dürfte es kein Problem sein, das in den größeren Tinys unterzubringen. Ein paar 25er und 45er habe ich noch hier, sobald die genannten Fehler ausgemerzt sind, werde ich mal einen Tiny45 versuchen.
@trilu: Kannst Du mir noch eine Frage zum Burst-Modus beantworten? Du sendest für 350ms ein burst-Signal. Laut Code wird dafür nur der Tx-Mode des CC1101 aktiviert. Fängt der CC1101 bereits in diesem Moment an, Präambel-Bits zu senden? Im Datenblatt habe ich dazu nichts gefunden.
Allerdings dürfte es auf Sensor-Seite auch reichen, den passiven Burst-Modus zu unterstützen (also alle 300ms aufwachen und lauschen). Für Schalter wäre es natürlich schon fein, auch mit Bursts wecken zu können; mal sehen, ob der RFM22 das auch kann.
Schönen Abend,
Sebatian
Hi Sebastian,
stell doch deinen seriellen Port auf 57600, dann passen mehr Bytes in kürzerer Zeit durch die Leitung.
Dein Vorgehen kommt mir bekannt vor, am Anfang der ACK, dann Pairing, jetzt getConfig :-)
Burst Mode ist einfach - Im Burstmode wird einfach nur das Sendeteil eingeschaltet und der Empfänger lauscht im 250ms Takt
ob die Trägerfrequenz an ist. Da werden noch keine Bytes ausgetauscht.
Bei Schaltern gibt es den Burst nur pro Kanal, also Schaltaktor sendet 300ms Trägerfrequenz und dann erst Bytes.
Das was du meinst geht bei Schaltern anders...
Schalter sendet irgendwas, Zentrale merkt das der Schalter empfangsbereit ist und sendet ein getConfig oder was auch immer, in
dem String wird ein Flag mitgesendet um das Device wach zu halten. Es findet also kein Polling vom Schalter statt, sondern er schläft
wirklich und wird nur durch Interrupts der Taste aufgeweckt.
Ein HM String fängt ja mit der Länge an, gefolgt vom Counter und dann kommt das Message Byte, in dem Message Byte gibt es ein paar Flags:
my @culHmCmdFlags = ("WAKEUP", "WAKEMEUP", "CFG", "Bit3",
"BURST", "BIDI", "RPTED", "RPTEN");
#RPTEN 0x80: set in every message. Meaning?
#RPTED 0x40: repeated (repeater operation)
#BIDI 0x20: response is expected
#Burst 0x10: set if burst is required by device
#Bit3 0x08:
#CFG 0x04: Device in Config mode
#WAKEMEUP 0x02: awake - hurry up to send messages
#WAKEUP 0x01: send initially to keep the device awake
Das #WAKEUP ist das entsprechende Flag das du auswerten musst um dein Gerät für einen gewissen Zeitraum wach zu halten...
Viele Grüße
Horst
Moin,
@trilu: das Problem mit der Baudrate ist, dass ich den internen RC-Oszillator verwende und keinen Baudraten-Quarz, sodass nicht alle Geschwindigkeiten funktionieren. Ein Test mit 38400 geht aber (jedenfalls bei den aktuellen Temperaturen/Sternen-Konstellationen ;-)), sodass ich trotz Debug-Ausgaben mit dem Timing hinkomme.
@martin:
Ich habe inzwischen das Peering und Registerauslesen soweit implementiert, dass ich mein Device ohne Fehler mit fhem pairen kann. Allerdings ist mir aufgefallen, dass fhem das Setzen der Register und die Abfrage wiederholt. Ist das Absicht oder liegt es ggfls. daran, dass ich mir aus der Config nur die Rosinen herausgepickt habe (Adr. 2/Reg. 0 habe ich ignoirert und beim Auslesen dementsprechend nicht angegeben). Gleicht fhem die gesetzten Register exakt mit den Angaben ab? Da es keinen Fehler gibt (das Device ist danach angelegt und funktioniert einwandfrei) ist es eher ein kosmetisches Problem.
sending done
received message:10 20 b0 1 42 42 42 f3 92 de 0 5 0 0 0 0 0 config start
sent message:a 20 80 2 f3 92 de 42 42 42 0
0
sending done
received message:13 21 a0 1 42 42 42 f3 92 de 0 8 2 1 a 42 b 42 c 42 Adresse setzen (was ist Bank 0, Adr. 2?)
sent message:a 21 80 2 f3 92 de 42 42 42 0
0
sending done
received message:b 22 a0 1 42 42 42 f3 92 de 0 6 config end
sent message:a 22 80 2 f3 92 de 42 42 42 0
0
sending done
received message:10 23 b0 1 42 42 42 f3 92 de 0 4 0 0 0 0 0 hat's geklappt?
sent message:12 23 a0 10 f3 92 de 42 42 42 2 a 42 b 42 c 42 0 0
0
received message:a 23 0 2 42 42 42 f3 92 de 0
0
sending done
received message:b 24 b0 1 42 42 42 f3 92 de 1 3 peer list
sent message:e 24 a0 10 f3 92 de 42 42 42 1 0 0 0 0
0
received message:a 24 0 2 42 42 42 f3 92 de 0
0
sending done
received message:10 25 b0 1 42 42 42 f3 92 de 0 4 0 0 0 0 0 und nochmal?!
sent message:12 25 a0 10 f3 92 de 42 42 42 2 a 42 b 42 c 42 0 0
0
received message:a 25 0 2 42 42 42 f3 92 de 0
0
sending done
received message:b 26 b0 1 42 42 42 f3 92 de 1 3
sent message:e 26 a0 10 f3 92 de 42 42 42 1 0 0 0 0
0
received message:a 26 0 2 42 42 42 f3 92 de 0
0
sending done
received message:b 27 b0 1 42 42 42 f3 92 de 1 e
sent message:e 27 a4 10 f3 92 de 42 42 42 6 1 0 0 0
0
received message:a 27 0 2 42 42 42 f3 92 de 0
Ich habe die Libary neu installiert ;)
Nun bekomme ich den HM_LC_SW1_BA_PCB Beispiel-Sketch nicht zum compelieren :(
Der Compiler hat rekamiert, dass die Funktion:
relay[0].config(0,3,0,5,5);
nicht geht (falsche Parameter...)
Also habe in der Relay.h und der Relay.cpp:
//void config(void Init(), void Switch(uint8_t), uint8_t minDelay, uint8_t randomDelay);
auf:void config(uint8_t type, uint8_t pinOn, uint8_t pinOff, uint8_t minDelay, uint8_t randomDelay);geändert.
In der Relay.cpp habe ich dann://tInit = Init;
//tSwitch = Switch;
auskomentiert.
Nun motzt der Compiler, das in der Sensor_SHT10_BMP0805.h und .cpp etliches nicht stimmt.
Sehe aber nicht, wo im HM_LC_SW1_BA_PCB Sketch der Sensor eingebunden wird.
Braucht es die Sensor Files den überhaubt für den Relais Sketch ?
Grüsse Martin
so, probier jetzt mal. hatte ein paar änderungen und das beispiel nicht nachgezogen.
ZitatBraucht es die Sensor Files den überhaubt für den Relais Sketch ?
ne, eigentlich nicht. aber irgendwo sind sie noch in der lib verknüpft. entpacke einfach das
paket: additional-sensor-libraries.zip
in dein arduino library ordner.
Danke Dir trilu
Compilieren leuft nun durch :D
Dafür bekomme ich kein Pairing mit fhem hin :(
freeMem: 1020 byte
pair: 00 00 00
reset device, clear eeprom...
prep eeprom
reset done
<- 1A 00 A2 00 4F B7 4C 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27) (64696)
<- 1A 00 A2 00 4F B7 4C 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27) (65398)
<- 1A 00 A2 00 4F B7 4C 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27) (66099)
-> NA (66793)
Sieht so aus, als ob fhem nichts zurückschickt, oder mein Gerät es nicht lesen kann.
fhem hat nur das Filelog erstellt, aber kein Gerät angelegt.
Vielleicht liegts aber auch an meinem Hardware Aufbau ?
Muss nun leider weg.
Grüsse Martin
Ich denke es liegt an fhem. Du bekommst ja kein ACK zurück. Hast du in fem pairforseconds gesetzt?
Hallo mmatt,
check mal in Register.h ( weit unten )
HM::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
0, defaultRegsTbl // von 3 auf 0 setzen!!
};
LG Robbi
Hi Robbi24,
ich bin begeistert, es scheint als hättest du dich mit der Lib beschäftigt!
Hatte ich übersehen, die Strings werden ja an meine default Master ID gesendet.
Der defaultRegsTbl darf natürlich nicht gesetzt sein, sonst werden Register Änderungen bei jedem
Neustart wieder platt gemacht...
Viele Grüße
Horst
Hallo zusammen
Ja, nun hat das Pairing geklappt :D
- Die defaultRegsTbl auf 0 gesetzt.
- fhem neu gestartet.
- hmPairForSec abgesetzt.
- und das "r" und danach das "p" abgesetzt.
Danke Euch, nun kann ich weiter "basteln" :-)
Grüsse Martin
So... weiter geht´s mit den blöden Fragen ;)
Du hast ja eine neue Funktion gemacht :orelay[0].config(&initRelay,&switchRelay,2,2);
"initRelay()" und "switchRelay()" in der .ino habe ich gesehen.
Kann irgendwo noch bistabil (jetzt ist ja monostabil) definieren, oder muss ich das in den obigen zwei Funktionen selber programieren ?
Grüsse Martin
erst einmal: vielen Dank für die tolle Lib. Ich habe erfolgreich alle Examples zum Spielen gebracht.
Als erstes reales Anwendungsprojekt denke ich an einen Mini-IR-Sender auf Arduino pro mini Basis.
Mit wenigen IR-Signalen sehe ich da kein Problem, ich habe schon erfolgreich mit dem LedLampeRelay Sketch + IRremote Lib meinen Sat-Receiver ein/ausgeschaltet. Auf 6-8 Channels mit festen IR-Code Zuweisungen zu erweitern ist ja auch kein Problem.
Nur wenn man flexibel sein will, stößt man an Grenzen. Ich stelle mir vor, von FHEM aus den IR-Code als String zu senden. Nur komme ich nicht richtig weiter. In diesem Thread kam ja mal der Vorschlag, den Dimmer-Value zu missbrauchen, um multiple zu werden. Nur finde ich im aktuellen git keine Reste mehr von dieser Dimmer-Funktion.
Vielleicht hat jemand einen Denkanstoß für mich, wie man FHEM überreden kann, nicht nur on / off zuzulassen, dann könnte man mehr als C8 und 00 im Byte3 senden, das würde mir schon reichen zum Auswerten. Oder kann man auch Byte 2 und 1 benutzen, ich muss irgendwie eigene Werte an den Actor bekommen?
ein schönes WE
Mario
Eigene Werte an den Aktor bekommen ist eigentlich kein Problem der Library als vielmehr ein Problem von FHEM.
Letztendlich beruhen alle meine Beispiele auf realen HM Geräten, d.h. die model ID ist die selbe wie von original HM Geräten.
Deshalb erkennt FHEM das Gerät und stellt natürlich auch nur die geräteabhängigen Flags zur Verfügung.
Um die größte Flexibilität zu haben müsstest du ein eigenes Device definieren, also eine eigene Model ID nutzen.
Im Wettersensor Thread gibts dann auch Beispiele zum erweitern von FHEM.
Vermutlich ist es am einfachsten du hinterlegst die IR Commands im Device und steuerst sie mit Werten von 0 - 255 an.
Also über das set command
"11;p01=02" => { txt => "SET" , params => {
Wenn du Flexibilität bzgl. der IR Befehle möchtest, dann musst du auch entsprechende Register einrichten um die Befehlsfolgen aufzunehmen.
Viele Grüße
Horst
Ich habe mich heute zwar intensiv in diesen Thread mit deinen Erklärungen beschäftigt, aber was du mit "11;p01=02" => { txt => "SET" , params => {
meinst, raffe ich noch nicht ganz.
Aber so ähnlich bin ich heute schon weitergekommen. Ich werde die Codes im Device hinterlegen und nur den Key dazu senden.
Ich habe dafür in der Register.h auf ein HM_LC_DIM1L_CV (dimmer) umgestellt, ein Dummy.cpp leicht angepasst und kann jetzt von FHEM per "set <name> pct <int>" den Int-Value an den Sketch schicken.
So kann ich weitermachen ... Danke
Hallo Zusammen
Unterstützt die Library max. 1 Homematic-Gerät oder konnten auch schon mehrere Geräte emuliert/nachgebildet werden ?
Der 1-fach Aktor HM_LC_SW1_BA_PCB ist als Beispiel enthalten, hat schon jemand den 4fach Aktor HM_LC_SW2_BA_PCB probiert ?
Gruss Peter
Hallo Liste,
ich bin jetzt auch etwas weiter gekommen mit dem HB-1W-KEY (Siehe dazu diese Wiki-Seite: http://www.fhemwiki.de/wiki/Kategorie:HomeBrew)
Auf einem Panstamp läuft der 1-Wire Busmaster, der meldet einen erkannten iButton als Tastendruck via HomeMatic an FHEM.
Am meisten hatte ich mit der eher, sagen wir es vorsichtig, minimalistischen Dokumentation zu kämpfen.
Es wird auch noch eine ganze Weile dauern, bis mein Gerät für Andere (oder für mich selbst...) produktiv verwendbar ist.
Die Frage stellt sich, ob man nicht sinnvollerweise sowohl in FHEM, als auch in die mitgelieferten Beispiele der AskSin library etwas aufnimmt, das "generische" Geräte erlaubt. Also z.B. mit bis zu 3 Sensorkanälen und bis zu 3 Aktorkanälen). Das würde die weitere Eigenentwicklung deutlich vereinfachen.
LG
pah
Hallo Zusammen,
ich gebe zu, die Dokumentation ist viel zu kurz gekommen - aber im Moment fehlt mir einfach die Zeit um hier weiter zu machen.
Falls Fragen sind packt sie einfach hier rein, das Meiste habe ich noch im Kopf.
ZitatDer 1-fach Aktor HM_LC_SW1_BA_PCB ist als Beispiel enthalten, hat schon jemand den 4fach Aktor HM_LC_SW2_BA_PCB probiert ?
Das funktioniert, hatte ich schon getestet. Zum 1fach Aktor sketch bedarf es nur ein paar kleiner Änderungen. Die Model ID muss angepasst werden
und die Relay Class muss es vier mal geben und damit auch die Zuordnung zu den Kanälen. Also in der destillReg vier gleiche Kanäle definieren
und im main sketch zurodnen.
Falls es eigene Geräte sein sollen, also wo es keine Definition in der HM Config Soft oder in FHEM gibt, muss das natürlich angepasst werden.
Ansonsten kann man sich so viele Kanäle pro Device (und damit verschiedene Funktionen) definieren, wie eben in den Arduino rein passen.
Viele Grüße
Horst
Soll, um Himmels willen, keine negative Äußerung sein. Es wäre aber schade, wenn Eure ganzen Überlegungen bei der Programmierung so langsam verloren gingen.
LG
pah
Hallo zusammen,
ich möchte hier mal mein Projekt vorstellen: http://forum.fhem.de/index.php/topic,18510.0.html (http://forum.fhem.de/index.php/topic,18510.0.html)
Dort will ich eine Art PanStamp Modul mit dem STM32 realisieren. Die Mikrocontroller haben einen ARM Cortex an Board und sind sehr gut ausgestattet und zudem gibt es diese zu einem sehr günstigen Preis. Somit sollten sie sich für jede Menge Projekte in der Hausautomatisierung verwendet lassen. Da ich persönlich mit diesen Prozessoren sehr gute Erfahrungen sammeln konnte, werde ich diesen für meine Projekte verwenden.
Da ich daheim bereits Homematic-Komponenten habe, möchte ich gerne diese Bibliothek für mein Board verwenden. Dazu muss ich die vorhandene Library portieren.
Besteht dafür Interesse, sodass der Code auch entsprechend im Repository eingepflegt werden soll?
Der Hauptteil wird sich wohl in der cc110x.cpp abspielen, da der Zugriff beim AVR und STM32 sehr unterschiedlich sein werden. Sinnvoll wäre es dort wohl eine entspreche HAL einzubauen, dann wäre man von der HW unabhängig.
Ich kenne die Arduino-Entwicklungsumgebung nicht. Wie werden dort die ino-Dateien eingebunden? Außerdem werden in der HM Klasse einige Arduino spezifische Bibliotheken eingebunden. Muss mal schauen wie man das am schönsten umsetzen kann.
Wäre super, wenn ich hier ein wenig Unterstützung bekommen können.
Soweit mal von mir.
Viele Grüße und noch ein schönes Wochenende!
Grüße
Holger
PS: Nachtrag: Ich habe hier mal die Bibliothek und deren Zusammenhänge dargestellt:
(http://forum.fhem.de/index.php?action=dlattach;topic=14140.0;attach=15014;image)
Hallo Horst
Ich habe nun doch mal ein Panstamp Entwicklungskit besorgt, da die Kombi Arduino Nano-CC1101 bei mir nicht stabil genug läuft. (Pairing, etc.)
Mein Ziel ist es den AVR als Homematic-Blackbox mit 4 Eingängen (z.B. 4-fach Funk-Taster-Schnittstelle - HM-PBI-4-FM) und 4 Ausgängen (z.B. 4-Kanal-Schaltaktor - HM-LC-Sw4-Ba-PCB) zu betreiben.
Ist diese Konstellation denkbar ? (Der Sketch HM_LC_SW1_BA_PCB.ino ist ja bereits in den Beispielen enthalten)
Gruss Peter
Vorneweg erstmal ein dickes LOB für die lib und die ganze Mühe die drinsteckt.
Ich bin gerade dabei die lib mal auszuprobieren und habe schon die ersten Probleme die ich mangels gefundener Doku
hier mal zur Lösung anbiete :)
1. Wenn ich das LedLampeRelay Beispiel kompiliere und auf einen Arduino Uno spiele bekomme ich folgende Ausgabe:
Starting sketch...
Available commands:
p - start pairing with master
r - reset device
b[0] b[n] s - send a string, b[0] is length (50 bytes max)
c - print configuration
$nn for HEX input (µù
Danach ist der Arduino eingefroren und nimmt keine Kommandos mehr an und sagt auch nix mehr. Wenn ich die Ausgabe des Hilfetexts auskommentiere
gehts normal weiter.
2.
Das Pairen mit FHEM funktioniert nicht. Ich setze in FHEM hmPairForSec auf beispielsweise 100. Dann auf dem Arduino ein reset (r) und pair (p) bringt folgende Ausgabe:
Sta²÷ing sketch...
freeMem: 1053 byte
pair: 00 00 00
reset device, clear eeprom...
prep eeprom
reset done
<- 1A 00 A2 00 F4 B6 5D 00 00 00 15 00 11 54 4C 55 30 30 30 32 30 30 33 10 01 01 00 (l:27) (6270)
<- 1A 00 A2 00 F4 B6 5D 00 00 00 15 00 11 54 4C 55 30 30 30 32 30 30 33 10 01 01 00 (l:27) (6970)
<- 1A 00 A2 00 F4 B6 5D 00 00 00 15 00 11 54 4C 55 30 30 30 32 30 30 33 10 01 01 00 (l:27) (7671)
-> NA (8367)
Warum sind hier jetzt komische Zeichen im "Starting Sketch" ?!?
Die dtRegs in der Register.h stehen auf 0. Gibts da noch einen Tip woran es noch hängen kann?
3.
Wenn ich die Beispiele compile krieg ich teilweise Fehler:
AskSin\AskSinMain.cpp.o: In function `fastdelegate::DelegateMemento::SetMementoFrom(fastdelegate::DelegateMemento const&)':
/utility/Fastdelegate.h:640: undefined reference to `modTbl'
/utility/Fastdelegate.h:640: undefined reference to `modTbl'
/utility/Fastdelegate.h:641: undefined reference to `modTbl'
/utility/Fastdelegate.h:641: undefined reference to `modTbl'
AskSin\AskSinMain.cpp.o: In function `HM::regCnlModule(unsigned char, fastdelegate::FastDelegate5<unsigned char, unsigned char, unsigned char, unsigned char*, unsigned char, void>, unsigned int*, unsigned int*)':
D:\Programme\Arduino\libraries\AskSin/AskSinMain.cpp:249: undefined reference to `modTbl'
AskSin\AskSinMain.cpp.o:D:\Programme\Arduino\libraries\AskSin/AskSinMain.cpp:249: more undefined references to `modTbl' follow
Hallo Meta
Das Einfrieren von manchen Befehlen (z.B. "r") hatte ich früher auch.
Welche Hardware verwendest du ?
Gruss Peter
Ich hab einen Arduino Uno auf dem das Sketch läuft und ein Funkmodul (bei ebay geschossen) das eigentlich nur ein Breakout für den CC1101 Chip ist.
Gestern habe ich 2 Funkmodule mittels der panstamp library mal reden lassen, was auch funktioniert hat. Die Module funktionieren also.
Hallo,
die Fehlermeldung bekomme ich auch - keine Ahnung warum. Mich würde auch interessieren woran das liegt.
Gruß Christoph
Das hängen bleiben hatte ich anfangs auch mal - damals lag es am SPI Bus timing.
Schalte mal im Modul cc1101.h das Debuggen ein:
#define CC_DBG
Ich hatte mal das Problem beim pairen das der Master zu nah am Gerät lag - du brauchst mindestens einen Meter Abstand zwischen den Geräten.
Aber auch hier hilft das Debugflag von cc1101 um den Fehler einzugrenzen.
undefined reference to `modTbl'
Dieser Fehler ist ziemlich eindeutig :-)
Ich habe den modTbl erst nach einigen Beispielen eingebaut und jetzt sucht die Lib in der Register.h danach.
Je nach Beispiel, bzw. Anzahl der Kanäle sowas einfügen:
HM::s_modtable modTbl[] = {
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
}; // 16 byte
Es muss eine Zeile pro Kanal da sein - Kanäle zählen ab 0, dieses Beispiel ist also für ein Gerät mit einem Kanal.
ZitatMein Ziel ist es den AVR als Homematic-Blackbox mit 4 Eingängen (z.B. 4-fach Funk-Taster-Schnittstelle - HM-PBI-4-FM) und 4 Ausgängen (z.B. 4-Kanal-Schaltaktor - HM-LC-Sw4-Ba-PCB) zu betreiben.
Das kann die Lib jetzt schon, du musst nur eine Entsprechende Register.h generieren.
Das wäre die passende devDefinition.pm
use strict;
#Beispiel
# ========================switch =====================================
# battery powered 1 channel temperature
# "003D" => {name=>"HM-WDS10-TH-O" ,st=>'THSensor' ,cyc=>'00:10' ,rxt=>'c:w:f' ,lst=>'p' ,chn=>"",},
# 1 device
# 1 kanal
# 6 peers je kanal erlaubt
#----------------define reglist types-----------------
package usrRegs;
my %listTypes = (
regDev =>{ intKeyVisib=>1, burstRx=>1, pairCentral=>1,
},
regKey =>{
sign=>1, longPress=>1, dblPress=>1,
peerNeedsBurst=>1, expectAES=>1,
},
regAct =>{
sign =>1, #| literal | | signature (AES) options:on,off
lgActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
lgCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
lgCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
lgCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
lgCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
lgMultiExec =>1, #| literal | required | multiple execution per repeat of long trigger options:on,off
lgOffDly =>1, #| 0 to 111600s | required | off delay
lgOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
lgOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
lgOnDly =>1, #| 0 to 111600s | required | on delay
lgOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
lgOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
lgSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
lgSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
lgSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
lgSwJtOn =>1, #| literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
shActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
shCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
shCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
shCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
shCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
shCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
shCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
shOffDly =>1, #| 0 to 111600s | required | off delay
shOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
shOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
shOnDly =>1, #| 0 to 111600s | required | on delay
shOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
shOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
shSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
shSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
shSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
shSwJtOn =>1, #|
},
);
# -----------assemble device -----------------
my %regList;
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regKey",peers=>6};
$regList{2}={type => "regKey",peers=>6};
$regList{3}={type => "regKey",peers=>6};
$regList{4}={type => "regKey",peers=>6};
$regList{5}={type => "regAct",peers=>2};
$regList{6}={type => "regAct",peers=>2};
$regList{7}={type => "regAct",peers=>2};
$regList{8}={type => "regAct",peers=>2};
sub usr_getHash($){
my $hn = shift;
return %regList if($hn eq "regList" );
return %listTypes if($hn eq "listTypes" );
}
Danach einfach "perl destillregs.pl" und du bekommst die Register.h geliefert.
Viele Grüße
Horst
Servus zusammen,
Großes Lob! wirklich eine super lib!
Nach viel Lesen frage ich mich, ob der Speicher reicht, um einen Aktor und einen Sensor zu realisieren. Konkret möchte ich einen Schalter mit 6 Tastern und 6 LEDs in Größe eines Einbaurahmens nutzen, um zu schalten und den Schaltzustand zu visualisieren. Ala HM-PB-6-WM55 nur mit zusätzlicher LED Visualisierung. Oder brauche ich zwei Arduinos und zwei RF interfaces?
der speicher reicht dicke - die tasten haben nur zwei config flags.
einzig die io's könnten knapp werden, aber du kannst ja die leds auch multiplexen...
Ja, ein Beispiel mit 6 Eingängen und 6 Ausgängen wäre schon hilfreich, dann müsste ich es nur noch auf 4 reduzieren ;D
Danke trilu für die Tipps.
PS: Sieht die lib eigentlich schon den 24h alive modus (spätestens alle 24h ein Lebenszeichen) vor, oder ist dies im sketch abzufackeln ?
Gruss Peter
Wahrscheinlich reichen schon die aktuellen beispiele mit der led lampe relay und dem 6fach taster. Werde mich mal in ein paar wochen dran setzen, sobald ich zeit habe. Es sei denn mir kommt jemand zuvor.
Grüße
Hallo zusammen,
ich bin noch dabei, die AskSin Library mit einem Hardware Abtraction Layer zu versehen, damit man diese auch auf anderen Plattformen verwenden kann. Siehe mein Post weiter oben.
Habe gerade noch einen kleinen Bug gefunden, den ich euch nicht vorenthalten will:
Zitat
uint32_t HM::getHMID(void) {
uint8_t a[3];
a[0] = dParm.HMID[2];
a[1] = dParm.HMID[1];
a[2] = dParm.HMID[0];
a[3] = 0;
return *(uint32_t*)&a;
}
Das Array sollte eine Größe von 4 haben, sonst kracht es irgendwann mal auf dem Stack! ;)
Grüße
Holger
Hi Holger,
wieso siehst du das Array für die HM ID als Bug?
Soweit ich mich erinnere behandle ich die HM ID unterschiedlich zu den Peers, dürfte also nicht krachen weil es nur 3 Byte hat.
Die HM ID wird ja eigentlich nur zur Adressierung verwendet und hat folglich nur die 3 Byte.
Ich versuche die Lib auch gerade etwas weiter zu modularisieren, lagere gerade das EEprom Handling in eine eigene Class aus.
Das habe ich dann auch für send und receive vor...
Viele Grüße
Horst
uint32_t HM::getHMID(void) {
[color=red] uint8_t a[3]; //dieses Array hat nur 3 Byte[/color]
a[0] = dParm.HMID[2];
a[1] = dParm.HMID[1];
a[2] = dParm.HMID[0];
[color=red] a[3] = 0; //Hier schreibst du in eine Adresse, für die kein Speicher mehr reserviert ist[/color]
return *(uint32_t*)&a;
}
Wenn der Kompiler für die Funktion und deren lokalen Variablen den Stack verwendet, kann es unter Umständen sein, dass mit der Aktion "a[3] = 0;" ein Wert vorher aus dem Programm überschrieben wird. Bei den AVRs wächst der Stack nach unten. Wenn du Glück hast, dann verwendet er nur die CPU Register und schreibt später eh einen anderen Wert dort wieder rein. Zur Sicherheit aber
uint32_t HM::getHMID(void) {
[color=green]uint8_t a[4]; //jetzt kann sicher in a[3] geschrieben werden[/color]
a[0] = dParm.HMID[2];
a[1] = dParm.HMID[1];
a[2] = dParm.HMID[0];
[color=green]a[3] = 0; //Hier kann nun sicher beschrieben werden[/color]
return *(uint32_t*)&a;
}
Evtl macht es sind Sinn den Endianess gleich bei der Initialisierung anzupassen und als Struct ein Union zu verwenden. Verbraucht ein Byte mehr, der Zugriff ist allerdings schneller. Falls die Struktur dParm allerdings direkt für den zuübertragenden Protokoll-Stream verwendet wird, dann geht es nicht. Soweit war ich allerdings noch nicht. ;-)
union HmId_T
{
uint8 hmid[4];
uint32 hmIdWord:
}
inline uint32_t HM::getHMID(void) {
return = dParm.hmIdWord;
}
Zur Überarbeitung des Biliothek:
Die Eeprom Zugriffe sind mir auch schon aufgefallen. Die habe ich bei meiner Version auch schon bereinigt.
Ebenso ist mir das WatchDog und das Power-Handling aufgefallen. Teilweise werde ich da das PowerHandling für den CC1101 in dessen Klasse packen.
Mein Ziel ist es die AskSin Klasse nur als Protokoll-Stack Implementierung zu haben. (Da sollten keine direkten AVR Register Zugriffe mehr vorhanden sein und spezielle HW vorausgersetzt sein.) Ist noch ein wenig Arbeit, deswegen komme ich nicht so schnell voran wie ich möchte. ;-) Beispielsweise habe ich schon alle GPIO, I2C, SPI, TIMER, EEPROM Zugriffe in HAL Interfaces verpackt und greife von AskSin Lib generisch drauf zu. Das Pendant für die Treiber des AVRs fehlen dann noch.
Wenn du willst können wir uns gern mal darüber unterhalten.
Grüße
Holger
kann ich mir irgendwo deinen code anschauen - ich glaube ich kann das was lernen :-)
Nein der Code ist nur bei mir lokal. Die Änderungen will ich dir gerne zukommen lassen.
Es gibt 2 Möglichkeiten:
1. Branch in deinem Repository. Dann könnten wir den Stack gemeinsam pflegen. Bis jetzt habe ich die Änderungen im Code mit Kommentaren versehen und einen Compiler-Switch verwendet. Mein Code sollte sich entsprechend bei dir noch kompilieren lassen.
2. Ich gebe dir meine Änderungen und du nimmst dir die Teile raus, die du gebrauchen kannst.
Langfristig werde ich die Streaming-Klassen ebenfalls entsorgen, da sie nicht so performant sind und nicht auf jedem Target gleich gut unterstützt werden. Für die reine Debug-.Ausgabe gibt es auch andere Möglichkeiten. Mein Problem ist, dass ich beim STM32 nicht mit dem Arduino Framework arbeiten kann. Deswegen nimmt mein Kompiler mal mehr oder weniger gute Standard-Bibliotheken.
Hast du die Klassen bisher allein geschrieben? Für die AVR ist der Code mit Arduino gut augestellt. Wenn man mehrere Plattformen unterstützen will, so wie ich, dann wird man um einige Änderungen nicht drumherum kommen. Weil Plattformunabhängig bedeutet, dem AVR wird etwas mehr an Ressourcen abverlangt und der Code wird nicht mehr ganz so optimiert sein. Wenn ja kann man beide Projekte als eins laufen lassen. Anders werden die beiden Projekte irgendwann zuweit auseinander sein, damit Bugfixes/Features einfach ausgetauscht werden können.
Viele Grüße
Holger
puh, immer diese entscheidungen ;)
eigentlich habe ich viel zu wenig ahnung vom programmieren. wenn die hal zusätzlich resourcen kostet ist das schlecht,
da nicht wirklich viel platz im 328 übrig ist. auf der anderen seite hat das arduino zeug ja auch schon eine hal eingebaut.
am liebsten würde ich zusammen entwickeln - mir fehlt für viele sachen einfach die zeit und das technische wissen.
naja, und ideen hätte ich auch sooooo viele ;D
lass uns doch so machen - du schickst mir mal deinen code und dann entscheiden wir...
zur debug ausgabe schreibst du, dass es da auch andere möglichkeiten gibt, was wäre das?
viele grüße
horst
Hallo Peter,
falls Du noch interesse hast. Der sketch ist im Anhang. Nutzt jedoch eine alte relay.h und .cpp die ins den lib ordner muss.
Grüße, kuek
Zitat von: PeterS am 01 Mai 2014, 23:19:57
Hallo Zusammen
Unterstützt die Library max. 1 Homematic-Gerät oder konnten auch schon mehrere Geräte emuliert/nachgebildet werden ?
Der 1-fach Aktor HM_LC_SW1_BA_PCB ist als Beispiel enthalten, hat schon jemand den 4fach Aktor HM_LC_SW2_BA_PCB probiert ?
Gruss Peter
Hallo kuek
Werde es die Tage mal testen und feedback geben ;)
Gruss Peter
Danke für die Lib erstmal! Echt super!
Ich habe leider ein Problem und ich komme da einfach nicht weiter:
Und zwar hab ich einen Selbstbau-Sensor von Dirk und das Problem ist, dass im Schnitt nur ca. 50% der vom Sensor gesendeten Nachrichten beim FHEM ankommen. Ich benutze einen HMLAN. Die fehlgeschlagenen Nachrichten sind einfach komplett nicht zu sehen im HMLAN.
Nun hab ich schon ziemlich viel mit der Firmware des Sensors rumgespielt und folgendes rausgefunden:
Das Problem verschwindet (also es kommen ca. 100% der Nachrichten an), wenn ich die Nachrichten mit "Burst" sende. Also wenn ich CC110x::sendData mit einer "1" als zweiten Parameter aufrufe. Das ist natürlich erstmal nur ein Workaround und ich hätte auch gerne ohne Burst eine stabile Kommunikation.
Ich hab schon die Doku des CC1101 studiert (leider verstehe ich nur grob die Hälfte wegen mangelnder Kenntnisse) und wenn ich das richtig verstehe, dann bewirkt das Senden mit Burst, dass die Lib den CC1101 vor dem Senden schon für 360ms in den TX-Modus schaltet. Wenn der CC1101 in den TX-Modus geschaltet wird ohne Daten im TX-FIFO, dann sendet er wohl einfach die Präambel (101010101...) bis Daten in den TX-FIFO gesteckt werden.
Also das heißt einfach, dass der Burst Modus eine extrem lange (360ms) Präambel zur Folge hat (anstatt nur der sonst üblichen 4 Bits)?
Also kurz gesagt, bekomme ich nur eine stabile Kommunikation hin, wenn ich vor der eigentlichen Nachricht für 360ms (100ms reichen auch, hab ich getestet) Präambeln sende.
Nun kann ich eigentlich nur raten, voran das liegen könnte:
Es sieht für mich so aus, als würde mein HMLAN schlafen und auch nur ab und zu aufwachen, um Daten zu empfangen (burst-like). Oder aus anderen Gründen bekommt der HMLAN nicht mit, dass da gerade eine Nachricht vorbei gekommen ist.
Hat da jemand evtl. irgendwelche Ideen zu? Ich komme da einfach im Moment nicht weiter :( Bin für jegliche Tipps dankbar.
ist die Lib nicht mehr im Git ? oder umgezogen?
habe nur diese URL:
https://github.com/trilu2000/AskSinLib
doch, doch - ist hier
https://github.com/trilu2000/AskSin
aber nach dem merge mit dirks änderungen gehen die meissten beispiele nicht und ich bin noch nicht dazu gekommen das wieder gerade zu ziehen.
danke. wollte nur mit der neuesten Lib mal rumspielen.
Habe nun eine Frage zur Lib:
in der Methode HM::sendOut() wird überprüft, ob der Empfänger der Nachricht identisch mit dem Device selbst ist (als HMID = Empfänger). Dann werden die Daten in den Receive-Buffer kopiert.
if (memcmp(&send.data[7], HMID, 3) == 0) { // if the message is addressed to us,
memcpy(recv.data,send.data,send.data[0]+1); // then copy in receive buffer. could be the case while sending from serial console
}
Es wird aber offenbar trotzdem auch gesendet - oder zumindest versucht. Soweit ich das nachvollziehen konnte kommt es hier meistens zu Problemen, da kein ACK (von sich selbst) empfangen wird. Mir ist nicht ganz klar, wie das läuft. Ich hätte angenommen, der Tranceiver kann natürlich nicht gleichzeitig Senden und sich selbst empfangen.
Kurz: Gibt es einen vernünftigen Grund hier überhaupt zu senden bzw. es zu versuchen? Dies scheint mir die Ursache für Verzögerungen zu sein die ich bei dem 1-fach-Schaltaktor (mit der Custom-FW) habe. Bei dem kommt es ja aufgrund der kombinierten Remote-Aktor Funktionilität ständig dazu, dass man an sich selbst "senden" will.
mhh, ich weiss nicht aus welcher funktion dein code schnippsel stammt, aber grundsätzlich sende ich nicht an mich selbst...
void HM::send_out(void) {
if (bitRead(send.data[2],5)) send.retries = dParm.maxRetr; // check for ACK request and set max retries counter
else send.retries = 1; // otherwise send only one time
send.burst = bitRead(send.data[2],4); // burst necessary?
if (memcmp(&send.data[7], dParm.HMID, 3) == 0) { // if the message is addressed to us,
memcpy(recv.data,send.data,send.data[0]+1); // then copy in receive buffer. could be the case while sending from serial console
send.counter = 0; // no need to fire
} else { // it's not for us, so encode and put in send queue
send.counter = 1; // and fire
send.timer = 0;
}
}
weil wenn an sich selbst adressiert, dann send counter auf 0 - heisst nicht senden....
Hallo Trilu,
wie ich inzwischen bemerkt habe, wurde das gepostete Codeschnippsel wohl von jab für den UP-Aktor selbst geändert. Insofern sorry für die Frage.
Ich habe mich in den letzten Tagen sehr intensiv mit der Lib und der Anwendung von JAB beschäftigt. Da ich bisher weder Panstamps noch Arduinos habe sondern tatsächlich als Experimentierhardware nur den HM_LC_Sw1PBU_FM habe ich halt überwiegend mit dem dort vorhandenen (und offenbar verändertem) Code gearbeitet. Die Struktur der aktuellen Lib im Git und die der dort eingebundenen ist grundverschieden. Da muss ich noch hinterkommen. Ich staune aber inzwischen über mich selbst und ich denke ich habe die Lib überwiegend verstanden. Dazu zählte auch, diesen Thread hier (und andere) mehrere male zu lesen ...
In diesem Thread wird immer wieder über 2 Dinge gesprochen:
- ein Perl-Script um die register.h zu erzeugen für selbst "ausgedachte" Geräte
- ein Anwendungsbeispiel als Dimmer.
Gibt es das wirklich oder waren das nur Ideen?
Ich habe mir inzwischen Panstamps bestellt, das wird aber noch dauern (Shop ist im "Urlaub") und ich will ja JETZT was machen ... eines meiner Ziele ist es eine Custom-FW auch für den HM-LC-Dim1TPBU-FM zu schreiben (also die Dimmer-Variante des UP-Schaltaktors, zu dem es schon die Custom-FW gibt. Die ist hardwaremäßig praktisch identisch, nur dass eben kein Relass sondern ein Mosfet zum Dimmen dran hängt.
Hab ursprünglich überlegt, für Dimmversuche die eingebaute LED zu nehmen, aber die hängt dummerweise an einem nicht-PWM Port.
Hautparbeit dürfte wohl das Implementieren des Dimmer-Registersets mit den entsprechenden Logiken/Aktionen sein (Die Sets sind ja bei Dimmern deutlich größer, es müssen Rampen mit unterschiedlichen Zeiten usw. unterstützt werden.
Daher meine Frage ob es hier schon irgendetwas zu gibt, was ich als Denkansatz nehmen könnte.
Nochmals vielen Dank!
Freut mich das dir die lib gefällt und du dich damit beschäftigen willst. Das Perl Script gibt es schon. Liegt auf dem git und heisst destillregs.pm.
Damit kannst du dir den Inhalt für die register.h generieren lassen.
Ein Dimmer Modul habe ich noch nicht gemacht, ist aber sehr ähnlich dem Schaltmodul. Statt schalten müssen die Dimm-Register noch ein gebaut werden.
Ich bin gerade dran die Lib zu optimieren und zu dokumentieren. Ich habe nur sehr wenig Zeit, deshalb wird esnoch eine Weile dauern bis was vorzeigbares raus kommt.
Viele Grüsse
Trilu
Moin unimatrix,
Ich sende Nachrichten an den Schalter selbst damit FHEM das auch mitbekommt. Generell gibt es da aber noch Probleme. Ich hab aktuell leider nicht so viel Zeit um mich drum zu kümmern. In ein paar Wochen vermutlich wieder.
Gruß
Jan
Hi Jab,
ja das hab ich inzwischen dann auch so verstanden. Ich habe diesen Teil durch senden an Broadcast ersetzt. Dann bekommt es FHEM genau so mit, und die Probleme sind weg. Ich teste das mal eine Weile, ob es noch zu Nebenwirkungen kommt.
Danke für die Hinweise wegen Perl und Dimmer. In der original-FW hat der Dimmer ja noch virtuelle Kanäle, die mit dem physikalischen verknüpft werden können. Alles ein wenig aufwändiger. Werde das erstmal mit dem Panstamp und einer LED machen bevor ich mich traue den Original-Dimmer zu zerflashen.
Das Zeitproblem ist mir klar. Ich mache das auch nur als "Ausgleich" von Arbeit und Familie...wie wohl die meisten hier. Wenn ich meiner Frau erkläre, dass ich in den Lichtschalter eine eigene Software einspiele, dann .... naja ihr kennt die Geschichte wohl...
Jo die Situation ist bei mir ähnlich. Mein Plan ist für solche Änderungen Unit Tests zu schreiben. Allerdings muss ich mich vorher um Hardware Abstraktion kümmern. Bisher nutze ich ja eine ältere Version dieser lib mit einigen Bugfixes und kleineren Änderungen.
Gruß
Jan
Servus zusammen,
ich nutze einen HM-LC-Sw4-Ba-PCB sketch und das funktioniert soweit. Allerdings schaltet sich der Ausgang mit konstanter Boshaftigkeit innerhalb 8 bis 9 sekunden immer wieder aus, nachdem er eingeschaltet wurde. Suche schon seit einigen Stunden, wahrscheinlich habe ich etwas übersehen. Hat diesen "Ausschalteffekt" jemand schon einmal fest gestellt? Übrigens tritt es auch auf, wenn ich on-for-timer setze. Auch wenn der Ausgang bereits schon wieder aus ist.
Monitor:
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur CMDs_pending
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur_Sw_03 set_on
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur CMDs_done
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur_Sw_03 level: 100
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur_Sw_03 pct: 100
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur_Sw_03 deviceMsg: on (to CUL_0)
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur_Sw_03 on
2014-07-15 21:05:50 CUL_HM Arduino_LC.SW4_flur_Sw_03 timedOn: off
2014-07-15 21:05:58 CUL_HM Arduino_LC.SW4_flur CMDs_done
2014-07-15 21:05:58 CUL_HM Arduino_LC.SW4_flur_Sw_03 level: 0
2014-07-15 21:05:58 CUL_HM Arduino_LC.SW4_flur_Sw_03 pct: 0
2014-07-15 21:05:58 CUL_HM Arduino_LC.SW4_flur_Sw_03 deviceMsg: off (to CUL_0)
2014-07-15 21:05:58 CUL_HM Arduino_LC.SW4_flur_Sw_03 off
2014-07-15 21:05:58 CUL_HM Arduino_LC.SW4_flur_Sw_03 timedOn: off
Raw
2014.07.15 21:05:28 4: CUL_send: CUL_0As 0A 0D 8002 F10065 000063 00
2014.07.15 21:05:50 5: CUL_0 sending As0E04A011F100650000630203C80000
2014.07.15 21:05:50 4: CUL_send: CUL_0As 0E 04 A011 F10065 000063 0203C80000
2014.07.15 21:05:50 5: CUL/RAW: /A0E048002000063F100650103C8000008
2014.07.15 21:05:50 4: CUL_Parse: CUL_0 A 0E 04 8002 000063 F10065 0103C8000008 -70
2014.07.15 21:05:50 5: CUL_0 dispatch A0E048002000063F100650103C80000::-70:CUL_0
2014.07.15 21:05:58 5: CUL/RAW: /A0E0EA410000063F10065060300000008
2014.07.15 21:05:58 4: CUL_Parse: CUL_0 A 0E 0E A410 000063 F10065 060300000008 -70
2014.07.15 21:05:58 5: CUL_0 dispatch A0E0EA410000063F100650603000000::-70:CUL_0
2014.07.15 21:05:58 5: CUL_0 sending As0A0E8002F1006500006300
2014.07.15 21:05:58 5: CUL 000063 dly:97ms
2014.07.15 21:05:58 4: CUL_send: CUL_0As 0A 0E 8002 F10065 000063 00
Kannst du mal bitte die list3 der kanäle auslesen und posten. Ich habe mehrere relay classes im einsatz und die schalten sich nicht aus... .
servus trilu,
die List3 ist nicht da, oder ich komme nicht ran.
Habe vorher das intKeyVisib auf "visib" gesetzt und ein getConfig, bzw. getRegRaw List3 ausgeführt. Ausser Liste0 ist aber nichts vorhanden.
RegL_00: 02:81 05:00 0A:F1 0B:00 0C:64 12:00 00:00
Ein "get CUL_HM_HM_LC_SW4_BA_PCB reg all" ergibt:
CUL_HM_HM_LC_SW4_BA_PCB type:switch -
list:peer register :value
0: intKeyVisib :visib
0: ledMode :off
0: lowBatLimitBA :0 V
0: pairCentral :0xF10065
ich habe zwar so ein Device nicht aber ich nehme mal stark an dass du nur das Device betrachtet hast. Die Peer-Listen sind aber in den einzeilen Kanälen. Nach dem getConfig auf das Device (schon von dir gemacht) müssten alle Listen in den einzelnen Kanälen ausgelesen und sichtbar sein.
ich weiß, in diesem Thread gibts mehrere Links, aber viele sind alt...hat gerade jemand auf die Schnelle einen Link für mich, wo ich jetzt ein zum Arduino Pro Mini 3,3 einen passenden CC1101 bekomme bzw. was man noch braucht um den da draufzulöten? Gibts das inzwischen als "Shield"? Ebay suggeriert das, aber die scheinen für 433 Mhz ausgelegt zu sein.
Wenn jemand die Infos hier postet mit aktuellen Links, würde ich auch die Wiki-Seite mit dieser Info versorgen
Am liebsten was mit "normaler" Versanddauer zumindest mal für 1 Stück, notfalls aber auch China
Danke!
hi unimatrix,
ich habe meine damals hier bestellt: http://www.aliexpress.com/item/25pcs-lot-CC1101-868MHz-wireless-module-1-2k-500-kbps-data-rate-Free-shipping/1104691912.html
dauert halt 4 wochen bis du sie hast, sind aber günstig :-)
falls du es schneller brauchst kann ich dir eine abtreten - kommst du aus münchen?
viele grüße
trilu
danke. wohne zwischen Freising und Landshut, der genaue Ort dürfte der Bundesnetzagentur bekannt sein (haha) aber bis wir das organisiert bekommen habe ich jetzt erstmal ein 5er Lot aus China bestellt, habe für die Wartezeit ja genug Projekte...
hi unimatrix,
die cc1101 habe ich auch von aliexpress, wie trilu.
arduinos von ebay: http://www.ebay.de/itm/1-x-Pro-Mini-Atmega328-3-3V-8M-Modul-ATmega128-Arduino-Kompatible-Nano-Neu-/301167442353?ssPageName=ADME:L:OC:DE:3160
dauert auch 3-4 Wochen.
Hallo!
Sorry, falls ich doof frage - aber was nehmt ihr für die Sende/Empfangsstation am FHEM-Server her? Habe eine Fritzbox mit FHEM drauf. Hätte jetzt vorgehabt einen
HomeMatic LAN Konfigurations-Adapter mit dem Fritzbox - Fhem Server zu verbinden.
Wie macht ihr das denn?
Ansonsten - Einfach geil das Projekt, echt!
Zitat von: unimatrix am 16 Juli 2014, 12:41:36
ich habe zwar so ein Device nicht aber ich nehme mal stark an dass du nur das Device betrachtet hast. Die Peer-Listen sind aber in den einzeilen Kanälen. Nach dem getConfig auf das Device (schon von dir gemacht) müssten alle Listen in den einzelnen Kanälen ausgelesen und sichtbar sein.
ja sollte im Kanal sein, du hast Recht. Ein
echter HM-LC-SW4-BA-PCB zeigt mir zB im vierten Kanal an:
RegL_03:self04
02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00 das "arduino SW4-BA-PCB" zeigt aber nichts an. auch nicht in den Kanälen.
Zitat von: thunder1902 am 16 Juli 2014, 16:42:11
Sorry, falls ich doof frage - aber was nehmt ihr für die Sende/Empfangsstation am FHEM-Server her?
Die Frage ist bestimmt nicht doof, aber ich verstehe sie nicht ;) - und nicht den Zusammenhang zu der Lib.
fhem läuft auf einer Fritzbox (bei vielen) - bei mir auf einem normalen Rechner, der irgendwo auf dem Dachboden steht und nebenher viele andere Funktionen hat (fileserver, Videorecorder, etc.)
der HMLAN ist (wie der Name schon sagt) ein Device, was man ans LAN anschließt. Die Position sollte hier auf die Funkabdeckung optimiert sein (LAN-Anschluss dort vorrausgesetzt).
Das ist aber alles unabhängig von der LIB. Zur Kommunikation mit Devices, die es von EQ3 so nicht gibt, muss einerseits Firmware basierend auf der LIB erstellt werden, andererseits ein entsprechendes Modul bzw. ein entsprechender Zusatz zum CUL_HM Modul für FHEM (mit den entsprechenden GErätedefinitionen, Kanälen, Registern, etc.)
VG in der Hoffnung, mit diesen allgemeinen Angaben ins Blaue zufällt deine Frage beantwortet zu haben :)
bei mir läuft fhem auf meinem NAS, zum entwickeln der lib nutze ich aber die original hm config software. damit funktioniert das pairen einfacher :-)
ach ja, für die kommunikation nutze ich zwei usb hm adapter. einer hängt am nas, einer am pc für die hm config soft.
ok. du bist der erste der findet dass man mit der HM Software gut pairen kann *G*
vermutlich - aber ich denke mir halt, wenn die lib mit original config soft läuft, dann gehts mit fhem allemal :-)
Ich habe gerade in meinem git den beginn einer neuen asksin hochgeladen. Bisher ist nur der anfang mit dem register handling gemacht. Ziel der neuen lib ist, das sie überschaubarer und leichter zu bedienen wird...
Doku folgt dann auch noch.
Ach ja, wenn jemand lust zum mitproggen hat, dann schalte ich ihn gerne im git frei.
Zitat von: trilu am 16 Juli 2014, 06:53:44
Kannst du mal bitte die list3 der kanäle auslesen und posten. Ich habe mehrere relay classes im einsatz und die schalten sich nicht aus... .
Hi trilu,
habe mal den Sw1-Ba-PCB aus dem git geflasht. Dort besteht das gleiche Problem, nach dem einschalten wird innerhalb von wenigen sekunden wieder ausgeschaltet. Allerdings nicht mit konstanter Boshaftigkeit wie bei meinem Sw4 Sketch. Im Schnitt jedes zweite mal, wird wieder ausgeschaltet. Dafür konnte ich die List3 auslesen:
RegL_03:1FA65C05
02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 82:00 83:00 84:00 85:00 86:00 87:00 88:00 89:00 8A:00 8B:00 8C:00 00:00
RegL_03:1FA65C06
02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:00 82:00 83:00 84:00 85:00 86:00 87:00 88:00 89:00 8A:00 8B:00 8C:00 00:00
Moin !
Zitat von: kuek am 15 Juli 2014, 22:43:17
Hat diesen "Ausschalteffekt" jemand schon einmal fest gestellt?
Ich hatte vor einiger Zeit mal einen Mini mit dem HM-LC-SW1-BA-PCB Sketch betankt und hatte ein ähnliches Verhalten. Wenn der
Mini neu gestartet wurde, war alles prima. Lief er schon einige Zeit (~ 1Tag), so wurde der Channel einige Sekunden nach dem
Einschalten auch direkt wieder abgeschaltet. Nach einem Neustart des Minis war alles wieder IO. Da ich noch einen echten
HM-LC-SW1-BA-PCB rumliegen hatte, habe ich dann kurzer Hand letzteren verbaut und das Problem nicht weiter verfolgt.
HW: China Arduino Mini + Funkmodul aus einem MAX Fensterkontakt
Gruß, Marc
Moin marc2,
danke für die Rückmeldung. Das bestätigt meinen Effekt... dass es an den China Arduino Mini liegt, kann ich mir fast nicht denken. Suche immernoch den Software bug.
Viele Grüße,
kuek
bei eurem Ausschalt-Verhalten - hattet ihr da den Kanal über FHEM / die Zentrale mit "set <kanal> on" eingeschaltet oder über einen Peer? (Taster, etc.)
Einfach mit "set .... on"
hab mir den relay sketch noch mal angeschaut und einige korrekturen vorgenommen. kamen durch die anpassung vom thermometer sketch.
hol dir mal den aktuellen sketch und teste noch mal...
Zitat von: trilu am 20 Juli 2014, 17:30:02
hab mir den relay sketch noch mal angeschaut und einige korrekturen vorgenommen. kamen durch die anpassung vom thermometer sketch.
hol dir mal den aktuellen sketch und teste noch mal...
hi trilu,
danke, es schien erst zu gehen. Allerdings wohl nicht immer.
Es liegt reproduzierbar am "statusRequest". Sobald das device an ist und fhem einen statusRequest sendet, oder ich manuell einen sende schaltet der kanal aus. Kann das sein?
bei "statusRequest" wird im event monitor folgendes sichtbar (egal ob der status wirklich "on" oder "off" ist):
CUL_HM_HM_LC_SW1_BA_PCB_0000 level: 0
CUL_HM_HM_LC_SW1_BA_PCB_0000 pct: 0
CUL_HM_HM_LC_SW1_BA_PCB_0000 deviceMsg: off (to CUL_0)
CUL_HM_HM_LC_SW1_BA_PCB_0000 off
CUL_HM_HM_LC_SW1_BA_PCB_0000 timedOn: off
CUL_HM_HM_LC_SW1_BA_PCB_0000 battery: ok
hmm - kann ich nicht nachvollziehen...
on:
-> 0E 71 B0 11 63 19 63 00 00 63 02 01 C8 00 00 (l:15)(6509826)
<- 0E 71 80 02 00 00 63 63 19 63 01 01 C8 00 00 (l:15)(6509834)
<- 0E 09 A4 10 00 00 63 63 19 63 06 01 C8 00 00 (l:15)(6513549)
-> 0A 09 80 02 63 19 63 00 00 63 00 (l:11)(6513690)
status request
-> 0B 72 B0 01 63 19 63 00 00 63 01 0E (l:12)(6575161)
<- 0E 72 A4 10 00 00 63 63 19 63 06 01 C8 00 00 (l:15)(6575169)
-> 0A 72 80 02 63 19 63 00 00 63 00 (l:11)(6575314)
off
-> 0E 73 B0 11 63 19 63 00 00 63 02 01 00 00 00 (l:15)(6621980)
<- 0E 73 80 02 00 00 63 63 19 63 01 01 00 00 00 (l:15)(6621990)
<- 0E 0A A4 10 00 00 63 63 19 63 06 01 00 00 00 (l:15)(6624434)
-> 0A 0A 80 02 63 19 63 00 00 63 00 (l:11)(6624577)
status request
-> 0B 74 B0 01 63 19 63 00 00 63 01 0E (l:12)(6669113)
<- 0E 74 A4 10 00 00 63 63 19 63 06 01 00 00 00 (l:15)(6669121)
-> 0A 74 80 02 63 19 63 00 00 63 00 (l:11)(6669264)
um ehrlich zu sein, ich sehe nichts auffälliges...
ja das sieht bei dir gut aus. Bei mir schaltet er sofort wieder aus, siehe hier:
erster versuch "on"
-> 0E 25 B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 25 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 07 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 07 80 02 F1 00 64 00 00 63 00 (l:11)
(die payload ist dann 01 00 00 00, nicht 01 C8 00 00, wie sie sein sollte)
zweiter versuch "on":
-> 0E 28 B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 28 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
direkt gefolgt von "status request"
-> 0B 29 B0 01 F1 00 64 00 00 63 01 0E (l:12)
<- 0E 29 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 29 80 02 F1 00 64 00 00 63 00 (l:11)
dritter versuch "on"
-> 0E 2A B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 2A 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 09 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 09 80 02 F1 00 64 00 00 63 00 (l:11)
Habe die gesamte lib getauscht und den aktuellen status von trilu genommen. Damit geht es prinzipiell.
-> 0E 1E B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 1E 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 05 A4 10 00 00 63 F1 00 64 06 01 C8 00 00 (l:15)
-> 0A 05 80 02 F1 00 64 00 00 63 00 (l:11)
Allerdings funktioniert es nur wenige Minuten, danach schaltet der arduino wieder konstant aus, wie gehabt. Nach einem reset geht es dann wieder.
Werde mal neue arduino hardware testen, vielleicht liegt es doch an der China version!?
Grüße,
kuek
Habe einen anderen arduino getestet. Hatte leider nur noch China versionen hier liegen. Der zeigt das gleiche Verhalten.
Hat jemand eine günstige Arduino Mini Pro (3v3) Quelle, wo der Arduino mit dieser Lib nachweislich funktioniert?
ich galube nicht das es am arduino liegt. mit welcher hw versuchst du es - arduino, funkmodul, relais mit transistor?
@trilu fehlt nach deinem Update in dem Sketch (register.h) von heute jetzt nicht die HMID gänzlich? Dachte die gehört jetzt in devParam[].
Zitat von: trilu am 20 Juli 2014, 21:37:30
ich galube nicht das es am arduino liegt. mit welcher hw versuchst du es - arduino, funkmodul, relais mit transistor?
arduino pro mini 3.3V, TRX868-TI Funkmodul.
Am Ausgang war erst einmal eine low current LED über Vorwiderstand angeschlossen.
Mhh, han die selbe test config. Daran kanns nicht liegen. Gerade noch mal getestet, mein testdevice schaltet immer noch.
Poste doch mal den output der seriellen schnittstelle.
@unimatrix
Stimmt, die hmid liegt jetzt fix im flash, dirk hat sie dahin verlagert, damit er sie per script im .hex file verändern kann. Änderung ist irgendwo im temperatur sensor sketch beschrieben...
Zitat von: trilu am 20 Juli 2014, 21:58:43
Mhh, han die selbe test config. Daran kanns nicht liegen. Gerade noch mal getestet, mein testdevice schaltet immer noch.
Poste doch mal den output der seriellen schnittstelle.
pairing
<- 1A 03 A2 00 00 00 63 63 19 63 15 00 6C 50 53 30 30 30 30 30 30 30 32 10 41 01 00 (l:27)
-> 10 01 B0 01 F1 00 64 00 00 63 00 05 00 00 00 00 00 (l:17)
<- 0A 01 80 02 00 00 63 F1 00 64 00 (l:11)
-> 13 02 A0 01 F1 00 64 00 00 63 00 08 02 01 0A F1 0B 00 0C 64 (l:20)
<- 0A 02 80 02 00 00 63 F1 00 64 00 (l:11)
-> 0B 03 A0 01 F1 00 64 00 00 63 00 06 (l:12)
<- 0A 03 80 02 00 00 63 F1 00 64 00 (l:11)
-> 10 04 A0 01 F1 00 64 00 00 63 00 04 00 00 00 00 00 (l:17)
<- 18 04 A0 10 00 00 63 F1 00 64 02 02 01 05 00 0A F1 0B 00 0C 64 12 FF 00 00 (l:25)
-> 0A 04 80 02 F1 00 64 00 00 63 00 (l:11)
-> 10 05 A0 01 F1 00 64 00 00 63 01 04 00 00 00 00 01 (l:17)
<- 0E 05 A0 10 00 00 63 F1 00 64 02 08 FF 00 00 (l:15)
-> 0A 05 80 02 F1 00 64 00 00 63 00 (l:11)
-> 0B 06 A0 01 F1 00 64 00 00 63 01 03 (l:12)
<- 16 06 A0 10 00 00 63 F1 00 64 01 1F A6 5C 06 1F A6 5C 05 00 00 00 00 (l:23)
-> 0A 06 80 02 F1 00 64 00 00 63 00 (l:11)
-> 10 07 A0 01 F1 00 64 00 00 63 01 04 1F A6 5C 05 03 (l:17)
<- 1A 07 A0 10 00 00 63 F1 00 64 02 02 FF 03 FF 04 FF 05 FF 06 FF 07 FF 08 FF 09 FF (l:27)
-> 0A 07 80 02 F1 00 64 00 00 63 00 (l:11)
<- 1A 08 A0 10 00 00 63 F1 00 64 02 0A FF 0B FF 0C FF 82 FF 83 FF 84 FF 85 FF 86 FF (l:27)
-> 0A 08 80 02 F1 00 64 00 00 63 00 (l:11)
<- 18 09 A0 10 00 00 63 F1 00 64 02 87 FF 88 FF 89 FF 8A FF 8B FF 8C FF 00 00 (l:25)
-> 0A 09 80 02 F1 00 64 00 00 63 00 (l:11)
-> 10 08 A0 01 F1 00 64 00 00 63 01 04 1F A6 5C 06 03 (l:17)
<- 1A 08 A0 10 00 00 63 F1 00 64 02 02 FF 03 FF 04 FF 05 FF 06 FF 07 FF 08 FF 09 FF (l:27)
-> 0A 08 80 02 F1 00 64 00 00 63 00 (l:11)
<- 1A 09 A0 10 00 00 63 F1 00 64 02 0A FF 0B FF 0C FF 82 FF 83 FF 84 FF 85 FF 86 FF (l:27)
-> 0A 09 80 02 F1 00 64 00 00 63 00 (l:11)
<- 18 0A A0 10 00 00 63 F1 00 64 02 87 FF 88 FF 89 FF 8A FF 8B FF 8C FF 00 00 (l:25)
-> 0A 0A 80 02 F1 00 64 00 00 63 00 (l:11)status request
-> 0B 09 B0 01 F1 00 64 00 00 63 01 0E (l:12)
<- 0E 09 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 09 80 02 F1 00 64 00 00 63 00 (l:11)set on
-> 0E 0A B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 0A 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 04 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 04 80 02 F1 00 64 00 00 63 00 (l:11)da war der Fehler schon... habe dann einen reset gemacht
Starting sketch...
pair: F1 00 64
<- 0E 00 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
<- 0E 00 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 00 80 02 F1 00 64 00 00 63 00 (l:11)set on
-> 0E 0D B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 0D 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 01 A4 10 00 00 63 F1 00 64 06 01 C8 00 00 (l:15)
-> 0A 01 80 02 F1 00 64 00 00 63 00 (l:11)jetzt hat er das "on" angenommen
status request
-> 0B 0E B0 01 F1 00 64 00 00 63 01 0E (l:12)
<- 0E 0E A4 10 00 00 63 F1 00 64 06 01 C8 00 00 (l:15)
-> 0A 0E 80 02 F1 00 64 00 00 63 00 (l:11)noch einmal status request
-> 0B 0F B0 01 F1 00 64 00 00 63 01 0E (l:12)
<- 0E 0F A4 10 00 00 63 F1 00 64 06 01 C8 00 00 (l:15)
-> 0A 0F 80 02 F1 00 64 00 00 63 00 (l:11)set off
-> 0E 10 B0 11 F1 00 64 00 00 63 02 01 00 00 00 (l:15)
<- 0E 10 80 02 00 00 63 F1 00 64 01 01 00 00 00 (l:15)
<- 0E 02 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
-> 0A 02 80 02 F1 00 64 00 00 63 00 (l:11)set on
-> 0E 11 B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 11 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 03 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)
<- 0E 03 A4 10 00 00 63 F1 00 64 06 01 00 00 00 (l:15)da ist der fehler wieder.
Super Arbeit, echt gut gemacht.
Gibt es auch schon eine Nachbildung der Rollladenaktoren?
Also HM-LC-BI1PBU-FM oder HM-LC-Bl1-FM?
Nein, bisher noch nicht. Beim alten Aktor (nicht-PBU) hat glaub ich auch noch niemand "nachgeschaut" was da überhaupt für ein uC drin ist und ob man halbwegs einfach an den ISP Port rankommt.
Hi Unimatrix,
das ist ja schade.
Hab ich es richtig verstanden, dass Ihr die Programme aus dem µC auslest?
Übernehmt Ihr dann die Firmware komplett?
Ich bin gerade dabei für meine Velux Rolläden einen Platine zu entwerfen.
Da wäre es super den µC gleich mit drauf zu packen.
Eventuell hol ich mir dann die Bausätze.
Edit:
Hier gibts bilder. http://s6z.de/cms/index.php/homeautomation/homematic/36-schaltaktor-hm-lc-sw1pbu-fm
Denke es ist ein ATMEGA 644A
Gruß Robert
man kann die programme nicht aus dem uC auslesen, sind dagegen geschützt. jan hat beim wandschalter die lib angepasst, so dass man die original firmware überschreiben kann.
prinzipiell kann man den relay sketch als rolladen aktor missbrauchen. das was halt derzeit nicht drin ist, ist das absichern gegen zu schnelles schalten der rolladenmotoren. ich habe mir aber so elektrische fensteröffner gekauft und brauche auch eine steuerung - werde mich also in absehbarer zeit daran setzen um einen rolladensteuerung zu basteln :-)
Zitat von: trilu am 20 Juli 2014, 21:58:43
@unimatrix
Stimmt, die hmid liegt jetzt fix im flash, dirk hat sie dahin verlagert, damit er sie per script im .hex file verändern kann. Änderung ist irgendwo im temperatur sensor sketch beschrieben...
Ja, das habe ich gefunden. Allerdings ersetzt er ja dort die Default-ID. Aber damit die überhaupt erstmal im Flash ist, und bei der Ersetzung per "sed" gefunden wird, beinhaltet ja auch beim Temperatursensor die register.h noch folgendes. Oder was übersehe ich. Interessiere mich nur deswegen dafür, weil ich mich bei der Anpassung des Schalters natürlich an den "Standard" halten möchte.
Du sagtest, du hast noch weitere Änderungen an der Lib in der Queue? Werden das größere Umstrukturierungen, also macht es jetzt Sinn, den Schalter an den aktuellen GIT-Stand anzupassen?
const uint8_t devParam[] PROGMEM = {
0x10, // The firmware version, 1 byte
0xF1, 0x01, // The model-ID 0xF1 0x01 = DIY (HB-UW-Sen-THPL-I)
// 0xF1, 0x02, // The model-ID 0xF1 0x01 = DIY (HB-UW-Sen-THPL-O)
'H','B','0','D','e','f','a','u','l','t', // The serial 10 bytes, needed for pairing (Default for flash tool)
0x70, // Frame type 0x70 = WEATHER_EVENT
0x03, 0x01, 0x00, // Device Info, 3 byte, describes device, not completely clear yet. includes amount of channels
0xAB, 0xCD, 0xEF // The HM-ID 3 bytes, needed for pairing (Default for flash tool)
};
so wirklich tief bin ich nicht in den änderungen von dirk drin. hab sie einfach übernommen und festgestellt, dass der rest nicht mehr funzt. hätte vielleicht vorher schauen soll was bei einem merge alles verbogen ist :-)
eigentlich lohnt es sich nicht mehr, den hm-schalter an das aktuelle asksin anzupassen. bin gerade dabei ein komplettes rework zu machen. möchte mehr modularisieren und einige fehler ausmerzen. Siehe Anhang Seite 35
sehr interessant!
Ich werde trotzdem weiter anpassen und betrachte es als Lerneffekt für mich. TODO ist ja auch noch das Dimmer-Profil. Da ich jetzt den Schaltplan habe werde ich mir einen Dimmer "zerflashen" und anfangen da Low-Level Übungen mit zu machen. Es wird also so schnell nicht langweilig.
Wenn du Hilfe benötigst, lass es mich wissen.
Hallo kuek
Der 4fach Aktor HM_LC_SW2_BA_PCB funktioniert. Hat aber schon mal jemand versucht 2 Geräte in einem Arduino zu realisieren ? 4fach Aktor + 3 Schalter (HM-SCI-3-FM) ?
Gruss Peter
Zitat von: kuek am 01 Juli 2014, 00:10:52
Hallo Peter,
falls Du noch interesse hast. Der sketch ist im Anhang. Nutzt jedoch eine alte relay.h und .cpp die ins den lib ordner muss.
Grüße, kuek
für so etwas sollte man besser ein neues Geräte erfinden, was eben 7 Kanäle hat. 4 Aktoren und 3 Remotes.
Da es das dann genau so in FHEM noch nicht gibt, muss das dort ebenfalls definiert werden, aber das ist machbar.
Zwei Geräteinstanzen auf einem Controller wären deutlich komplexer und man hat sich aus guten Grund von dieser Idee verabschiedet.
Ich habe mir für meine Fußbodenheizungssteuerung (Panstamp-Shield mit 8 Relais) auch einen 8-Kanal-Aktor definiert. Mit der Lib geht das ja nach Baukastensystem. Jetzt muss der Panstamp nur noch geliefert werden ;)
Hallo unimax
Wie funktioniert das mit dem Baukastensystem. Hab ich das was überlesen ?
PS: Wenn man einen 8fach Aktor definieren kann, dann sollte auch ein 4fach Schalter + 4fach Aktor möglich sein ;D
Gruss Peter
Zitat von: unimatrix am 22 Juli 2014, 20:07:25
Ich habe mir für meine Fußbodenheizungssteuerung (Panstamp-Shield mit 8 Relais) auch einen 8-Kanal-Aktor definiert. Mit der Lib geht das ja nach Baukastensystem. Jetzt muss der Panstamp nur noch geliefert werden ;)
Baukasten ist vll. übertrieben. Natürlich muss man sich mit der Lib etwas beschäftigen. Mit dem Perl-Script legt man sich die passende register.h für die gewünschte Anzahl von Kanälen an und dann kommen noch ein paar Zeilen in den Sketch und dann ist die Firmware eigentlich schon fertig.
Was dann noch gemacht werden muss, ist auf der FHEM Seite das entsprechende Device zu implementieren. Das geht aber aber auch recht übersichtlich. man braucht ja nix völlig neues. Für ein Device mit Buttons und Relais kann man sich an der Custom-Firmware des Unterputz-Aktors orientieren. Der hat 2 Buttons und 2 Switches - muss man nur skalieren.
@Trilu: ich weß du hast wenig Zeit (ich kenne das von mir) und ich weiß nicht, wie weit deine Änderungen schon fortgeschritten sind.
Ich habe inzwischen angefangen einen Dimmer-Prototypen zu entwerfen. Den habe ich zunächst auf den Schalter gespielt und dabei als "Frontend" die LED per Soft-PWM gedimmt. Damit kann ich jetzt Rampen fahren usw.
Es wurde dann sehr schnell klar, dass vieles aus der Relay-Klasse in der Dimmer-Klasse fast gleich sein wird. Die Dimmer-Klasse kann eben noch einiges mehr.
Daher denke ich, es sollte eine Elternklasse "Aktor" erstellt werden, und dann sollten die Relay und Dimmerklassen nur Spezialisierungen sein.
Ich erwähne das hier nur, weil es ja womöglich für dein aktuelles Refactoring schon relevant sein könnte. Wenn wir den Schritt dann mal haben, dann fehlen auch noch ein paar Leistungsmerkmale in der Relay-Klasse, z.B. PowerOn Verhalten usw.
Außerdem muss irgendwie die Option des externen EEproms rein. Als konfigurierbare Option eben. Bei dem Dimmer wird man es in jedem Fall brauchen, das Registerset ist einfach sehr umfangreich. Da kann man die 4KByte gut brauchen.
@jau, zeit um wirklich zu proggen ist mangelware....
Um ehrlich zu sein wäre es mir lieber die Aktor Klassen getrennt zu halten. Mein Ziel ist es, auch die Klassen per Konfigurator einzubinden. Da würde es helfen wenn sie möglichst eigenständig sind. In der Relay Klasse fehlt auch die Behandlung von Sensoren, also Alles was Message 41 ist.
Das mit den externen EEproms wird in der neuen Lib einfacher werden, die Verbindung zur HW kommt in eine HAL, dann müssen nur die EEprom schreib und lese Routine aufgebohrt werden.
Wenn du die Dimmer Klasse einigermassen hast wäre es nett wenn du sie mir zuschicken könntest. Würde sie gerne mal testen und mit in die bisherige Lib packen.
Viele Grüße
Horst
Ich wollte natürlich die Klassen trennen, aber sie könnten Dinge die gleich sind von einer Aktor-Klasse erben. Um doppelten Code zu sparen. Aber es ist deine Lib, es war nur eine Anregung.
Ich mache die Dimmerklasse erstmal so fertig. Läuft als Test auch auf einem Arduino Pro Mini mit der roten LED. Kann ich aber hier nicht komplett testen, weil ich dafür noch keine Funkmodule habe.
Schicke dir das Zeug, sobald es irgendwie läuft. Leider kommt jetzt, wo ich gerade so gut drin bin, eine Zeit von ein paar Tagen mit sehr wenig Zeit dafür :(
Zitat von: trilu am 21 Juli 2014, 17:29:03
so wirklich tief bin ich nicht in den änderungen von dirk drin. hab sie einfach übernommen und festgestellt, dass der rest nicht mehr funzt. hätte vielleicht vorher schauen soll was bei einem merge alles verbogen ist :-)
Was war denn da genau das Problem?
die Änderungen sollten eigentlich alle kompatibel gewesen sein.
Hallo unimatrix und trilu
Ich habe mir auf Seite 32 nochmal die Infos zum Paket destillRegs durchgelesen:
Zitat von: trilu am 29 Dezember 2013, 15:24:21
Ich habe jetzt mal einen GIT für die Library erstellt, derzeit ist erst mal nur das versprochene Paket destillRegs hochgeladen.
destillRegs beruht auf der Idee von martin876 hier im Forum, ist ein Perl Script um einen großen Teil der Register.h automatisch zu erstellen.
Das Paket besteht im Wesentlichen aus 3 Teilen:
destillRegs, das Perl Script
devDefinition.pm, um die eigentliche Funktionalität des Devices zu konfigurieren
RegConfig.pm, enthält alle derzeit bekannten Variablen der HM Devices
Alle 3 Files müssen in einem Directory sein, Aufruf ist dann einfach "perl destillRegs.pl"
Was dann auf der Konsole raus kommt, muss in die Register.h kopiert werden.
Verstandene Schritte:
a) Alle 3 Dateien werden in den FHEM-Ordner kopiert
a) Man läßt sich die Register per "get DEVISE regList" anzeigen
b) Wie nutzt man den jetzt der Input für das File "devDefinition.pm" ?
c) Startet ihr die "perl destillRegs.pl" aus FHEH heraus ?
d) Dann muss noch der Header ergänzt werden und das Ergebnis in eine Register.h kopiert werden ?
Zitat von: unimatrix am 23 Juli 2014, 13:45:39
Baukasten ist vll. übertrieben. Natürlich muss man sich mit der Lib etwas beschäftigen. Mit dem Perl-Script legt man sich die passende register.h für die gewünschte Anzahl von Kanälen an und dann kommen noch ein paar Zeilen in den Sketch und dann ist die Firmware eigentlich schon fertig.
Was dann noch gemacht werden muss, ist auf der FHEM Seite das entsprechende Device zu implementieren. Das geht aber aber auch recht übersichtlich. man braucht ja nix völlig neues. Für ein Device mit Buttons und Relais kann man sich an der Custom-Firmware des Unterputz-Aktors orientieren. Der hat 2 Buttons und 2 Switches - muss man nur skalieren.
Gruss Peter
Zitat von: Dirk am 25 Juli 2014, 00:12:18
Was war denn da genau das Problem?
die Änderungen sollten eigentlich alle kompatibel gewesen sein.
glaube da war gar keins. Ich hatte nur angemerkt, dass man in der register.h ja die Default HMID drin lassen muss. Denn diese ersetzt ja dann dein Script per SED. Ich glaube es war ein Mißverständnis. Alles gut.
@PeterS: Die ausgabe von RegList kannst du nicht direkt verwenden. Es ist nur eine Vorlage, nach der du dann die devDefinition.pm anpassen kannst. Dort kommen die Register einfach in die entsprechenden Hashes.
Das Perl-Script hat mit FHEM nichts zu tun. Es ist nur ein Werkzeug zur Erzeugung der register.h mit den entsprechenden Slices, Eeprom-Adressen usw. Das wäre sonst viel Handarbeit.
@unimatrix: Danke für die Infos
@trilu:
- Wäre eine Versionsnummer für die Library nicht sinnvoll?
- Für wann ist die neue Version geplant?
Mit meinem Projekt (4 digitale Eingänge / 4 digitale Ausgänge) komme ich leider nicht richtig voran.
Könnte mir jemand die Register.h dafür erstellen.
Besser wäre natürlich noch 6 digitale Eingänge und 6 digitale Ausgänge. Beim Arduino mini und Panstamp kann ja noch die analogen Eingänge als digitale verwenden :)
Gruss Peter
Hallo Zusammen,
wie versprochen habe ich angefangen mit der neuen Library. Zu finden ist sie hier: https://github.com/trilu2000/NewAskSin (https://github.com/trilu2000/NewAskSin)
Ist aber erst der Anfang - ich habe mit dem Datenbankmodul begonnen. Es enthält jetzt auch eine Testroutine, die alle wesentlichen
Funktionen testet. Die Hardwareanbindung ist in einen Hardware Abstraction Layer ausgegliedert.
Die Registerdefinition in der register.h ist auch komplett neu, sowie die Behandlung der HM Id und Serial.
Das ganze folgt jetzt diesem Aufbau:
(http://forum.fhem.de/index.php?action=dlattach;topic=14140.0;attach=17576)
Viele Grüße
Horst
@PeterS - Über Versionsnummern habe ich mir keine Gedanken gemacht, ich dachte dafür gibt es den GIT?
Nachdem ich das nicht professionell mache und immer weiter progge wenn ich Zeit habe, kann ich dir leider nicht
sagen wann du mit der neuen Version rechnen kannst.
Hallo trilu
Die Versionsnummer sollte nur eine Anregung sein, damit man sich auch in Forenbeiträgen darauf beziehen kann ;) Bsp: Ist in Version X.YY gefixt :-)
Es gibt nun eine Homematic-Komponente HM-MOD-Re-8 mit 8-Ausgängen: http://www.elv.de/homematic-8-kanal-empfangsmodul.html
Könnte jemand diese in eine Register.h pressen, sobald diese in der HMConfig.pm aufgenommen wurden ?
Gruss Peter
Hallo Peter,
der neue Bausatz wird ja incl. EQ-3 Firmware kommen. Ich gehe davon aus, dass er 8 Kanäle haben wird und die internen 8 Taster nicht als eigene Kanäle zur Verfügung stehen werden sondern nur intern als Kanaltaster nutzbar sind. Das gleiche wie bei den Aktoren.
Damit dieser Bausatz in FHEM funtkioniert, muss er in HMConfig eingebaut werden. Das sollte nicht allzu schwierig sein.
Eine Register.h benötigst du aber nur, wenn die diese Eq-3 Firmware durch eine CustomFW ersetzen willst (z.B. um auch die internen Taster zu nutzen) - das scheint mir hierbei aber nicht das allerdringenste zu sein. Es gibt ja genug Projekte. Mit einer EQ3-FW für einen 8-Kanalaktor könnte ich gut leben...
Lustigerweise habe ich mir gerade am Wochenende mein Panstamp 12-Kanal Output Modul (8 Relais, 4 x 0-10V )zusammengebaut und die AskSin Lib darauf geflasht mit einem 8-Kanal Device. Was allerdings in der jetzigen Version der Lib ziemlich speichereng wird da vieles im SRAM behalten wird. Ich werde das für die Fußbodenheizungssteuerung einsetzen. Funktioniert noch nicht so gut, liegt wohl an meiner selbstgebauten Drahtantenne...kann empfangen aber nicht senden...
Übrigens eine Register.h für einen 8-Kanal Aktor würde ungefähr so aussehen. Wenn man da mehrere Peers braucht gibts aber EEProm Platzprobleme.
#include <AskSinMain.h>
#define SER_DBG
const uint8_t devParam[] PROGMEM = {
0x11, // The firmware version, 1 byte
0xF1, 0x01, // model ID, describes HM hardware. we should use high values due to HM starts from 0
'P','X','0','0','0','0','0','0','0','1', // The serial 10 bytes, needed for pairing (Default for flash tool)
0x10, // Subtype ??
0x41, 0x01, 0x00, // Device Info, 3 byte, describes device, not completely clear yet. includes amount of channels
0xFF, 0xF0, 0x01 // The HM-ID 3 bytes, needed for pairing (Default for flash tool)
};
HM::s_devParm dParm = {
5, // send retries, 1 byte, how often a string should be send out until we get an answer
700, // send timeout, 2 byte, time out for ACK handling
devParam // pointer to devParam, see above
};
HM::s_modtable modTbl[] = {
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
}; // 136 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
0x02,0x05,0x0a,0x0b,0x0c,0x12,
0x08,
0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
// 0x02,0x05,0x0a,0x0b,0x0c,0x12,
uint8_t :7; // l:0, s:7
uint8_t intKeyVisib :1; // 0x02, s:7, e:8
uint8_t :6; // l:0, s:6
uint8_t ledMode :2; // 0x05, s:6, e:8
uint8_t pairCentral[3]; // 0x0a, s:0, e:0
uint8_t lowBatLimitBA; // 0x12, s:0, e:0
};
struct s_regAktorL1 {
// 0x08,
uint8_t sign :1; // 0x08, s:0, e:1
uint8_t :7; //
};
struct s_regAktorL3 {
// 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
uint8_t shCtDlyOn :4; // 0x02, s:0, e:4
uint8_t shCtDlyOff :4; // 0x02, s:4, e:8
uint8_t shCtOn :4; // 0x03, s:0, e:4
uint8_t shCtOff :4; // 0x03, s:4, e:8
uint8_t shCtValLo; // 0x04, s:0, e:0
uint8_t shCtValHi; // 0x05, s:0, e:0
uint8_t shOnDly; // 0x06, s:0, e:0
uint8_t shOnTime; // 0x07, s:0, e:0
uint8_t shOffDly; // 0x08, s:0, e:0
uint8_t shOffTime; // 0x09, s:0, e:0
uint8_t shActionType :2; // 0x0a, s:0, e:2
uint8_t :4; //
uint8_t shOffTimeMode :1; // 0x0a, s:6, e:7
uint8_t shOnTimeMode :1; // 0x0a, s:7, e:8
uint8_t shSwJtOn :4; // 0x0b, s:0, e:4
uint8_t shSwJtOff :4; // 0x0b, s:4, e:8
uint8_t shSwJtDlyOn :4; // 0x0c, s:0, e:4
uint8_t shSwJtDlyOff :4; // 0x0c, s:4, e:8
uint8_t lgCtDlyOn :4; // 0x82, s:0, e:4
uint8_t lgCtDlyOff :4; // 0x82, s:4, e:8
uint8_t lgCtOn :4; // 0x83, s:0, e:4
uint8_t lgCtOff :4; // 0x83, s:4, e:8
uint8_t lgCtValLo; // 0x84, s:0, e:0
uint8_t lgCtValHi; // 0x85, s:0, e:0
uint8_t lgOnDly; // 0x86, s:0, e:0
uint8_t lgOnTime; // 0x87, s:0, e:0
uint8_t lgOffDly; // 0x88, s:0, e:0
uint8_t lgOffTime; // 0x89, s:0, e:0
uint8_t lgActionType :2; // 0x8a, s:0, e:2
uint8_t :3; //
uint8_t lgMultiExec :1; // 0x8a, s:5, e:6
uint8_t lgOffTimeMode :1; // 0x8a, s:6, e:7
uint8_t lgOnTimeMode :1; // 0x8a, s:7, e:8
uint8_t lgSwJtOn :4; // 0x8b, s:0, e:4
uint8_t lgSwJtOff :4; // 0x8b, s:4, e:8
uint8_t lgSwJtDlyOn :4; // 0x8c, s:0, e:4
uint8_t lgSwJtDlyOff :4; // 0x8c, s:4, e:8
};
struct s_regDev {
s_regDevL0 l0;
};
struct s_regAktor {
s_regAktorL1 l1;
s_regAktorL3 l3;
};
struct s_regs {
s_regDev ch0;
s_regAktor ch1;
s_regAktor ch2;
s_regAktor ch3;
s_regAktor ch4;
s_regAktor ch5;
s_regAktor ch6;
s_regAktor ch7;
s_regAktor ch8;
} regs; // 366 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel device list table --------------------------------------------------------------------------------------------
s_cnlDefType cnlDefType[] PROGMEM = {
// cnl, lst, pMax, sIdx, sLen, pAddr, pPeer, *pRegs; // pointer to regs structure
{0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)®s.ch0.l0},
{1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)®s.ch1.l1},
{1, 3, 2, 0x07, 22, 0x0007, 0x0000, (void*)®s.ch1.l3},
{2, 1, 0, 0x06, 1, 0x0033, 0x0000, (void*)®s.ch2.l1},
{2, 3, 2, 0x07, 22, 0x0034, 0x0008, (void*)®s.ch2.l3},
{3, 1, 0, 0x06, 1, 0x0060, 0x0000, (void*)®s.ch3.l1},
{3, 3, 2, 0x07, 22, 0x0061, 0x0010, (void*)®s.ch3.l3},
{4, 1, 0, 0x06, 1, 0x008d, 0x0000, (void*)®s.ch4.l1},
{4, 3, 2, 0x07, 22, 0x008e, 0x0018, (void*)®s.ch4.l3},
{5, 1, 0, 0x06, 1, 0x00ba, 0x0000, (void*)®s.ch5.l1},
{5, 3, 2, 0x07, 22, 0x00bb, 0x0020, (void*)®s.ch5.l3},
{6, 1, 0, 0x06, 1, 0x00e7, 0x0000, (void*)®s.ch6.l1},
{6, 3, 2, 0x07, 22, 0x00e8, 0x0028, (void*)®s.ch6.l3},
{7, 1, 0, 0x06, 1, 0x0114, 0x0000, (void*)®s.ch7.l1},
{7, 3, 2, 0x07, 22, 0x0115, 0x0030, (void*)®s.ch7.l3},
{8, 1, 0, 0x06, 1, 0x0141, 0x0000, (void*)®s.ch8.l1},
{8, 3, 2, 0x07, 22, 0x0142, 0x0038, (void*)®s.ch8.l3},
}; // 187 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
HM::s_devDef dDef = {
8, 17, sliceStr, cnlDefType,
}; // 6 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- eeprom definition ----------------------------------------------------------------------------------------------------
// define start address and size in eeprom for magicNumber, peerDB, regsDB, userSpace
HM::s_eeprom ee[] = {
{0x0000, 0x0002, 0x0042, 0x01b0,},
{0x0002, 0x0040, 0x016e, 0x0000,},
}; // 16 byte
//- -----------------------------------------------------------------------------------------------------------------------
// - defaults definitions -------------------------------------------------------------------------------------------------
const uint8_t regs01[] PROGMEM = {0x00,0x00,0x00,0x00,0x00};
//const uint8_t regs02[] PROGMEM = {0xff,0xff,0xff};
const uint8_t regs03[] PROGMEM = {0x1f,0xa6,0x5c,0x06};
const uint8_t regs04[] PROGMEM = {0x1f,0xa6,0x5c,0x05};
//const uint8_t regs05[] PROGMEM = {0x12,0x02,0x03,0x04};
//const uint8_t regs06[] PROGMEM = {0x13,0x02,0x03,0x04};
//const uint8_t regs07[] PROGMEM = {0x13,0x02,0x03,0x05};
//const uint8_t regs08[] PROGMEM = {0x15,0x02,0x03,0x04};
//const uint8_t regs09[] PROGMEM = {0x20,0x02,0x03,0x04,0x00,0x00,0x00,0x00,0x22,0x02,0x03,0x04,0x00,0x00,0x00,0x00,0x24,0x02,0x03,0x04,0x25,0x02,0x03,0x04};
//const uint8_t regs10[] PROGMEM = {0x30,0x02,0x03,0x04,0x31,0x02,0x03,0x04,0x32,0x02,0x03,0x04,0x33,0x02,0x03,0x04,0x34,0x02,0x03,0x04,0x35,0x02,0x03,0x04};
//const uint8_t regs11[] PROGMEM = {0x40,0x02,0x03,0x04,0x41,0x02,0x03,0x04,0x42,0x02,0x03,0x04,0x43,0x02,0x03,0x04,0x44,0x02,0x03,0x04,0x45,0x02,0x03,0x04};
//const uint8_t regs12[] PROGMEM = {0x50,0x02,0x03,0x04,0x51,0x02,0x03,0x04,0x52,0x02,0x03,0x04,0x53,0x02,0x03,0x04,0x54,0x02,0x03,0x04,0x55,0x02,0x03,0x04};
//const uint8_t regs13[] PROGMEM = {0x60,0x02,0x03,0x04,0x61,0x02,0x03,0x04,0x62,0x02,0x03,0x04,0x63,0x02,0x03,0x04,0x64,0x02,0x03,0x04,0x65,0x02,0x03,0x04};
s_defaultRegsTbl defaultRegsTbl[] = {
// peer(0) or regs(1), channel, list, peer index, len, pointer to payload
{1, 0, 0, 0, 5, regs01},
// {1, 1, 1, 0, 3, regs02},
// {0, 1, 4, 0, 4, regs03},
// {0, 1, 4, 1, 4, regs04},
// {0, 1, 4, 2, 4, regs05},
// {0, 1, 4, 3, 4, regs06},
// {0, 1, 4, 4, 4, regs07},
// {0, 1, 4, 5, 4, regs08},
// {0, 2, 4, 0, 24, regs09},
// {0, 3, 4, 0, 24, regs10},
// {0, 4, 4, 0, 24, regs11},
// {0, 5, 4, 0, 24, regs12},
// {0, 6, 4, 0, 24, regs13},
};
HM::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
1, defaultRegsTbl
};
Hi,
Zitat von: unimatrix am 28 Juli 2014, 14:01:56
Lustigerweise habe ich mir gerade am Wochenende mein Panstamp 12-Kanal Output Modul (8 Relais, 4 x 0-10V )zusammengebaut und die AskSin Lib darauf geflasht mit einem 8-Kanal Device. Was allerdings in der jetzigen Version der Lib ziemlich speichereng wird da vieles im SRAM behalten wird. Ich werde das für die Fußbodenheizungssteuerung einsetzen. Funktioniert noch nicht so gut, liegt wohl an meiner selbstgebauten Drahtantenne...kann empfangen aber nicht senden...
bei mir wären das 9 Heizkreise in der FBH - dafür brauche ich keine Analogoutputs. Denkst Du das passt in den Panstamp rein? Dann hätte ich einen guten Grund mich näher mit der AskSin Lib auseinanderzusetzen :-)
Danke und Grüße,
Andy.
Die Kanäle "passen" da schon rein in den Panstamp. Aber das fertige Output-Board hat nunmal nur 8 Relais. Das schöne daran ist nur, dass es das so schon fertig gibt und man nix basteln muss.
@unimatrix - hast du dir mal das eeprom zeug von der neuen asksin angeschaut?
ist das für dich ok, verbesserungsbedarf?
@trilu: finde das mit den Peers interessant gelöst. Vor allem sehr übersichtlich.
Hattest du das so geplant, dass man dann einfach die HAL "austauscht" wenn man z.B. ein externes I2C EEPROM dran hat?
Bei meinen Tests mit dem externen EEProm wurde klar dass man das Timing irgendwie berücksichtigen muss. Wenn das EEProm noch im Schreibzyklus ist, nimmt es keine neuen Daten an. Man muss das entweder abprüfen oder anders dafür sorgen, dass zwischen zwei Schreibzugriffen eine Mindestzeit von ca. 5 ms liegt.
Ich war an der Dimmerklasse nicht untätig, aber es sind noch viele Details zu machen. Ich hoffe ich kann dir bald eine Version geben. An ein paar "Kleinigkeiten" habe ich mir die Zähne ausgebissen.
ja, entweder hal austauschen oder anpassen.
du könntest z.b. nur die höheren adressen ins externe eeprom schreiben
z.b. so
void setEEPromBlock(uint16_t addr,uint8_t len,void *ptr) {
if (addr < 1000) {
eeprom_write_block((const void*)ptr,(void*)addr,len);
} else {
i2c_eepromwrite....
}
}
auf das timing muss man beim internen eeprom keine rücksicht nehmen, das macht der schreibbefehl. aus dem kommt man erst nach einer gewissen wartezeit raus.
16 byte schreiben braucht um die 20ms. ist aber ok, mehr wird nie auf einmal geschrieben und timeout kommt erst nach 300ms bei hm...
Habt ihr als Alternative für ein externes EEprom schonmal ein I2C FRAM in Betracht gezogen, zB ein Ramtron FM24CL16B? Hier sollte es keinerlei Probleme mit den Timing geben.
Beste Grüße,
Andy.
Es geht ja darum dass auf den Devices von eq3 schon ein empört drauf ist... Fuer die Anwendung reicht es wohl wirklich einfach die paar ms zu warten bzw. in der hal abzupruefen ob das eeprom bereit ist.
@trilu
unter https://github.com/unimatrix27/Asksin/tree/mymaster findest du eine dimmer.cpp und dimmer.h - dies ist der erste Draft einer Dimmerklasse, deckt bis jetzt nur trigger11 ab.
ich bin allerdings auf einer Dienstreise und kann das nicht auf einem Device testen. Aber nur mal so als Zwischenstand...
Hallo unimatrix
Zitat von: unimatrix am 28 Juli 2014, 14:05:04
Übrigens eine Register.h für einen 8-Kanal Aktor würde ungefähr so aussehen. Wenn man da mehrere Peers braucht gibts aber EEProm Platzprobleme.
Bei mir erscheint zwar die Komponente in FHEM, allerdings ohne schaltbare Kanäle.
Ich habe nun mal das Script destillRegs.pl mal mit der mitgelieferten devDefinition.pm ausgeführt und das Ergebnis in eine Register.h Datei umgeleitet. anschliessend noch die Headerinfos dazu kopiert und erhalte beim Kompilieren nun folgende Meldung:
AskSin\AskSinMain.cpp.o: In function `HM::loadDefaults()':
C:\Users\Test\Documents\Arduino\libraries\AskSin/AskSinMain.cpp:249: undefined reference to `dtRegs'
C:\Users\Test\Documents\Arduino\libraries\AskSin/AskSinMain.cpp:255: undefined reference to `dtRegs'
C:\Users\Test\Documents\Arduino\libraries\AskSin/AskSinMain.cpp:255: undefined reference to `dtRegs'
C:\Users\Test\Documents\Arduino\libraries\AskSin/AskSinMain.cpp:254: undefined reference to `dtRegs'
Hast du noch ein paar Tipps für mich ?
Gruss Peter
Hallo PeterS,
Damit ein Device in FHEM funtktioniert, muss es natürlich in HMConfig überhaupt existieren. Dieser Thread hier geht hauptsächlich um die Firmware der Module. Für eine komplette Integration muss immer auch die FHEM Seite angepasst/erweitert werden- zumindest bei neuen Modulen die es ansonsten "so nicht gibt".
Wenn man Module die es auch von EQ3 gibt nachbaut oder zumindest solche, die die gleiche Art und Anzahl an Kanälen haben, dann kann man diesen die entsprechende Modell ID in der register.h geben. FHEM "kennt" sie dann und legt auch die Kanäle richtig an.
Der andere Fehler von dir sagt ja schon, was fehlt. Nämlich die Definition von dtRegs. Diese kann unten an die register.h manuell angefügt werden und führt dazu, dass du Defaultwerte in den Listen hast.
Beispiel:
const uint8_t regs01[] PROGMEM = {0x00,0x00,0x11,0x22,0x33}; //(Default wird als Pair 112233 eingetragen, so muss man nicht immer neu pairen)
s_defaultRegsTbl defaultRegsTbl[] = {
{1, 0, 0, 0, 5, regs01},
};
HM::s_dtRegs dtRegs = {
// amount of lines in defaultRegsTbl[], pointer to defaultRegsTbl[]
1, defaultRegsTbl
};
Hallo kuek
Ich kann das Verhalten, dass die Kanäle nach einigen Sekunden abschalten auch auf einem Panstamp feststellen.
Konntest du das Problem schon lösen ?
Zitat von: kuek am 20 Juli 2014, 20:27:06
Habe die gesamte lib getauscht und den aktuellen status von trilu genommen. Damit geht es prinzipiell.
-> 0E 1E B0 11 F1 00 64 00 00 63 02 01 C8 00 00 (l:15)
<- 0E 1E 80 02 00 00 63 F1 00 64 01 01 C8 00 00 (l:15)
<- 0E 05 A4 10 00 00 63 F1 00 64 06 01 C8 00 00 (l:15)
-> 0A 05 80 02 F1 00 64 00 00 63 00 (l:11)
Allerdings funktioniert es nur wenige Minuten, danach schaltet der arduino wieder konstant aus, wie gehabt. Nach einem reset geht es dann wieder.
Werde mal neue arduino hardware testen, vielleicht liegt es doch an der China version!?
Grüße,
kuek
Gruss Peter
Habe einen Bug in der Lib gefunden der dazu führen kann dass nach einem Einschalten über FHEM die Kanäle nach einer zufälligen Zeit wieder abschalten.
Kann in Kürze einen Fix bereitstellen
Hallo unimatrix
Ich würde dann auch diesen testen ;)
Zitat von: unimatrix am 31 Juli 2014, 13:26:15
Habe einen Bug in der Lib gefunden der dazu führen kann dass nach einem Einschalten über FHEM die Kanäle nach einer zufälligen Zeit wieder abschalten.
Kann in Kürze einen Fix bereitstellen
Gruss Peter
Der hier angefügte Patch (Trilu kann überlegen, ob er das in die bestehende Lib (nicht die neue, die in Erstellung ist) noch einpatchen möchte auf dem Git) beinhaltet:
- Bug: Kanal schaltet manchmal nach einer Zeit x, die unterschiedlich ist, ab. Dies lag daran, dass, wenn unlimitiert eingeschaltet wird per FHEM, nicht geprüft wurde, ob es eine OnTime überhaupt gibt und dann ein Wert per Zeiger aus dem Speicher genommen wurde, der ggf. einen undefinierten Zustand haben konnte. Der Kanal hat reagiert wie bei "on-for-timer"
- MsgCount wird mit 0 initialisiert: vorher hatte ein Kanal immer den zweiten Tastendruck eines Peers verpasst/übersprungen
- Das Anlegen des Default-Registersets für single-peering funtioniert jetzt. Das Default-Set wurde angepasst nach dem Schema: Off->OnDly->On->OffDly
--- a/Relay.h
+++ b/Relay.h
@@ -85,7 +85,7 @@ class Relay {
uint8_t mDel, rDel; // store for the call back delay
uint32_t cbsTme; // timer for call back poll routine
- void trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime); // FHEM event
+ void trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime,uint8_t len); // FHEM event
void trigger41(uint8_t lngIn, uint8_t val); // sensor event called
void trigger40(uint8_t lngIn, uint8_t cnt); // remote event called
--- "a/Relay.cpp"
+++ "b/Relay.cpp"
@@ -22,9 +22,9 @@ const uint8_t peerEven[] = {
};
const uint8_t peerSingle[] = {
// Default actor single: 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01
- // 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63
+ // 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:01 8B:14 8C:63
0x00, 0x00, 0x32, 0x64, 0x00, 0xFF, 0x00, 0xFF, 0x01, 0x14, 0x63,
- 0x00, 0x00, 0x32, 0x64, 0x00, 0xFF, 0x00, 0xFF, 0x21, 0x14, 0x63,
+ 0x00, 0x00, 0x32, 0x64, 0x00, 0xFF, 0x00, 0xFF, 0x01, 0x14, 0x63,
};
@@ -50,15 +50,19 @@ void Relay::config(void Init(), void Switch(uint8_t), uint8_t minDelay, uint8_t
nxtStat = 6; // set relay status to off
adjRly(0); // set relay to a defined status
curStat = 6; // set relay status to off
+ msgRecvCnt = 0; // init counter.
}
// private functions for triggering some action
-void Relay::trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime) {
+void Relay::trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime, uint8_t len) {
// {no=>0,dlyOn=>1,on=>3,dlyOff=>4,off=>6}
rTime = (uint16_t)rampTime[0]<<8 | (uint16_t)rampTime[1]; // store ramp time
- dTime = (duraTime)?((uint16_t)duraTime[0]<<8 | (uint16_t)duraTime[1]):0; // duration time if given
-
+ if(len>3){
+ dTime = (duraTime)?((uint16_t)duraTime[0]<<8 | (uint16_t)duraTime[1]):0;// duration time if given
+ }else{
+ dTime =0;
+ }
if (rTime) nxtStat = (val == 0)?4:1; // set next status
else nxtStat = (val == 0)?6:3;
@@ -261,7 +265,7 @@ void Relay::hmEventCol(uint8_t by3, uint8_t by10, uint8_t by11, uint8_t *data, u
if ((by3 == 0x01) && (by11 == 0x01)) peerAddEvent(data, len);
if (by3 >= 0x3E) peerMsgEvent(by3, data, len);
- if ((by3 == 0x11) && (by10 == 0x02)) trigger11(data[0], &data[1], &data[3]);
+ if ((by3 == 0x11) && (by10 == 0x02)) trigger11(data[0], &data[1], &data[3],len);
if (by3 == 0x40) trigger40((by10 & 0x40), data[0]);
}
void Relay::peerAddEvent(uint8_t *data, uint8_t len) {
@@ -269,10 +273,10 @@ void Relay::peerAddEvent(uint8_t *data, uint8_t len) {
// 1st byte and 2nd byte shows the peer channel, 3rd and 4th byte gives the peer index
// no need for sending an answer, but we could set default data to the respective list3/4
#ifdef DM_DBG
Serial << F("peerAddEvent: pCnl1: ") << pHexB(data[0]) << F(", pCnl2: ") << pHexB(data[1]) << F(", pIdx1: ") << pHexB(data[2]) << F(", pIdx2: ") << pHexB(data[3]) << '\n';
#endif
- if ((data[0]) && (data[1])) { // dual peer add
+ if ((data[0]) != (data[1])) { // dual peer add
if (data[0]%2) { // odd
hm->setListFromModule(regCnl,data[2],(uint8_t*)peerOdd,sizeof(peerOdd));
hm->setListFromModule(regCnl,data[3],(uint8_t*)peerEven,sizeof(peerEven));
Hallo unimatrix
Danke für den Patch.
Ein erster Test mit dem Sketch "HM_LC_SW1_BA_PCB" sah zunächst ganz gut aus.
Nach mehrfachen Schalten fällt der Ausgang leider wieder ab!
Gruss Peter
melde mich per PM bei dir
Zitat von: PeterS am 31 Juli 2014, 14:54:29
Hallo unimatrix
Danke für den Patch.
Ein erster Test mit dem Sketch "HM_LC_SW1_BA_PCB" sah zunächst ganz gut aus.
Nach mehrfachen Schalten fällt der Ausgang leider wieder ab!
Gruss Peter
Hi Peter,
komme erst gerade dazu wieder im Forum zu lesen. Gibt es schon Neuigkeiten? Habe es bisher nicht ans Laufen bekommen. Den Patch habe ich noch nicht getestet.
kuek
hallo unimatrix, hallo peter,
scheint zu gehen. auch mit "meinem" Sw4-BA. Zumindest nach den ersten 15 minuten testen ist es stabil. Konntest Du es auch zum Laufen bringen, Peter? Sonst schicke ich dir meine Lib und die ino.
kuek
Zitat von: unimatrix am 31 Juli 2014, 14:26:59
Der hier angefügte Patch (Trilu kann überlegen, ob er das in die bestehende Lib (nicht die neue, die in Erstellung ist) noch einpatchen möchte auf dem Git) beinhaltet:
- Bug: Kanal schaltet manchmal nach einer Zeit x, die unterschiedlich ist, ab. Dies lag daran, dass, wenn unlimitiert eingeschaltet wird per FHEM, nicht geprüft wurde, ob es eine OnTime überhaupt gibt und dann ein Wert per Zeiger aus dem Speicher genommen wurde, der ggf. einen undefinierten Zustand haben konnte. Der Kanal hat reagiert wie bei "on-for-timer"
- MsgCount wird mit 0 initialisiert: vorher hatte ein Kanal immer den zweiten Tastendruck eines Peers verpasst/übersprungen
- Das Anlegen des Default-Registersets für single-peering funtioniert jetzt. Das Default-Set wurde angepasst nach dem Schema: Off->OnDly->On->OffDly
--- a/Relay.h
+++ b/Relay.h
@@ -85,7 +85,7 @@ class Relay {
uint8_t mDel, rDel; // store for the call back delay
uint32_t cbsTme; // timer for call back poll routine
- void trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime); // FHEM event
+ void trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime,uint8_t len); // FHEM event
void trigger41(uint8_t lngIn, uint8_t val); // sensor event called
void trigger40(uint8_t lngIn, uint8_t cnt); // remote event called
--- "a/Relay.cpp"
+++ "b/Relay.cpp"
@@ -22,9 +22,9 @@ const uint8_t peerEven[] = {
};
const uint8_t peerSingle[] = {
// Default actor single: 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01
- // 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63
+ // 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:01 8B:14 8C:63
0x00, 0x00, 0x32, 0x64, 0x00, 0xFF, 0x00, 0xFF, 0x01, 0x14, 0x63,
- 0x00, 0x00, 0x32, 0x64, 0x00, 0xFF, 0x00, 0xFF, 0x21, 0x14, 0x63,
+ 0x00, 0x00, 0x32, 0x64, 0x00, 0xFF, 0x00, 0xFF, 0x01, 0x14, 0x63,
};
@@ -50,15 +50,19 @@ void Relay::config(void Init(), void Switch(uint8_t), uint8_t minDelay, uint8_t
nxtStat = 6; // set relay status to off
adjRly(0); // set relay to a defined status
curStat = 6; // set relay status to off
+ msgRecvCnt = 0; // init counter.
}
// private functions for triggering some action
-void Relay::trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime) {
+void Relay::trigger11(uint8_t val, uint8_t *rampTime, uint8_t *duraTime, uint8_t len) {
// {no=>0,dlyOn=>1,on=>3,dlyOff=>4,off=>6}
rTime = (uint16_t)rampTime[0]<<8 | (uint16_t)rampTime[1]; // store ramp time
- dTime = (duraTime)?((uint16_t)duraTime[0]<<8 | (uint16_t)duraTime[1]):0; // duration time if given
-
+ if(len>3){
+ dTime = (duraTime)?((uint16_t)duraTime[0]<<8 | (uint16_t)duraTime[1]):0;// duration time if given
+ }else{
+ dTime =0;
+ }
if (rTime) nxtStat = (val == 0)?4:1; // set next status
else nxtStat = (val == 0)?6:3;
@@ -261,7 +265,7 @@ void Relay::hmEventCol(uint8_t by3, uint8_t by10, uint8_t by11, uint8_t *data, u
if ((by3 == 0x01) && (by11 == 0x01)) peerAddEvent(data, len);
if (by3 >= 0x3E) peerMsgEvent(by3, data, len);
- if ((by3 == 0x11) && (by10 == 0x02)) trigger11(data[0], &data[1], &data[3]);
+ if ((by3 == 0x11) && (by10 == 0x02)) trigger11(data[0], &data[1], &data[3],len);
if (by3 == 0x40) trigger40((by10 & 0x40), data[0]);
}
void Relay::peerAddEvent(uint8_t *data, uint8_t len) {
@@ -269,10 +273,10 @@ void Relay::peerAddEvent(uint8_t *data, uint8_t len) {
// 1st byte and 2nd byte shows the peer channel, 3rd and 4th byte gives the peer index
// no need for sending an answer, but we could set default data to the respective list3/4
#ifdef DM_DBG
Serial << F("peerAddEvent: pCnl1: ") << pHexB(data[0]) << F(", pCnl2: ") << pHexB(data[1]) << F(", pIdx1: ") << pHexB(data[2]) << F(", pIdx2: ") << pHexB(data[3]) << '\n';
#endif
- if ((data[0]) && (data[1])) { // dual peer add
+ if ((data[0]) != (data[1])) { // dual peer add
if (data[0]%2) { // odd
hm->setListFromModule(regCnl,data[2],(uint8_t*)peerOdd,sizeof(peerOdd));
hm->setListFromModule(regCnl,data[3],(uint8_t*)peerEven,sizeof(peerEven));
Peter hat wohl noch das Problem und hat mir seine Sachen geschickt, ich komme aber wohl heute nicht mehr dazu, mir das anzuschauen.
Hallo kuek
Ich habe basierend auf dem Beispiel HM_LC_SW1_BA_PCB und deiner 4fach Register.h meinen Sketch aufgebaut.
Von unimatrix habe ich Änderungen an der Lib übernommen.
Meine 4fach Relaiskarte schaltet sauber und hält meistens die Signalzustände.
Hin und wieder fallen die Ausgänge aber reihenweise ab. Dann schalte ich sie mehrfach ein und irgendwann bleiben sie dann wieder an.
Wenn deine Lösung stabil läuft schicke mir mal bitte dein Paket zum Testen!
Danke im voraus ;)
Gruss Peter
Zitat von: PeterS am 03 August 2014, 21:59:08
Hallo kuek
Ich habe basierend auf dem Beispiel HM_LC_SW1_BA_PCB und deiner 4fach Register.h meinen Sketch aufgebaut.
Von unimatrix habe ich Änderungen an der Lib übernommen.
Meine 4fach Relaiskarte schaltet sauber und hält meistens die Signalzustände.
Hin und wieder fallen die Ausgänge aber reihenweise ab. Dann schalte ich sie mehrfach ein und irgendwann bleiben sie dann wieder an.
Wenn deine Lösung stabil läuft schicke mir mal bitte dein Paket zum Testen!
Danke im voraus ;)
Gruss Peter
hast ne pm.
wenn es bei dir auch läuft werde ich es hier hochladen. so hat jeder was davon.
kuek
Mir ist noch nicht ganz klar woher das problem mit dem abschalten eigentlich kommt?
Gibt es denn einen Trigger11, also einen Set Befehl von FHEM kommend, wo die duartion time nicht gesetzt wird?
Soweit ich das in Erinnerung habe, wird die immer gesetzt - also es gibt keinen Trigger11 der die Duration Time nicht liefert.
Vielleicht macht ihr mal einen Log der seriellen Konsole?
0E 1E B0 11 F1 00 64 00 00 63 02 01 C8 00 00
So sieht der Trigger11 aus, also duartime = 0;
Hi Trilu,
bei "02 01 C8 00 00" bedeuten doch die zwei letzten Nullen die Ramptime, eine DuraTime wird nicht übertragen und führte dazu in der Relay.h zu zufälligem verhalten (Zeiger auf undefinierte Daten) - daher mein Patch von oben. NIchtsdestotrotz scheint es ja noch andere Probleme zu geben, die damit nicht behoben wurden. Das muss ich mir noch ansehen.
Zum vergleich: ein "set xxx on-for-timer 20" sieht dann so aus:
02 01 C8 00 00 19 00 - die "19 00" sind die Duration in Homematic Codierung.
Dachte ich bisher jedenfalls immer und so hat es sich auch verhalten....vll schmeiß ich ja auch jetzt was durcheinander.
ups, mein fehler :-)
"11;p01=02" => { txt => "SET" , params => {
CHANNEL => "02,2",
VALUE => "04,2",
RAMPTIME => '06,4,$val=CUL_HM_decodeTime16($val)',
DURATION => '10,4,$val=CUL_HM_decodeTime16($val)', } },
du hast recht, es wird ein integer übertragen und falls duration gesetzt werden soll, dann sind es zwei integer....
Hallo kuek und unimatrix
Danke für die Unterstützung.
Bei mir läuft der 4fach PCB mit den Änderungen von unimatrix nun auch stabil. D.h. die Ausgänge fallen nun nicht mehr willkürlich im Serial-Debugging (siehe Coding unten) oder an der 4fach-Relaiskarte ab :D
...
relay[0].regInHM(1,&hm); // register relay class in HM to respective channel
relay[0].config(&initRelay,&switchRelay1,2,2); // init function, switch function, min delay, random delay for transmitting status message
relay[1].regInHM(2,&hm); // register relay class in HM to respective channel
relay[1].config(&initRelay,&switchRelay2,2,2); // configure the relay to monostable, therefore only one HW pin needed
relay[2].regInHM(3,&hm); // register relay class in HM to respective channel
relay[2].config(&initRelay,&switchRelay3,2,2); // init function, switch function, min delay, random delay for transmitting status message
relay[3].regInHM(4,&hm); // register relay class in HM to respective channel
relay[3].config(&initRelay,&switchRelay4,2,2); // configure the relay to monostable, therefore only one HW pin needed
Serial << "\npair: " << pHex(regs.ch0.l0.pairCentral,3) << '\n';
}
void loop() {
parser.poll(); // handle serial input from console
hm.poll();
valA1 = digitalRead(A1);
valA2 = digitalRead(A2);
valA3 = digitalRead(A3);
valA4 = digitalRead(A4);
val_new = String(valA1, DEC) + String(valA2, DEC) + String(valA3, DEC) + String(valA4, DEC);
if (val_new != val_old) {
Serial << " \nPort A1234: " << val_new << '\n';
val_old = val_new;
}
}
void initRelay() {
digitalWrite(A1,0);
digitalWrite(A2,0);
digitalWrite(A3,0);
digitalWrite(A4,0);
pinMode(A1,OUTPUT);
pinMode(A2,OUTPUT);
pinMode(A3,OUTPUT);
pinMode(A4,OUTPUT);
}
void switchRelay1(uint8_t on) {
if (on) {
digitalWrite(A1,1);
// delay(1000);
}
else {
digitalWrite(A1,0);
// delay(1000);
}
}
void switchRelay2(uint8_t on) {
if (on) {
digitalWrite(A2,1);
// delay(1000);
}
else {
digitalWrite(A2,0);
// delay(1000);
}
}
void switchRelay3(uint8_t on) {
if (on) {
digitalWrite(A3,1);
// delay(1000);
}
else {
digitalWrite(A3,0);
// delay(1000);
}
}
void switchRelay4(uint8_t on) {
if (on) {
digitalWrite(A4,1);
// delay(1000);
}
else {
digitalWrite(A4,0);
// delay(1000);
}
}
...
Die Ursache meiner Probleme ist mir allerdings noch rätselhaft ???
Nach etlichen Kompilingfehlern und Problemen mit abfallenden Ausgänge habe ich mal meine Arduino-preferences.txt gelöscht.
Da nun die Ausgangsseite soweit stabil läuft, ist mein nächste Schritt die Kombination von 4-Eingängen und 4-Ausgängen in einem Sketch.
Gruss Peter
bedeutet das, dass deine "zufällig abschalten" - Probleme nun doch mit dem Patch (anscheinend) beseitigt sind? Ich hatte die letzten Tage nur wenig Zeit aber ich konnte auch in deinem Code keinen Grund mehr finden, warum sich da was abschalten sollte...
VG
Genau. Das was ich getestet habe, sieht nun gut aus !
Danke ;)
Gruss Peter
Hallo
Wenn ich die Library in einer neuen Arduino-IDE V1.5.7 versuche zum Laufen zu bringen erhalte ich folgende Fehler:
In file included from C:\Users\Test\Workplace\Arduino\arduino-1.5.7\libraries\AskSin/AskSinMain.h:31:0,
from sketch_aug10a.ino:1:
C:\Users\Test\Workplace\Arduino\arduino-1.5.7\libraries\AskSin/utility/StatusLed.h:18:20: fatal error: Serial.h: No such file or directory
#include <Serial.h>
^
compilation terminated.
#include <AskSinMain.h>
#include <Buttons.h>
#include <Dummy.h>
#include <Relay.h>
#include <Sensor_SHT10_BMP085_TSL2561.h>
void setup() {
// put your setup code here, to run once:
}
void loop() {
// put your main code here, to run repeatedly:
}
PS: Die Library wurde die Funktion "Library importieren" eingefügt
Kennt jemand die Lösung ?
Gruss Peter
Hallo Zusammen
Mein Ziel ist es immer noch die Kombination von 4-Eingängen und 4-Ausgängen in einem Sketch zu pressen und möglichst auf Standarddefinitionen (FHEM, Homematic) aufzubauen.
Gibt es eine HM-Komponente (Dimmer, Temp, etc.) welche sowohl ein Input/-Output Byte bereitstellt, dann könnte ich meine Signalzustände auch als Byte konsolidiert übertragen ?
Gruss Peter
Ich kann mir nicht vorstellen dass es so eine Komponente gibt. HM macht das immer Channel Orientiert.
Das heisst, du bekommst pro Kanal ein Byte, dass den Zustand angibt. Und der ist 0-200...
Bei einem Dimmer Kanal sind das 0,5%, bei Schaltern ist 0 aus und 200 ein....
Hallo trilu, hallo martinp876
Was muss für ein neues HM-Geräte (4 Eingangskanäle und 4 Ausgangskanäle) alles angepackt werden ?
HMconfig, 10_CUL_HM ?
Gruss Peter
Hallo Zusammen
Ich habe die Tage mehr mit der library und der HMconfig.pm befasst.
Der 4 fach switch (Modell-ID: 0xAB) sowie der 3fach Schalter (Modell-ID: 0x46) funktionieren soweit. Aber nicht in einem Sketch !!
Bei der Register.h genügt es teilweise sogar schon einfach nur die Modell-ID und Sub Type ID anzupassen ???
Mein Ziel ist es aber ein HM-Gerät HM-Gerät (4 Eingangskanäle und 4 Ausgangskanäle) zu betreiben. Besser wäre natürlich noch ein HM-Gerät (8 Eingangskanäle und 8 Ausgangskanäle und 2 Analogwerte) analog dem Multi-I/O-Modul für HomeMatic-Wired ;D
Da es so ein wireless HM-Gerät nicht gibt, müsste ich dieses in einer Register.h konstruieren und parallel die HMconfig.pm modifizieren, damit dieses neue Device auch in FHEM existiert und erkannt wird.
Ist dies überhaupt machbar, oder ist das HM-Protokoll hier definitiv der falsche Weg ? Eventuell wäre hier SWAP besser geeignet ?
Gruss Peter
Hallo Peter,
das ist schon machbar. Schaue dir doch als Beispiel mal die CustomFW des Schaltaktors an.
http://forum.fhem.de/index.php/topic,18071.0.html
Für diesen hat Martin das HMConfig angepasst (alles im GIT zu sehen) - und den Typen "remoteAndSwtich" erfunden. Dieser hat also sowohl Eingänge als auch Ausgänge, bzw sowohl Sensoren/Taster als auch Aktoren. (hier: 2 Taster + 3 Aktorkanäle).
Basierend auf diesem Beispiel solltest du das ganze hochskalieren können. Dazu muss wie du schon erkannt hast die register.h angepasst werden (dazu kann das Perl-Script verwendet werden, du baust dir die devDefinition.pm einfach aus den von dir gewünschten Registern und vorhandenen HM-Geräten zusammen). Die HMConfig aus dem obigen Beispiel muss wohl nur noch leicht angepasst werden.
Theoretisch sind der Anzahl der Kanäle keine Grenzen gesetzt, aber es wird hier dann im Speicher und EEProm eng. Es hängt von der Größe deiner Registersets ab, sobald du die channel "peerbar" machst brauchst du pro CHannel den Platz für alle zugelassenen Peers.
Hallo unimatrix
Das Beispiel hatte ich mir schon angesehen und versucht in meine Register.h zu portieren.
Allerdings ist die Register.h des Wechselschalters schon recht komplex.
Meine Versuche mit der Modell-ID 0xF0, 0xA9 führten entweder zu Compilingfehlern oder dem FHEM-Device fehlten die Kanäle und Aktionen :-[
Wäre es nicht sinnvoll ein universelles I/O Devices zu generieren (mehrere Eingänge und Ausgänge und vielleicht 2 Analogwerte), welches man individuell nutzen könnte ?
EQ3 geht nun schonmal den Weg im dem 8fach-Ausgängen, vielleicht folgen demnächst noch die 8fach-Eingänge ;)
Gruss Peter
So ein Modul gibt es schon. Bereits bestellbar, jedoch erst in 4 Monaten lieferbar.
Es sind das Pärchen HM-MOD-Re-8 und HM-MOD-EM-8.
Hallo Hexenmeister
Danke für die Info.
Den HM-MOD-EM-8 kannte ich noch nicht :-)
Allerdings sind dies 2 getrennte Module.
D.h. man müsste 2 Panstamp (oder ähnliches) einsetzen um die Funktionalität nachzubilden oder halt doch ein neues Homebrew Devices aus beiden bilden :-)
Gruss Peter
Hallo Peter,
du möchtest ein Device bauen, was es so noch nicht gibt. Dazu brauchst du also eine neue, eigene Modell-ID. Die kannst du dir schlicht ausdenken. Die Modell-ID wird dann von CUL_HM beim Paring benutzt um zu erkennen um was für ein Device es sich handelt. Daher muss eben CUL_HM (bz. HMConfig als Teil davon) um deine neue Modell-ID erweitert werden. Speziell für diesen Teil ist glaube ich die von Martin geschriebene Erweiterung von HMConfig (in eigener Datei) die beste Vorlage. Damit würde ich aber nicht anfangen, sondern erstmal mit dem Device.
Dafür fängtst du mit der devDefinition.pm an. siehe: https://github.com/trilu2000/AskSin/tree/master/destillRegs
mit der destillRegs.pl und deiner selbst geschriebenen devDefinition.pm (in dieser suchst du aus, was für Kanäle und Registerlisten dein Device haben soll) wird dann der Hauptteil der register.h automatisch erzeugt. Du fügst nur am Kopf den Header mit HMID usw. an und am Ende noch Defaultwerte.
Was für Compilerfehler hattest du und warum?
Hallo unimatrix
Die Compiling-Fehler führe ich auf die Standard-Askin Library zurück. Ich hatte nicht die projektspezifische verwendet.
Muss nicht zuerst die FHEM-Seite aufgebohrt (CUL_HM) werden, damit man überhaupt ein Homebrew Devices nutzen kann.
Andernfalls erschein ein grosses Fragezeichen und das Devices besitzt keine Kanäle, etc.
Das Problem ist aber auch dann, dass mit jedem FHEM-Update die Definition überschrieben wird, oder ?!
Gruss Peter
Zitat von: PeterS am 20 August 2014, 11:38:30
Muss nicht zuerst die FHEM-Seite aufgebohrt (CUL_HM) werden, damit man überhaupt ein Homebrew Devices nutzen kann.
Andernfalls erschein ein grosses Fragezeichen und das Devices besitzt keine Kanäle, etc.
Das kannst du dir beim Universalsensor ansehen.
Du musst ein entsprechendes File für FHEM erstellen. HMConfig_xxx
https://raw.githubusercontent.com/kc-GitHub/Wettersensor/master/Tools/FHEM/HMConfig_SenTHPL.pm
Gruß
Dirk
Scheint ganz neu zu sein. Habe gestern zufällig in dem neuen ELV Katalog gefunden.
Hallo Zusammen
Ich habe mir zu Testzwecken mal eine eigene HMConfig_HomeBrew.pm definiert und darin einen 8-fach Relay (ID:00FF) und einen 8-fach threeStateSensor (ID:00EF) definiert.
Der 8-fach threeStateSensor kann ich über die "$0C $00 $A4 $41 $FF $F0 $01 $F1 $16 $02 $01 $B2 $C8 s" Konsole triggern, allerdings nicht über den sketch direkt, da ich keinen Hardware-Interrupt auslöse.
Gibt es eine Funktion, um direkt den Zustand (High, Low) über den Channel direkt zu triggern ?
PS: Als nächsten Schritt möchte ich dann die beide Devices verschmelzen ::)
HMConfig_HomeBrew.pm:
package main;
use strict;
use warnings;
# device definition
$HMConfig::culHmModel{'F101'} = {name => 'HB-UW-Sen-THPL-I', st => 'THPLSensor', cyc => '00:10', rxt => 'c:f', lst => 'p', chn => '',};
$HMConfig::culHmModel{'F102'} = {name => 'HB-UW-Sen-THPL-O', st => 'THPLSensor', cyc => '00:10', rxt => 'c:f', lst => 'p', chn => '',};
$HMConfig::culHmModel{'00FF'} = {name => 'HM-MOD-FF-8', st => 'switch', cyc => '', rxt => 'b', lst => '3', chn => 'Sw:1:8',},
$HMConfig::culHmModel{'00FE'} = {name => 'HM-SCI-FE-8', st => 'threeStateSensor', cyc => '28:00', rxt => 'c:w', lst => '1,4', chn => 'Sw:1:8',},
# Register model mapping
$HMConfig::culHmRegModel{'HB-UW-Sen-THPL-I'} = {burstRx =>1};
$HMConfig::culHmRegModel{'HB-UW-Sen-THPL-O'} = $HMConfig::culHmRegModel{'HB-UW-Sen-THPL-I'};
$HMConfig::culHmRegModel{'HM-MOD-FF-8'} = {lowBatLimitBA3 =>1, ledMode =>1,localResDis =>1};
$HMConfig::culHmRegModel{'HM-SCI-FE-8'} = {msgScPosA =>1, msgScPosB =>1, eventDlyTime =>1};
# subtype channel mapping
$HMConfig::culHmSubTypeSets{'THPLSensor'} = {peerChan => '0 <actChn> ... single [set|unset] [actor|remote|both]'};
# Subtype spezific funtions
sub CUL_HM_ParseTHPLSensor(@){
my ($mFlg, $frameType, $src, $dst, $msgData, $targetDevIO) = @_;
my $shash = CUL_HM_id2Hash($src); #sourcehash - will be modified to channel entity
my @events = ();
# WEATHER_EVENT
if ($frameType eq '70'){
my $name = $shash->{NAME};
my $chn = '01';
my ($dTempBat, $hum, $pressure, $luminosity, $batVoltage) = map{hex($_)} unpack ('A4A2A4A8A4A8A8', $msgData);
my $temperature = $dTempBat & 0x7fff;
$temperature = ($temperature &0x4000) ? $temperature - 0x8000 : $temperature;
$temperature = sprintf('%0.1f', $temperature / 10);
my $stateMsg = 'state:T: ' . $temperature;
push (@events, [$shash, 1, 'temperature:' . $temperature]);
push (@events, [$shash, 1, 'battery:' . ($dTempBat & 0x8000 ? 'low' : 'ok')]);
$luminosity = ($luminosity + 0.0) / 100;
$luminosity = ($luminosity < 100) ? $luminosity : sprintf('%.0f', $luminosity);
$batVoltage = sprintf('%.2f', (($batVoltage + 0.00) / 1000));
if ($modules{CUL_HM}{defptr}{$src.$chn}){
my $ch = $modules{CUL_HM}{defptr}{$src.$chn};
push (@events, [$ch, 1, $stateMsg]);
push (@events, [$ch, 1, 'temperature:' . $temperature]);
}
# humidity
if ($hum) {
$stateMsg .= ' H: ' . $hum;
push (@events, [$shash, 1, 'humidity:' . $hum]);
}
# luminosity
if ($luminosity < 65538) {
$stateMsg .= ' L: ' . $luminosity;
push (@events, [$shash, 1, 'luminosity:' . $luminosity]);
}
# air pressure
if ($pressure) {
$stateMsg .= ' P: ' . $pressure;
push (@events, [$shash, 1, 'pressure:' . $pressure]);
my $altitude = AttrVal('global', 'altitude', 0);
my $pressureNN = $altitude ? sprintf('%.0f', ($pressure + ($altitude / 8.5))) : 0;
if ($pressureNN) {
$stateMsg .= ' P-NN: ' . $pressureNN;
push (@events, [$shash, 1, 'pressure-nn:' . $pressureNN]);
}
}
$stateMsg .= ' batVoltage: ' . $batVoltage; push (@events, [$shash, 1, 'batVoltage:' . $batVoltage]);
push (@events, [$shash, 1, $stateMsg]);
}
return @events;
}
1;
Gruss Peter
Hallo
Wie kann ich in einer eigenen HMCONFIG.pm Defnition die Eingangs- und Ausgangskanäle den Typen (Switch und threeStateSensor) zuordnen ?
Bsp:
$HMConfig::culHmModel{'00FD'} = {name => 'HM-IO-16', st => 'threeStateSensor', cyc => '28:00', rxt => 'c:w', lst => '1,4', chn => 'Sw:1:8,Sw:9:16',},
Gruss Peter
direktes auslösen hatte ich in der relay class nicht vorgesehen. im prinzip ist es aber nur eine message die du an den kanal schicken musst.
wenn der 8 kanal switch über remote funktioniert, dann würde ich einfach den switch mit rein hängen und jeweils einen switch kanal mit einem relay kanal peeren.
dann schickt der switch die message an den kanal und es wird geschaltet....
Danke für die Info trilu.
Das teste ich mal :-)
Kann mir noch jemand mit der eigenen HMConfig.pm weiterhelfen ?
Wie kann ich die Kanäle einem switch oder threeStateSensor zuweisen damit die richtige Konfiguration gezogen wird ?
Gruss Peter
Hallo trilu
Das peering zwischen Kanal 1 und Kanal x hat nicht funktioniert. Es kommen keine Messages.
Wo sollte dies in Register.h eingetragen werden ?
Hast du mal ein Beispiel für mich ?
Gruss Peter
Hallo unimatrix
Folgende kobinierte Definition (switch/threeStateSensor) habe ich in meiner HMConfig_HomeBrew.pm vorgenommen.
Der switch funktioniert, allerdings fehlt das webcmd "toogle".
Der threeStateSensor verhält sich wie ein Button, also state short bzw long.
Kann man bei einem kombinierten Devices die Attribute direkt mitgeben oder nur über eine eigene Funktion ?
package main;
use strict;
use warnings;
use POSIX;
use Switch;
sub
Asksin_HM_LC_Sw1PBU_FM_CustomFW_Initialize($$)
{
my ($hash) = @_;
}
sub
registerHM_LC_Sw1PBU_FM_CustomFW()
{
{$HMConfig::culHmModel{"00FD"} = {name=>"HM-IO-4",st=>'remoteAndSwitch',cyc=>'',rxt=>'',lst=>'3:1p.2p.3p.4p,1,4:5p.6p.7p.8p',chn=>"Sw:1:4,Btn:5:8"}}
{$HMConfig::culHmChanSets{"HM-IO-400"}{fwUpdate} ="<filename>"};
{$HMConfig::culHmChanSets{"HM-IO-401"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmChanSets{"HM-IO-402"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmChanSets{"HM-IO-403"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmChanSets{"HM-IO-404"} = $HMConfig::culHmSubTypeSets{"switch"}};
{$HMConfig::culHmChanSets{"HM-IO-405"} = $HMConfig::culHmSubTypeSets{"threeStateSensor"}};
{$HMConfig::culHmChanSets{"HM-IO-406"} = $HMConfig::culHmSubTypeSets{"threeStateSensor"}};
{$HMConfig::culHmChanSets{"HM-IO-407"} = $HMConfig::culHmSubTypeSets{"threeStateSensor"}};
{$HMConfig::culHmChanSets{"HM-IO-408"} = $HMConfig::culHmSubTypeSets{"threeStateSensor"}};
{$HMConfig::culHmRegChan{"HM-IO-401"} = $HMConfig::culHmRegType{switch}};
{$HMConfig::culHmRegChan{"HM-IO-402"} = $HMConfig::culHmRegType{switch}};
{$HMConfig::culHmRegChan{"HM-IO-403"} = $HMConfig::culHmRegType{switch}};
{$HMConfig::culHmRegChan{"HM-IO-404"} = $HMConfig::culHmRegType{switch}};
{$HMConfig::culHmRegChan{"HM-IO-405"} = $HMConfig::culHmRegType{threeStateSensor}};
{$HMConfig::culHmRegChan{"HM-IO-406"} = $HMConfig::culHmRegType{threeStateSensor}};
{$HMConfig::culHmRegChan{"HM-IO-407"} = $HMConfig::culHmRegType{threeStateSensor}};
{$HMConfig::culHmRegChan{"HM-IO-408"} = $HMConfig::culHmRegType{threeStateSensor}};
{$HMConfig::culHmRegModel{"HM-IO-8"} =
{ intKeyVisib =>1,sign =>1
,OnTime =>1,OffTime =>1,OnDly =>1,OffDly =>1
,SwJtOn =>1,SwJtOff =>1,SwJtDlyOn =>1,SwJtDlyOff =>1
,CtValLo =>1,CtValHi =>1
,CtOn =>1,CtDlyOn =>1,CtOff =>1,CtDlyOff =>1
,ActionType =>1,OnTimeMode =>1,OffTimeMode =>1
,lgMultiExec =>1
};}
#Log(1, "Registered 00FD");
}
Bei meine getrennte Definitionen wurden alle Attribute über die Standard HMConfig.pm korrekt gezogen:
package main;
use strict;
use warnings;
use POSIX;
use Switch;
# device definition
$HMConfig::culHmModel{'00FF'} = {name => 'HM-MOD-FF-8', st => 'switch', cyc => '', rxt => 'b', lst => '3', chn => 'Sw:1:8',},
$HMConfig::culHmModel{'00FE'} = {name => 'HM-SCI-FE-8', st => 'threeStateSensor', cyc => '28:00', rxt => 'c:w', lst => '1,4', chn => 'Sw:1:8',},
# Register model mapping
$HMConfig::culHmRegModel{'HM-MOD-FF-8'} = {lowBatLimitBA3 =>1, ledMode =>1,localResDis =>1};
$HMConfig::culHmRegModel{'HM-SCI-FE-8'} = {msgScPosA =>1, msgScPosB =>1, eventDlyTime =>1};
Kannst du mir hier nochmals weiterhelfen ?
Gruss Peter
Hallo martin876
Das HM-Device HM-MOD-Re-8 exisitiert bereits in der HMConfig.pm.
Wird das Sendemodul HM-MOD-EM-8 noch ergänzt ?!
Gruss Peter
Hallo trilu
Wie ist deine roadmap für die Library geplant?
Wird die library noch finalisiert oder arbeitest du nur noch an der NewAskSin ?
Welche Devices werden aktuell unterstützt ? Was ist mit Dimmern ? Was ist noch geplant ?
Gruss Peter
Roadmap hört sich zu professionell an. Ist ja nur ein Hobby.
Eigentlich arbeite ich nur noch an der neuen Lib. Sieht auch schon ganz gut aus. Grundfunktionen laufen soweit, HW Anbindung ist in eine Hal ausgelagert, d.h. sie müsste deutlich einfacher zu portieren sein. Was noch fehlt ist ein Modul für die Statusled, eins für Powersave und der User Module Registrar. Dann gehts an die Usermodule. Relay ist da und muss nur über arbeitet werden, Switch muss HW unabhängig werden und dann nehmen ich mir den Dimmer vor.
Kostet aber Alles viel Zeit, kann deshalb noch eine Weile dauern.
Viele Grasse aus Alanya
Hallo unimatrix
Hast du mal einen Beispielssketch für deine Dimmer Erweiterung ?
Gruss Peter
Ich habe meine Arbeiten an dem Device, das ich als Türöffner einsetzen möchte, seit etwa Mai ruhen lassen. Ich hatte gehofft, dass inzwischen eine Art Mirakel passiert und am Ende der Sommerzeit eine Art Kochbuch existiert, in dem systematisch die Verwendung der AskSin Library dokumentiert ist.
Denn eines muss man klar sagen: So schön das ist, und so gut und wertvoll die Arbeit von trilu an dieser Sache ist: Die Programmierung eigener Devices ist immer noch mit viel Bastelarbeit und Ausprobiererei verbunden.
Wie immer, wenn man auf ein Mirakel gehofft hat und es nicht gekommen ist: Selber Hand anlegen.
Ich habe also im Wiki einen neuen Artikel begonnen (steht noch nix drin, http://www.fhemwiki.de/wiki/Neues_HomeMatic_Device), in dem ich das dokuemtieren möchte. Und bitte um tatkräftige Mithilfe, um Registerstruktur etc. einigermaßen sauber zu beschreiben. Werde hier posten, wenn ich einen ersten Entwurf habe - ich muss aber erst mal meine Notizen aus dem Mai herauskramen und wieder verstehen.
LG
pah
Hi Peter,
wie das halt so ist mit Mirakeln - Ich persönlich glaube ja, dass Mirakel mehr dem Land der Wünsche/Träume entsprungen sind ;)
Du hast völlig recht, dass sich die Library für einen produktiven Einsatz derzeit nicht besonders eignet. Das liegt zum Einen an der fehlenden Dokumentation, zum Anderen aber auch an der Library selbst. Der aktuelle Stand ist das Ergebnis meiner nicht vorhandenen Programmierkünste. Ich habe als absoluter Anfänger, was das Thema Arduino und C++, vor etwa 1 Jahr angefangen an der Lib zu arbeiten und jede Menge über die Zeit dazu gelernt. Vieles von dem was in der aktuellen Lib ist, würde ich heute anders machen. Deshalb habe ich mit der Pflege/Verbesserung und Dokumentation der bestehenden Lib gestoppt und mit der NewAskSin begonnen.
Liegt ebenfalls im Git auf folgender Seite: https://github.com/trilu2000/NewAskSin
Mittlerer weile habe ich mit der NewAskSin einen Stand erreicht, dass die grundlegende Kommunikation ganz gut läuft, also Pair und Peer funktioniert. Registerhandling ist auch größtenteils implementiert, aber noch nicht vollständig getestet. Config Taste, Led Status Anzeige und User Modul Registrar sind auch drin. Als nächstes kümmere ich mich um das Power Management. Danach fehlen nur noch die User Module, wie Relay, Dimmer und Sensoren. Es geht also voran....
Momentan ist sie deutlich kleiner und transparenter als die Vorgängerversion. Die Anbindung an die HW ist in eine HAL ausgelagert, damit dürfte sie auch leichter zu portieren sein.
Die User Module werden dann eine externe Schnittstelle haben, also egal welchen Sensor man ranhängen möchte, das Modul bleibt das selbe. Die eigentliche Funktionalität kommt vom Main Sketch und nicht mehr aus dem Modul. Beim Relay würde das heissen, es gibt zwei Funktionen im Main Sketch, eine Initialisierung wenn das Modul startet und eine Funktion wird bei Änderungen angesprungen.
Wenn oben beschriebene Funktionalitäten so weit sind, mache ich mich an die PC Software. Ziel ist es, eine Konfigurationssoftware zu entwickeln, in der man die gewünschte Funktionalität des Devices beschreibt und automatisch die register.h und ein Script zur Einbindung in FHEM bekommt. Sich also auf Arduino Seite nur noch um die eigentliche Mess-, Schalt- oder Ausgabefunktionalität kümmern muss.
Zur Zeit baue ich das Ding aber mehr oder weniger allein; Klar, Grundlagenarbeit ist nicht sexy. Aber Aufgrund meiner limitierten Zeit kümmere ich mich halt verstärkt um das Programmieren und nicht ums Dokumentieren. Ich weiß, ohne Doku kann die Lib auch nicht benutzt werden...
Die Frage ist jetzt nur, wenn Du wirklich Interesse hast und dokumentieren möchtest, ob es nicht vernünftiger wäre, mit der NewAskSin zu starten. Die Register Struktur hat sich massiv verändert. Ich lade mal ein Dokument hoch, mit dem ich gestartet habe - vielleicht hilft es dir, die neue Lib Struktur zu verstehen (Seite 35).
Ich bin auch gerne bereit Zeit in die Erklärungen zu investieren, aber zur schönen Aufbereitung fehlt mir halt die Zeit.
Viele Grüße
trilu
Zitat von: trilu am 21 September 2014, 10:39:10
Du hast völlig recht, dass sich die Library für einen produktiven Einsatz derzeit nicht besonders eignet. Das liegt zum Einen an der fehlenden Dokumentation, zum Anderen aber auch an der Library selbst. Der aktuelle Stand ist das Ergebnis meiner nicht vorhandenen Programmierkünste.
Man kann die Lib schon auch für produktive Sachen einsetzen. Allerdings geht das nicht von selbst. Und ohne deine Arbeit daran währen Projekte wie die alternative Firmware für HM_LC_Sw1PBU_FM der AskSin Bootloader oder auch der Universalsensor noch nicht so weit gekommen.
Zitat
Zur Zeit baue ich das Ding aber mehr oder weniger allein;
Wenn du magst, beteilige ich mich hier gerne wieder.
Viele Grüße
Dirk
@Dirk
Ok, ich muss es umformulieren - Die Lib eignet sich für Kenner und Menschen die bereit sind, sich in die Lib einzuarbeiten.
Klar mag ich dass du dich wieder beteiligst! Danke für das Angebot. Wie wäre es, wenn wir es in einem Git machen und ich dich freischalte?
Minor Änderungen und Weiterentwicklung macht jeder allein. Major Themen sprechen wir per Mail oder Chat ab?
Viele Grüße
Horst
Hm, "Kenner" wovon ? Ich entwickele mit meiner Arbeitsgruppe unter anderem extrem komplexe Lernsysteme, bei denen fünf verschiedene Dienste miteinander Nachrichten austauschen, als "Kenner" würde ich mich schon ansehen. Das ist auch keine Frage der Einarbeitung, sondern der fehlenden inneren Systematik der bisherigen AskSin-Software.
Ich bin gerne mit dabei, auch mit "Hilfsarbeiten" wie der Dokumentation. Um einen Anfang zu machen: Es wäre sinnvoll, wenn man ordentliche Sequenzdiagramme hätte, mit den drei Akteuren
Anwendung - (New)AskSin - HM-Zentrale.
Also beispielsweise Aktion Pairing: Was leitet die Anwendung an (New)AskSin, was leitet diese an die Zentrale, was kommt von dort zurück etc. Gerne steuere ich diese Diagramme zur Dokumentation bei.
Betreffend die "neue" Architektur der Software: Ich habe mir das noch nicht angesehen, insofern stochere ich im Nebel. Allerdings frage ich mich, ob solche Dinge wie eine HAL der geringen Performance der ausführenden Mikros angemessen ist. Ich habe die Erfahrung gemacht, dass Programmier-Autodidakten dazu neigen, eher komplexe Lösungen zu bauen. Insofern bin ich auch hier gerne mit Rat und Tat zur Stelle.
Aber erst einmal dokumentieren.
LG
pah
LG
pah
Zitat von: trilu am 21 September 2014, 11:18:56
Klar mag ich dass du dich wieder beteiligst! Danke für das Angebot. Wie wäre es, wenn wir es in einem Git machen und ich dich freischalte?
Minor Änderungen und Weiterentwicklung macht jeder allein. Major Themen sprechen wir per Mail oder Chat ab?
Das klingt gut, Das können wir so machen.
Dann könnte ich auch mal versuchen den Universalsensor-Code zu portieren. Dann haben wir auch gleich ein praktischen Test.
@pah - sorry, wollte dir nicht zu nahe treten - Kenner des HM Protokolls und der Lib.
Die Systematik der AskSin sollte eigentlich nicht die große Rolle spielen, das ist ja etwas, was ich von Modulentwicklern fern halten will.
Schau dir mal die Dummy Class an, alle Messages die für ein Modul relevant sind, werden an den Dummy (Relay, Switch) gerouted und nur diese müssen beantwortet werden. Dokumentation des ganzen ist auch in der Dummy Class drin. Nicht ausführlich aber zumindest als grobe Beschreibung. Standard Messages wie Pairing, Peering, Register read and write, config status, etc. werden autonom von der AskSin beantwortet, also ohne User Eingriff.
Aber wie gesagt, ich wollte in keinster Weise deine fachliche Kompetenz angreifen.
Ich lass dir die Tage mal kommentierte Protokollmitschnitte der Kommunikation zukommen.
Zur HAL, ich denke die HAL ist sogar kleiner und performanter als Arduino. Ich spreche die HW ja direkt an, aber halt aus Funktionsblöcken die in der HAL zusammen laufen. Bei anderer HW wird nur in der HAL ein weiteres Register oder Port oder was auch immer in die Funktion oder Makro eingetragen. Bin aber für Ratschläge dankbar!
@Dirk - Klasse, ich schalte dich frei.
Kannst du beim portieren vom Code Sensor drüber nachdenken wie wir das Messen der Werte in den User Sketch bekommen?
So dass das Sensor Modul möglichst universell wird. Ich stelle mir vor, dass dem Sensor Modul zwei Funktionspointer übergeben werden - einer fürs Init und einer fürs Messen - in der Messfunktion wird dann einfach nur noch ein Array befüllt und an die Sensor Class zurück gegeben. Nutzt du eigentlich irgendeinen Chat, Google, ICQ?
OK, ich schau es mir mal an.
LG
pah
Zitat von: trilu am 22 September 2014, 11:12:26
Kannst du beim portieren vom Code Sensor drüber nachdenken wie wir das Messen der Werte in den User Sketch bekommen?
So dass das Sensor Modul möglichst universell wird. Ich stelle mir vor, dass dem Sensor Modul zwei Funktionspointer übergeben werden - einer fürs Init und einer fürs Messen - in der Messfunktion wird dann einfach nur noch ein Array befüllt und an die Sensor Class zurück gegeben.
ja, das sollte universell gehalten werden. Aber im Moment bekomme ich den Code erst mal nicht kompiliert. Dazu hebe ich das HM_LC_SW1_BA_PCB - Beispiel benutzt.
E:/Projekte/Elektronik/Arduino-Libs/AskSin-Lib_NEW/EEprom.cpp:482: error: pointer of type 'void *' used in arithmetic
E:/Projekte/Elektronik/Arduino-Libs/AskSin-Lib_NEW/EEprom.cpp:482: error: pointer of type 'void *' used in arithmetic
mhhh - das müsste diese zeile sein?
if (*(uint8_t*)(ptr+len-1) != 0) return 0;
sollte aus meiner sicht funktionieren. pointer ist void, ich addiere den wert aus uint8_t und ziehe 1 ab um den pointer zu positionieren.
mit *(uint8_t*) wandle ich den inhalt des pointer zu einem byte wert.
teste mal damit:
uint8_t isEmpty(uint8_t *ptr, uint8_t len) {
do {
if (*(ptr+len-1) != 0) return 0;
len-=1;
} while (len>0);
return 1;
}
Zitat von: trilu am 23 September 2014, 07:57:24
mhhh - das müsste diese zeile sein?
if (*(uint8_t*)(ptr+len-1) != 0) return 0;
sollte aus meiner sicht funktionieren. pointer ist void
Nein, Addition ist auf void nicht definiert. Void kann man eigentlich nur casten und sonst nichts.
Zitatuint8_t isEmpty(uint8_t *ptr, uint8_t len) {
do {
if (*(ptr+len-1) != 0) return 0;
len-=1;
} while (len>0);
return 1;
}
Ist len immer garantiert >0 beim Aufruf? Sonst müsste eine kopfgesteuerte while Schleife her. Ansonsten sollte es so passen.
Grüße, Marcel
Hi Marcel,
ich nutze die Funktion nur um zu Checken, ob ein ByteArray überhaupt einen Wert entält. Void hatte ich eingesetzt um das Ding universal nutzen zu können. Was mir nicht einleuchtet, warum ich zu einem void pointer nichts addieren kann, bzw. warum mein Kompiler nicht gemeckert hat :-)
Viele Grüße
Horst
Zitat von: trilu am 23 September 2014, 10:45:49
ich nutze die Funktion nur um zu Checken, ob ein ByteArray überhaupt einen Wert entält. Void hatte ich eingesetzt um das Ding universal nutzen zu können. Was mir nicht einleuchtet, warum ich zu einem void pointer nichts addieren kann, bzw. warum mein Kompiler nicht gemeckert hat :-)
Naja, +1 auf einen Int32_t* erhöht den Pointer-Wert um 4, da es bei der Addition nicht um Bytes geht sondern um Elemente. Void hat keine Größe, daher ist das nicht definiert. Wieso Dein Compiler nicht gemeckert hat wundert mich aber auch sehr ;-)
Soll der Funktions-Prototyp weiterhin universell bleiben dann musst Du den Cast erst auf den Pointer machen:
uint8_t isEmpty(void *ptr, uint8_t len) {
while (len > 0) {
len--;
if (*((uint8_t*)ptr+len) != 0) return 0;
}
return 1;
}Durch das Vorziehen von len-- sparst Du Dir noch ne Subtraktion. Evtl würde das aber ein optimierender Compiler so oder so machen.
Viele Grüße, Marcel
hättest du nicht lust mit an der asksin zu arbeiten?
so ein codereview und optimierung könnten nicht schaden?
schalte dich auch gerne für den github frei :-)
@pah
Anbei ein Beispiel zur Kommunikation.
So läuft das Pairen mit einem "HM-LC-Sw1-Ba-PCB" (Funk-Schaltaktor, 1fach, Platine, Batterie) ab:
-> 0D 26 84 10 1F B7 4A 00 00 00 06 01 00 80 (342544)
INFO_ACTUATOR_STATUS; cnl: 01, status: 00, na: 80
<- 1A 27 84 00 1F B7 4A 00 00 00 15 00 6C 4B 45 51 30 32 33 37 33 39 36 10 41 01 00 (350420)
DEVICE_INFO; fw: 15, type: 00 6C, serial: 4B 45 51 30 32 33 37 33 39 36
, class: 10, pCnlA: 41, pCnlB: 01, na: 00
-> 10 01 B0 01 63 19 63 1F B7 4A 00 05 00 00 00 00 00 (351263)
CONFIG_START; cnl: 00, peer: 00 00 00, pCnl: 00, lst: 00
<- 0A 01 80 02 1F B7 4A 63 19 63 00 (351382)
ACK
-> 13 02 A0 01 63 19 63 1F B7 4A 00 08 02 01 0A 63 0B 19 0C 63 (351454)
CONFIG_WRITE_INDEX; cnl: 00, data: 02 01 0A 63 0B 19 0C 63
<- 0A 02 80 02 1F B7 4A 63 19 63 00 (351571)
ACK
-> 0B 03 A0 01 63 19 63 1F B7 4A 00 06 (351639)
CONFIG_END; cnl: 00
<- 0A 03 80 02 1F B7 4A 63 19 63 00 (351762)
ACK
-> 10 04 A0 01 63 19 63 1F B7 4A 00 04 00 00 00 00 00 (351834)
CONFIG_PARAM_REQ; cnl: 00, peer: 00 00 00, pCnl: 00, lst: 00
<- 16 04 A0 10 1F B7 4A 63 19 63 02 02 01 05 00 0A 63 0B 19 0C 63 12 69 (351964)
INFO_PARAM_RESPONSE_PAIRS; data: 02 01 05 00 0A 63 0B 19 0C 63 12 69
-> 0A 04 80 02 63 19 63 1F B7 4A 00 (352082)
ACK
<- 0C 05 A0 10 1F B7 4A 63 19 63 02 00 00 (352208)
INFO_PARAM_RESPONSE_PAIRS; data: 00 00
-> 0A 05 80 02 63 19 63 1F B7 4A 00 (352331)
ACK
<- 0C 05 A0 10 1F B7 4A 63 19 63 02 00 00 (352497)
INFO_PARAM_RESPONSE_PAIRS; data: 00 00
-> 0A 05 80 02 63 19 63 1F B7 4A 00 (352618)
ACK
-> 10 0E A0 01 63 19 63 1F B7 4A 01 04 00 00 00 00 01 (352891)
CONFIG_PARAM_REQ; cnl: 01, peer: 00 00 00, pCnl: 00, lst: 01
<- 0C 0E A0 10 1F B7 4A 63 19 63 03 08 00 (353012)
INFO_PARAM_RESPONSE_SEQ; offset: 08, data: 00
-> 0A 0E 80 02 63 19 63 1F B7 4A 00 (353139)
ACK
<- 0C 0F A0 10 1F B7 4A 63 19 63 03 00 00 (353265)
INFO_PARAM_RESPONSE_SEQ; offset: 00, data: 00
-> 0A 0F 80 02 63 19 63 1F B7 4A 00 (353387)
ACK
-> 0B 17 A0 01 63 19 63 1F B7 4A 01 03 (353656)
CONFIG_PEER_LIST_REQ; cnl: 01
<- 0E 17 A0 10 1F B7 4A 63 19 63 01 00 00 00 00 (353783)
INFO_PEER_LIST; peer1: 00 00 00 0000 01 0B 190C 63 12 6910 41 01 00
-> 0A 17 80 02 63 19 63 1F B7 4A 00 (353907)
ACK
Reicht dir das auf dem Level oder brauchst du mehr Kommentare?
Viele Grüße
Horst
Reicht erstmal.
LG
pah
Zitat von: trilu am 23 September 2014, 19:00:20
hättest du nicht lust mit an der asksin zu arbeiten?
so ein codereview und optimierung könnten nicht schaden?
schalte dich auch gerne für den github frei :-)
Ich hab gedacht ich steig ein wenn der ganze Spaß fertig ist ;-) Nein, irgendwann wollte ich mal anfangen eigene Devices mit der Library zu bauen, insofern schau ich gerne mal drüber wenn ich die Zeit finde. Mein GitHub User ist "MarcelKilgus".
Viele Grüße, Marcel
Hallo!
Sorry, wenn ich kurz "unterbreche" - aber ich möchte mir ein Device zusammenbasteln, das mind. 3 Steckdosen schalten kann.
Dazu möchte ich ein Arduino Mini Pro mit 8MhZ und 3,3 Volt verwenden, ein CC1101, und mind. 3 Fets, mit denen ich dann Relais (oder etwas anderes) schalten kann. Dazu möchte ich den CMOS Baustein CD4007 verwenden, der 3 N und 3 P - Fets beinhaltet.
Soweit zu meinem Vorhaben -
Es gibt ja in dem Ordner "Examples" mehrere "Programme" für unterschiedliche Devices:
HM6TastenSwitch = Ein Sensor-Device, das 6 Buttons (Taster) hat und NUR die Schaltbefehle an Aktoren senden kann (?)
HM_LC_SW1_BA_PCB = Ein Sensor/Aktor-Device mit 1 Button (Taster) und einem Schaltausgang (?)
HM_LC_Sw1_Pl = Ein Aktor Device mit einem Schaltausgang (?)
HM_WDS10_TH_O = Wetter-Sensor, ähnlich wie Dirk's Wettersensor (?)
LedLampeRelay = das gleiche wie HM_LC_Sw1_Pl (?)
Ist das so richtig? Könnte man z.B. den Beispiel-Code HM_LC_SW1_BA_PCB auf 3 Sensor/Aktor Ein-und Ausgänge erweitern, indem ich den Code:
button[0].regInHM(0,&hm); // register buttons in HM per channel, handover HM class pointer
button[0].config(8, NULL); // configure button on specific pin and handover a function pointer to the main sketch
relay[0].regInHM(1,&hm);
einfach erweitere???
Danke schonmal für eure Antwort!
Hallo :)
Hat schon jemand versucht, einen Moteino (http://lowpowerlab.com/moteino/) mit der Arduino Asksin Library in ein FHEM System direkt einzubinden? Hat ja auch einen 868 MHz Transceiver eingebaut.
Kosten ca. 12 euro, PIR Sensoren ein paar cent - dann würde man sich nämlich einiges zb. bei den Bewegungssensoren sparen, wenn man sein system plant. :)
Kleine Halb-Off-Topic Frage: Als Sender/Empfänger verwendet man am einfachsten den EQ3 85128 (http://www.amazon.de/gp/product/B00315QNQQ/ref=ox_sc_act_title_3?ie=UTF8&psc=1&smid=A3JWKAKR8XB7XF), oder?
LG Martin
@Schrottpresse - Das mit dem Moteino wird ziemlich aufwendig. Der nutzt ein RF12 Modul, HM nutzt einen CC1101 transceiver.
Ist kein Problem der Frequenz, eher ein Problem der Richtigen Preambel und der automatischen Checksum.
@Thunder 1902
3 Steckdosen schalten, heisst du brauchst 3 mal einen Channel. Folglich musst du zuerst die Register.h anpassen. Das ganze wird per destillregs.pm generiert. Nachfolgend eine Beispielconfig die du durch die destillregs jagen kannst.
use strict;
#Beispiel
# ========================switch =====================================
# battery powered 6 channel switch
# "006C" => {name=>"HM-LC-SW1-BA-PCB" ,st=>'switch' ,cyc=>'' ,rxt=>'b' ,lst=>'3' ,chn=>"",},
# 1 device
# 1 kanal
# 6 peers je kanal erlaubt
#----------------define reglist types-----------------
package usrRegs;
my %listTypes = (
regDev =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
},
regChan =>{ sign =>1, #| literal | | signature (AES) options:on,off
lgActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
lgCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
lgCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
lgCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
lgCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
lgMultiExec =>1, #| literal | required | multiple execution per repeat of long trigger options:on,off
lgOffDly =>1, #| 0 to 111600s | required | off delay
lgOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
lgOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
lgOnDly =>1, #| 0 to 111600s | required | on delay
lgOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
lgOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
lgSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
lgSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
lgSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
lgSwJtOn =>1, #| literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
shActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
shCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
shCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
shCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
shCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
shCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
shCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
shOffDly =>1, #| 0 to 111600s | required | off delay
shOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
shOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
shOnDly =>1, #| 0 to 111600s | required | on delay
shOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
shOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
shSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
shSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
shSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
shSwJtOn =>1, #|
},
);
# -----------assemble device -----------------
my %regList;
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
$regList{2}={type => "regChan",peers=>6};
$regList{3}={type => "regChan",peers=>6};
sub usr_getHash($){
my $hn = shift;
return %regList if($hn eq "regList" );
return %listTypes if($hn eq "listTypes" );
}
Mit dem was dabei rauskommt, weiss die AskSin das es ein Gerät mit drei Schaltkanälen ist.
Jetzt musst du noch den Kanälen das Relay zuordnen...
Von der Relay Class 3 unterschiedliche Instanzen erstellen und diese in der Asksin entsprechen dem Kanal einhängen.
relay[0].regInHM(1,&hm);
relay[1].regInHM(2,&hm);
relay[2].regInHM(3,&hm);
Hab mal über die destillregs gegoogelt und bin auf Deinen Beitrag hier gestossen, den ich hier anhänge...
ZitatIch finde es total cool das du dich an die AskSin lib traust! Mir fehlt im Moment leider ein wenig die Zeit um hier aktiv weiter zu machen.
Wird aber bestimmt wieder, dauert nur noch etwas...
Ich versuche mal ein wenig Licht ins Dunkel zur destillRegs zu bringen.
Mit der destillRegs soll es möglich sein sich automatisch den Inhalt der Register.h generieren zu lassen. Am einfachsten ist es hier, auf ein bestehendes Device aufzubauen. Ich mach das mal am Beispiel eines HM_LC_SW1_BA_PCB.
Zuerst schauen wir uns die Register in FHEM an - das geht mit einem get <euer Device> regList
--- Code: ---list: register | range | peer | description
0: confBtnTime | 1 to 255min | | 255=permanent
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: ledMode | literal | | LED mode options:on,off
0: localResDis | literal | | local reset disable options:on,off
0: lowBatLimitBA | 5 to 15V | | low batterie limit, step .1V
0: pairCentral | 0 to 16777215 | | pairing to central
1: powerUpAction | literal | | behavior on power up options:on,off
1: sign | literal | | signature (AES) options:on,off
1: statusInfoMinDly | 0.5 to 15.5s | | status message min delay
1: statusInfoRandom | 0 to 7s | | status message random delay
1: transmitTryMax | 1 to 10 | | max message re-transmit
3: lgActionType | literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
3: lgCtDlyOff | literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtDlyOn | literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtOff | literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtOn | literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
3: lgCtValHi | 0 to 255 | required | Condition value high for CT table
3: lgCtValLo | 0 to 255 | required | Condition value low for CT table
3: lgMultiExec | literal | required | multiple execution per repeat of long trigger options:on,off
3: lgOffDly | 0 to 111600s | required | off delay
3: lgOffTime | 0 to 111600s | required | off time, 111600 = infinite
3: lgOffTimeMode | literal | required | off time mode options:minimal,absolut
3: lgOnDly | 0 to 111600s | required | on delay
3: lgOnTime | 0 to 111600s | required | on time, 111600 = infinite
3: lgOnTimeMode | literal | required | on time mode options:minimal,absolut
3: lgSwJtDlyOff | literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
3: lgSwJtDlyOn | literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
3: lgSwJtOff | literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
3: lgSwJtOn | literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
3: shActionType | literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
3: shCtDlyOff | literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtDlyOn | literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtOff | literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtOn | literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
3: shCtValHi | 0 to 255 | required | Condition value high for CT table
3: shCtValLo | 0 to 255 | required | Condition value low for CT table
3: shOffDly | 0 to 111600s | required | off delay
3: shOffTime | 0 to 111600s | required | off time, 111600 = infinite
3: shOffTimeMode | literal | required | off time mode options:minimal,absolut
3: shOnDly | 0 to 111600s | required | on delay
3: shOnTime | 0 to 111600s | required | on time, 111600 = infinite
3: shOnTimeMode | literal | required | on time mode options:minimal,absolut
3: shSwJtDlyOff | literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
3: shSwJtDlyOn | literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
3: shSwJtOff | literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
3: shSwJtOn | literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
--- Ende Code ---
Was man jetzt sieht sind die möglichen Register des Devices. Wenn man jetzt erweitern oder verändern möchte,
kann man sich die möglichen Register in der HMConfig.pm ansehen. Wirklich eigene Register würde ich im Moment noch nicht
definieren, da die Einbindung in FHEM gerade im Wettersensor Thread geklärt wird.
In der HMConfig.pm gibts ab Zeile ~250 so was hier
--- Code: ---my %culHmRegDefShLg = (# register that are available for short AND long button press. Will be merged to rgister list at init
#blindActuator mainly
ActionType =>{a=> 10.0,s=>0.2,l=>3,min=>0 ,max=>3 ,c=>'lit' ,f=>'' ,u=>'' ,d=>1,t=>"" ,lit=>{off=>0,jmpToTarget=>1,toggleToCnt=>2,toggleToCntInv=>3}},
OffTimeMode =>{a=> 10.6,s=>0.1,l=>3,min=>0 ,max=>1 ,c=>'lit' ,f=>'' ,u=>'' ,d=>0,t=>"off time mode",lit=>{absolut=>0,minimal=>1}},
OnTimeMode =>{a=> 10.7,s=>0.1,l=>3,min=>0 ,max=>1 ,c=>'lit' ,f=>'' ,u=>'' ,d=>0,t=>"on time mode" ,lit=>{absolut=>0,minimal=>1}},
MaxTimeF =>{a=> 29.0,s=>1.0,l=>3,min=>0 ,max=>25.4 ,c=>'' ,f=>10 ,u=>'s' ,d=>0,t=>"max time first direction"},
DriveMode =>{a=> 31.0,s=>1.0,l=>3,min=>0 ,max=>3 ,c=>'lit' ,f=>'' ,u=>'' ,d=>0,t=>"" ,lit=>{direct=>0,viaUpperEnd=>1,viaLowerEnd=>2,viaNextEnd=>3}},
#dimmer mainly
OnDly =>{a=> 6.0,s=>1.0,l=>3,min=>0 ,max=>111600 ,c=>'fltCvT' ,f=>'' ,u=>'s' ,d=>0,t=>"on delay"},
OnTime =>{a=> 7.0,s=>1.0,l=>3,min=>0 ,max=>111600 ,c=>'fltCvT' ,f=>'' ,u=>'s' ,d=>0,t=>"on time, 111600 = infinite"},
--- Ende Code ---
Das ist die Auflistung der bekannten Registervariablen die über die verschiedenen HM Geräte genutzt werden.
So, aber zurück zur destillRegs und wie es geht - die destillRegs "kompiliert" aus dem Inhalt des Files devDefinition.pm die Inhalte für Register.h
Also müssen jetzt die Inhalte der devDefinition.pm angepasst werden. Der Inhalt sieht dann so aus:
--- Code: ---use strict;
#Beispiel
# ========================switch =====================================
# battery powered 6 channel switch
# "006C" => {name=>"HM-LC-SW1-BA-PCB" ,st=>'switch' ,cyc=>'' ,rxt=>'b' ,lst=>'3' ,chn=>"",},
# 1 device
# 1 kanal
# 6 peers je kanal erlaubt
#----------------define reglist types-----------------
package usrRegs;
my %listTypes = (
regDev =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
},
regChan =>{ sign =>1, #| literal | | signature (AES) options:on,off
lgActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
lgCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
lgCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
lgCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
lgCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
lgMultiExec =>1, #| literal | required | multiple execution per repeat of long trigger options:on,off
lgOffDly =>1, #| 0 to 111600s | required | off delay
lgOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
lgOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
lgOnDly =>1, #| 0 to 111600s | required | on delay
lgOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
lgOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
lgSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
lgSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
lgSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
lgSwJtOn =>1, #| literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
shActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
shCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
shCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
shCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
shCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
shCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
shCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
shOffDly =>1, #| 0 to 111600s | required | off delay
shOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
shOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
shOnDly =>1, #| 0 to 111600s | required | on delay
shOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
shOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
shSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
shSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
shSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
shSwJtOn =>1, #|
},
);
# -----------assemble device -----------------
my %regList;
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
sub usr_getHash($){
my $hn = shift;
return %regList if($hn eq "regList" );
return %listTypes if($hn eq "listTypes" );
}
--- Ende Code ---
Was wurde jetzt definiert?
Ein Gerät mit einem Channel 0 und Channel 1, wobei der Channel 1 Platz für 6 Peers haben soll
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
Channel 0 wird aus der Variable regDev befüllt, Channel 1 aus regList
Wollt ihr jetzt ein Device mit mehr Channel, so muss das hier entsprechend definiert werden - etwa so:
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
$regList{2}={type => "regChan",peers=>6};
$regList{3}={type => "regChan",peers=>6};
Das wäre jetzt ein Device mit 3 Kanälen, die aber alle gleich sind. So würde aus dem Relay Sketch ein 3 Relay Sketch.
Braucht ihr unterschiedliche Variablen für die Kanäle, dann müsst ihr das so machen:
$regList{0}={type => "regDev",peers=>1};
$regList1{1}={type => "regChan",peers=>6};
$regList2{2}={type => "regChan",peers=>6};
Natürlich müsst ihr dann auch die Variablen zur regList1 und regList2 zuordnen. Gleich mehr dazu...
Wenn euch 6 Peers pro Kanal nicht reichen, dann könnt ihr hier entsprechend mehr Platz reservieren.
Aber Vorsicht - pro Peer werden 4 Byte für die Peer Adresse benötigt und zusätzlich die Anzahl der Bytes in List3/4.
In unserem Beispiel sind das 22 byte.
D.h. 26 byte pro Peer, bei einem Dimmer sind das dann etwa 70byte pro Peer. Da wird der EEprom schnell zu klein.
Das Füllen der Variablen ist dieser Teil - ich nehme mal den Channel 0 weil hier nicht so viele Variablen drin sind
--- Code: --- regDev =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
},
--- Ende Code ---
Hier werden dem Kanal 0 folgende Variablen zugewiesen:
intKeyVisib - visibility of internal channel options:visib,invisib (derzeit noch nicht in der AskSin implementiert)
ledMode - LED mode options:on,off
lowBatLimitBA - low batterie limit, step .1V
pairCentral - pairing to central (der muss immer im Kanal 0 sein, sonst kann das Device nicht mit der Zentrale gepairt werden)
Wenn jetzt die devDefinition.pm soweit fertig ist, dann kann man die destillRegs.pl in einer Shell aufrufen.
perl destillRegs.pl
In der Shell bekommt man jetzt den Inhalt für die Register.h
--- Code: ---HM::s_modtable modTbl[] = {
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
}; // 24 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
0x02,0x05,0x0a,0x0b,0x0c,0x12,
0x08,
0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
// 0x02,0x05,0x0a,0x0b,0x0c,0x12,
uint8_t :7; // l:0, s:7
uint8_t intKeyVisib :1; // 0x02, s:7, e:8
uint8_t :6; // l:0, s:6
uint8_t ledMode :2; // 0x05, s:6, e:8
uint8_t pairCentral[3]; // 0x0a, s:0, e:0
uint8_t lowBatLimitBA; // 0x12, s:0, e:0
};
struct s_regChanL1 {
// 0x08,
uint8_t sign :1; // 0x08, s:0, e:1
uint8_t :7; //
};
struct s_regChanL3 {
// 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
uint8_t shCtDlyOn :4; // 0x02, s:0, e:4
uint8_t shCtDlyOff :4; // 0x02, s:4, e:8
uint8_t shCtOn :4; // 0x03, s:0, e:4
uint8_t shCtOff :4; // 0x03, s:4, e:8
uint8_t shCtValLo; // 0x04, s:0, e:0
uint8_t shCtValHi; // 0x05, s:0, e:0
uint8_t shOnDly; // 0x06, s:0, e:0
uint8_t shOnTime; // 0x07, s:0, e:0
uint8_t shOffDly; // 0x08, s:0, e:0
uint8_t shOffTime; // 0x09, s:0, e:0
uint8_t shActionType :2; // 0x0a, s:0, e:2
uint8_t :4; //
uint8_t shOffTimeMode :1; // 0x0a, s:6, e:7
uint8_t shOnTimeMode :1; // 0x0a, s:7, e:8
uint8_t shSwJtOn :4; // 0x0b, s:0, e:4
uint8_t shSwJtOff :4; // 0x0b, s:4, e:8
uint8_t shSwJtDlyOn :4; // 0x0c, s:0, e:4
uint8_t shSwJtDlyOff :4; // 0x0c, s:4, e:8
uint8_t lgCtDlyOn :4; // 0x82, s:0, e:4
uint8_t lgCtDlyOff :4; // 0x82, s:4, e:8
uint8_t lgCtOn :4; // 0x83, s:0, e:4
uint8_t lgCtOff :4; // 0x83, s:4, e:8
uint8_t lgCtValLo; // 0x84, s:0, e:0
uint8_t lgCtValHi; // 0x85, s:0, e:0
uint8_t lgOnDly; // 0x86, s:0, e:0
uint8_t lgOnTime; // 0x87, s:0, e:0
uint8_t lgOffDly; // 0x88, s:0, e:0
uint8_t lgOffTime; // 0x89, s:0, e:0
uint8_t lgActionType :2; // 0x8a, s:0, e:2
uint8_t :3; //
uint8_t lgMultiExec :1; // 0x8a, s:5, e:6
uint8_t lgOffTimeMode :1; // 0x8a, s:6, e:7
uint8_t lgOnTimeMode :1; // 0x8a, s:7, e:8
uint8_t lgSwJtOn :4; // 0x8b, s:0, e:4
uint8_t lgSwJtOff :4; // 0x8b, s:4, e:8
uint8_t lgSwJtDlyOn :4; // 0x8c, s:0, e:4
uint8_t lgSwJtDlyOff :4; // 0x8c, s:4, e:8
};
struct s_regDev {
s_regDevL0 l0;
};
struct s_regChan {
s_regChanL1 l1;
s_regChanL3 l3;
};
struct s_regs {
s_regDev ch0;
s_regChan ch1;
} regs; // 139 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel device list table --------------------------------------------------------------------------------------------
s_cnlDefType cnlDefType[] PROGMEM = {
// cnl, lst, pMax, sIdx, sLen, pAddr, pPeer, *pRegs;
{0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)®s.ch0.l0},
{1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)®s.ch1.l1},
{1, 3, 6, 0x07, 22, 0x0007, 0x0000, (void*)®s.ch1.l3},
}; // 33 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
HM::s_devDef dDef = {
1, 3, sliceStr, cnlDefType,
}; // 6 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- eeprom definition ----------------------------------------------------------------------------------------------------
// define start address and size in eeprom for magicNumber, peerDB, regsDB, userSpace
HM::s_eeprom ee[] = {
{0x0000, 0x0002, 0x001a, 0x00a5,},
{0x0002, 0x0018, 0x008b, 0x0000,},
}; // 16 byte
--- Ende Code ---
Sollten noch Fragen sein, immer gerne :-)
Viele Grüße
Horst
@trilu:
Hab jetzt mal das destillregs.pl mit deiner oben genannten Config aufgerufen: In Deiner Config steht doch eignentlich drin, dass nur 1 Kanal zur Verfügung steht!?!
Zitat# 1 device
# 1 kanal
# 6 peers je kanal erlaubt
Außerdem ist das, was rauskommt - 1:1 identisch mit der devDefinition.pm - HM_LC_SW1_BA_PCB im destillRegs-Verzeichnis...??
Oder muss ich nur die Relay-Classen 3x definieren?
Wie weiß ich , welche PIN's die Schalter und Aktoren auf dem Arduino Mini Pro haben???
Zitat von: thunder1902 am 07 Oktober 2014, 22:46:46
@trilu:
Hab jetzt mal das destillregs.pl mit deiner oben genannten Config aufgerufen: In Deiner Config steht doch eignentlich drin, dass nur 1 Kanal zur Verfügung steht!?!
Außerdem ist das, was rauskommt - 1:1 identisch mit der devDefinition.pm - HM_LC_SW1_BA_PCB im destillRegs-Verzeichnis...??
Oder muss ich nur die Relay-Classen 3x definieren?
Wie weiß ich , welche PIN's die Schalter und Aktoren auf dem Arduino Mini Pro haben???
Glaub ich nicht :-)
# -----------assemble device -----------------
my %regList;
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
$regList{2}={type => "regChan",peers=>6};
$regList{3}={type => "regChan",peers=>6};
Die Zeilen machen den Unterschied.
$regList{2} damit wird Kanal 2 definiert. Kanal zwei bekommt die selben Register wie Kanal 1 zugewiesen, aber in einem eigenen Speicherbereich.
$regList{3} siehe 2
Damit erstellst du aber nur die Register, jetzt musst du mit den Registern noch irgendwas anfangen. Das passiert mit den Channel Modulen - in deinem Fall mit der Relay Class.
relay[0].regInHM(1,&hm);
relay[1].regInHM(2,&hm);
relay[2].regInHM(3,&hm);
Über die Funktion regInHM werden die Class Module in Asksin einem Kanal zugewiesen. Das ist der erste Wert in der Klammer...
Der nächste Schritt ist, du weißt der Relay Class die entsprechenden Pins zu...
void MyClassName::config(uint8_t type, uint8_t pinOn, uint8_t pinOff, uint8_t minDelay, uint8_t randomDelay) {
// store config settings in class
hwType = type; // 0 indicates a monostable, 1 a bistable relay
hwPin[0] = pinOn; // first byte for on, second for off
hwPin[1] = pinOff;
mDel = minDelay; // remember minimum delay for sending the status
rDel = (randomDelay)?randomDelay:1; // remember random delay for sending the status
Bei monostable, wird nur pinOn genutzt. Das ganze folgt der Arduino Pin Nummerierung.
Die Pins müssten eigentlich auf deinem Arduino aufgedruckt sein...
Viele Grüße
Horst
Hallo trilu,
ist zwar etwas offtopic aber...
um mehrere Variablen auf die Serielle Konsole auszugeben wird zb. das hier verwendet:
Serial << F("s: ") << pHexL(hm.send.data, hm.send.data[0]+1) << '\n';
Das ist sehr praktisch :-)
Das obige habe ich bei einem neuem Sketch versucht, aber "Serial" kennt "<<" nicht. Denke mir fehlt da eine Bibliothek die eingebunden werden muss ?
Kannst Du das kurz erklären ?
Grüsse Martin
Hi Martin,
das mit der Serial ist einfach...
Dieses Template muss irgendwo in deinem Sketch sein:
template<class T> inline Print &operator <<(Print &obj, T arg) { obj.print(arg); return obj; }
Um sowas wie pHex nutzen zu können, brauchst du folgende Makros:
#define pHexB(x) char((x>>4)>9?(x>>4)+55:(x>>4)+48)<< char((x&0xF)>9?(x&0xF)+55:(x&0xF)+48)
#define pHex(x,y) char(0);for(uint8_t i=0;i<y;i++)dbg<<pHexB(x
)<<char(i+1<y?32:0);dbg<<char(0)
Viele Grüße
Horst
Hallo Trilu,
ich hab die Schritte jetzt alle nochmals probiert - und habe immer noch folgendes Problem:
Was habe ich bis jetzt gemacht?
1. Dein Beispiel von oben (3-Kanal Schalter) durch die destillreg gejagt. Als Ergebnis habe ich folgenden Text erhalten, der 1:1 mit dem entsprechenden Teil in der Register.h im HM_LC_SW1_BA_PCB- example Verzeichnis ist. 3
Zitat
HM::s_modtable modTbl[] = {
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
}; // 24 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
0x02,0x05,0x0a,0x0b,0x0c,0x12,
0x08,
0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
// 0x02,0x05,0x0a,0x0b,0x0c,0x12,
uint8_t :7; // l:0, s:7
uint8_t intKeyVisib :1; // 0x02, s:7, e:8
uint8_t :6; // l:0, s:6
uint8_t ledMode :2; // 0x05, s:6, e:8
uint8_t pairCentral[3]; // 0x0a, s:0, e:0
uint8_t lowBatLimitBA; // 0x12, s:0, e:0
};
struct s_regChanL1 {
// 0x08,
uint8_t sign :1; // 0x08, s:0, e:1
uint8_t :7; //
};
struct s_regChanL3 {
// 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
uint8_t shCtDlyOn :4; // 0x02, s:0, e:4
uint8_t shCtDlyOff :4; // 0x02, s:4, e:8
uint8_t shCtOn :4; // 0x03, s:0, e:4
uint8_t shCtOff :4; // 0x03, s:4, e:8
uint8_t shCtValLo; // 0x04, s:0, e:0
uint8_t shCtValHi; // 0x05, s:0, e:0
uint8_t shOnDly; // 0x06, s:0, e:0
uint8_t shOnTime; // 0x07, s:0, e:0
uint8_t shOffDly; // 0x08, s:0, e:0
uint8_t shOffTime; // 0x09, s:0, e:0
uint8_t shActionType :2; // 0x0a, s:0, e:2
uint8_t :4; //
uint8_t shOffTimeMode :1; // 0x0a, s:6, e:7
uint8_t shOnTimeMode :1; // 0x0a, s:7, e:8
uint8_t shSwJtOn :4; // 0x0b, s:0, e:4
uint8_t shSwJtOff :4; // 0x0b, s:4, e:8
uint8_t shSwJtDlyOn :4; // 0x0c, s:0, e:4
uint8_t shSwJtDlyOff :4; // 0x0c, s:4, e:8
uint8_t lgCtDlyOn :4; // 0x82, s:0, e:4
uint8_t lgCtDlyOff :4; // 0x82, s:4, e:8
uint8_t lgCtOn :4; // 0x83, s:0, e:4
uint8_t lgCtOff :4; // 0x83, s:4, e:8
uint8_t lgCtValLo; // 0x84, s:0, e:0
uint8_t lgCtValHi; // 0x85, s:0, e:0
uint8_t lgOnDly; // 0x86, s:0, e:0
uint8_t lgOnTime; // 0x87, s:0, e:0
uint8_t lgOffDly; // 0x88, s:0, e:0
uint8_t lgOffTime; // 0x89, s:0, e:0
uint8_t lgActionType :2; // 0x8a, s:0, e:2
uint8_t :3; //
uint8_t lgMultiExec :1; // 0x8a, s:5, e:6
uint8_t lgOffTimeMode :1; // 0x8a, s:6, e:7
uint8_t lgOnTimeMode :1; // 0x8a, s:7, e:8
uint8_t lgSwJtOn :4; // 0x8b, s:0, e:4
uint8_t lgSwJtOff :4; // 0x8b, s:4, e:8
uint8_t lgSwJtDlyOn :4; // 0x8c, s:0, e:4
uint8_t lgSwJtDlyOff :4; // 0x8c, s:4, e:8
};
struct s_regDev {
s_regDevL0 l0;
};
struct s_regChan {
s_regChanL1 l1;
s_regChanL3 l3;
};
struct s_regs {
s_regDev ch0;
s_regChan ch1;
} regs; // 139 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel device list table --------------------------------------------------------------------------------------------
s_cnlDefType cnlDefType[] PROGMEM = {
// cnl, lst, pMax, sIdx, sLen, pAddr, pPeer, *pRegs; // pointer to regs structure
{0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)®s.ch0.l0},
{1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)®s.ch1.l1},
{1, 3, 6, 0x07, 22, 0x0007, 0x0000, (void*)®s.ch1.l3},
}; // 33 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
HM::s_devDef dDef = {
1, 3, sliceStr, cnlDefType,
}; // 6 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- eeprom definition ----------------------------------------------------------------------------------------------------
// define start address and size in eeprom for magicNumber, peerDB, regsDB, userSpace
HM::s_eeprom ee[] = {
{0x0000, 0x0002, 0x001a, 0x00a5,},
{0x0002, 0x0018, 0x008b, 0x0000,},
}; // 16 byte
Irgendwas ist da schief gelaufen, da die destilreg ja keine Änderungen macht..??
Kannst du mir da sagen was ich falsch mache???
keine ahnung was da schief läuft...
also, du nimmst das file "devDefinition.pm", da muss dieser content rein:
use strict;
#Beispiel
# ========================switch =====================================
#
# "006C" => {name=>"HM-LC-SW1-BA-PCB" ,st=>'switch' ,cyc=>'' ,rxt=>'b' ,lst=>'3' ,chn=>"",},
# 1 device
# 1 kanal
# 6 peers je kanal erlaubt
#----------------define reglist types-----------------
package usrRegs;
my %listTypes = (
regDev =>{ intKeyVisib=>1, ledMode=>1, lowBatLimitBA=>1, pairCentral=>1,
},
regChan =>{ sign =>1, #| literal | | signature (AES) options:on,off
lgActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
lgCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
lgCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
lgCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
lgCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
lgCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
lgMultiExec =>1, #| literal | required | multiple execution per repeat of long trigger options:on,off
lgOffDly =>1, #| 0 to 111600s | required | off delay
lgOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
lgOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
lgOnDly =>1, #| 0 to 111600s | required | on delay
lgOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
lgOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
lgSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
lgSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
lgSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
lgSwJtOn =>1, #| literal | required | Jump from on options:on,off,dlyOn,no,dlyOff
shActionType =>1, #| literal | required | options:toggleToCntInv,off,toggleToCnt,jmpToTarget
shCtDlyOff =>1, #| literal | required | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
shCtDlyOn =>1, #| literal | required | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
shCtOff =>1, #| literal | required | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
shCtOn =>1, #| literal | required | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
shCtValHi =>1, #| 0 to 255 | required | Condition value high for CT table
shCtValLo =>1, #| 0 to 255 | required | Condition value low for CT table
shOffDly =>1, #| 0 to 111600s | required | off delay
shOffTime =>1, #| 0 to 111600s | required | off time, 111600 = infinite
shOffTimeMode =>1, #| literal | required | off time mode options:minimal,absolut
shOnDly =>1, #| 0 to 111600s | required | on delay
shOnTime =>1, #| 0 to 111600s | required | on time, 111600 = infinite
shOnTimeMode =>1, #| literal | required | on time mode options:minimal,absolut
shSwJtDlyOff =>1, #| literal | required | Jump from delayOff options:on,off,dlyOn,no,dlyOff
shSwJtDlyOn =>1, #| literal | required | Jump from delayOn options:on,off,dlyOn,no,dlyOff
shSwJtOff =>1, #| literal | required | Jump from off options:on,off,dlyOn,no,dlyOff
shSwJtOn =>1, #|
},
);
# -----------assemble device -----------------
my %regList;
$regList{0}={type => "regDev",peers=>1};
$regList{1}={type => "regChan",peers=>6};
$regList{2}={type => "regChan",peers=>6};
$regList{3}={type => "regChan",peers=>6};
$regList{4}={type => "regChan",peers=>6};
sub usr_getHash($){
my $hn = shift;
return %regList if($hn eq "regList" );
return %listTypes if($hn eq "listTypes" );
}
danach abspeichern, wieder öffnen und kontrollieren ob das auch wirklich der inhalt des files ist.
jetzt eine shell öffnen, in das verzeichnis mit dem file wechseln...
jetzt das in die kommandozeile eingeben:
destillRegs.pl devDefinition.pm
danach return drücken - führt zu diesem output:
HM::s_modtable modTbl[] = {
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
{0,0,(s_mod_dlgt)NULL},
}; // 72 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice definition ---------------------------------------------------------------------------------------------
uint8_t sliceStr[] = {
0x02,0x05,0x0a,0x0b,0x0c,0x12,
0x08,
0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- Channel device config ------------------------------------------------------------------------------------------------
struct s_regDevL0 {
// 0x02,0x05,0x0a,0x0b,0x0c,0x12,
uint8_t :7; // l:0, s:7
uint8_t intKeyVisib :1; // 0x02, s:7, e:8
uint8_t :6; // l:0, s:6
uint8_t ledMode :2; // 0x05, s:6, e:8
uint8_t pairCentral[3]; // 0x0a, s:0, e:0
uint8_t lowBatLimitBA; // 0x12, s:0, e:0
};
struct s_regChanL1 {
// 0x08,
uint8_t sign :1; // 0x08, s:0, e:1
uint8_t :7; //
};
struct s_regChanL3 {
// 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
uint8_t shCtDlyOn :4; // 0x02, s:0, e:4
uint8_t shCtDlyOff :4; // 0x02, s:4, e:8
uint8_t shCtOn :4; // 0x03, s:0, e:4
uint8_t shCtOff :4; // 0x03, s:4, e:8
uint8_t shCtValLo; // 0x04, s:0, e:0
uint8_t shCtValHi; // 0x05, s:0, e:0
uint8_t shOnDly; // 0x06, s:0, e:0
uint8_t shOnTime; // 0x07, s:0, e:0
uint8_t shOffDly; // 0x08, s:0, e:0
uint8_t shOffTime; // 0x09, s:0, e:0
uint8_t shActionType :2; // 0x0a, s:0, e:2
uint8_t :4; //
uint8_t shOffTimeMode :1; // 0x0a, s:6, e:7
uint8_t shOnTimeMode :1; // 0x0a, s:7, e:8
uint8_t shSwJtOn :4; // 0x0b, s:0, e:4
uint8_t shSwJtOff :4; // 0x0b, s:4, e:8
uint8_t shSwJtDlyOn :4; // 0x0c, s:0, e:4
uint8_t shSwJtDlyOff :4; // 0x0c, s:4, e:8
uint8_t lgCtDlyOn :4; // 0x82, s:0, e:4
uint8_t lgCtDlyOff :4; // 0x82, s:4, e:8
uint8_t lgCtOn :4; // 0x83, s:0, e:4
uint8_t lgCtOff :4; // 0x83, s:4, e:8
uint8_t lgCtValLo; // 0x84, s:0, e:0
uint8_t lgCtValHi; // 0x85, s:0, e:0
uint8_t lgOnDly; // 0x86, s:0, e:0
uint8_t lgOnTime; // 0x87, s:0, e:0
uint8_t lgOffDly; // 0x88, s:0, e:0
uint8_t lgOffTime; // 0x89, s:0, e:0
uint8_t lgActionType :2; // 0x8a, s:0, e:2
uint8_t :3; //
uint8_t lgMultiExec :1; // 0x8a, s:5, e:6
uint8_t lgOffTimeMode :1; // 0x8a, s:6, e:7
uint8_t lgOnTimeMode :1; // 0x8a, s:7, e:8
uint8_t lgSwJtOn :4; // 0x8b, s:0, e:4
uint8_t lgSwJtOff :4; // 0x8b, s:4, e:8
uint8_t lgSwJtDlyOn :4; // 0x8c, s:0, e:4
uint8_t lgSwJtDlyOff :4; // 0x8c, s:4, e:8
};
struct s_regDev {
s_regDevL0 l0;
};
struct s_regChan {
s_regChanL1 l1;
s_regChanL3 l3;
};
struct s_regs {
s_regDev ch0;
s_regChan ch1;
s_regChan ch2;
s_regChan ch3;
s_regChan ch4;
} regs; // 538 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- channel device list table --------------------------------------------------------------------------------------------
s_cnlDefType cnlDefType[] PROGMEM = {
// cnl, lst, pMax, sIdx, sLen, pAddr, pPeer, *pRegs;
{0, 0, 0, 0x00, 6, 0x0000, 0x0000, (void*)®s.ch0.l0},
{1, 1, 0, 0x06, 1, 0x0006, 0x0000, (void*)®s.ch1.l1},
{1, 3, 6, 0x07, 22, 0x0007, 0x0000, (void*)®s.ch1.l3},
{2, 1, 0, 0x06, 1, 0x008b, 0x0000, (void*)®s.ch2.l1},
{2, 3, 6, 0x07, 22, 0x008c, 0x0018, (void*)®s.ch2.l3},
{3, 1, 0, 0x06, 1, 0x0110, 0x0000, (void*)®s.ch3.l1},
{3, 3, 6, 0x07, 22, 0x0111, 0x0030, (void*)®s.ch3.l3},
{4, 1, 0, 0x06, 1, 0x0195, 0x0000, (void*)®s.ch4.l1},
{4, 3, 6, 0x07, 22, 0x0196, 0x0048, (void*)®s.ch4.l3},
}; // 99 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
HM::s_devDef dDef = {
4, 9, sliceStr, cnlDefType,
}; // 6 byte
//- ----------------------------------------------------------------------------------------------------------------------
//- eeprom definition ----------------------------------------------------------------------------------------------------
// define start address and size in eeprom for magicNumber, peerDB, regsDB, userSpace
HM::s_eeprom ee[] = {
{0x0000, 0x0002, 0x0062, 0x027c,},
{0x0002, 0x0060, 0x021a, 0x0000,},
}; // 16 byte
viele grüße
trilu
Lieber trilu,
Erst mal danke für die pHex Erklärung.
Ich spiele gerade mit der "alten" Libary herum.
Mit dem Ziel einfach ein paar Daten über ein Device an FHEM zu senden.
Dafür nutze ich die dirrekt CC110x Klasse der Libary.
Mit ein paar Zeilen Code einfach 3 Bytes an FHEM senden:
CC110x cc;
uint8_t buffer[]={0x02,0xFF,0xAA};
uint8_t burst=0;
void setup()
{
Serial.begin(9600);
cc.config(10,11,12,13,2,0); // set the respective pins
cc.init();
}
void loop()
{
delay(60000);
cc.sendData(buffer,burst);
}
wenn ich nun die Rohdaten in die ich mit FHEM anschaue bekomme ich:
CUL_0: unknown message A028908
A: könnte den Empfang darstellen
02: Anzahl der Bytes
89: ? -> sollte FF ???
08: ? -> sollte AA ???
Weisst Du wie die 89 und 08 zustande kommen ?
Grüsse Martin
Hi Martin,
das wird so einfach nicht funktionieren.
HM sendet verschlüsselt und entschlüsselt nach dem Empfang.
D.h. deine Bytes sind entschlüsselt worden und damit natürlich Käse.
Du musst zumindest diese Funktion vorher aufrufen...
void HM::hm_enc(uint8_t *buf);
Übergibst deinen Send Buffer, also das Array.
Das erste Byte im Array bestimmt die Länge!
In deinem Fall musst du also 4 Byte senden. {0x03, 0x02,0xFF,0xAA}
Viele Grüße
Horst
Hallo trilu,
verschlüsselt ... ;D
Ja, mit der Funktion HM::hm_enc(uint8_t *buf) klappt es nun :)
Hab zuerst gedacht, dass da was beim Senden schief geht.
Danke Dir, und wünsch noch nen schönen Abend.
Grüsse Martin
@all
In der NewAskSin gibt es jetzt eine Dimmer Class - Funktioniert soweit schon recht ordentlich auf dem Schreibtisch.
Der Dimmer basiert auf den Registererstellungen von einem existierenden LED Dimmer. Hat also mehr Register, als der HM Phasenanschnitt Dimmer.
Pair & Peer läuft, Defaults werden gesetzt. Nutze allerdings noch nicht alle Variablen die durch die List3 angeboten werden.
Zum Teil weiß ich auch nicht was sie bedeuten. Größtenteils habe ich das verhalten von einem existierenden Dimmer nachgeahmt.
Die Verknüpfung mit den virtuellen Channels habe ich auch nicht implementiert, da sich mir der Nutzen noch nicht erschließt.
List1 Inhalte habe ich über die HM Config Soft gesetzt. Verknüpfung mit einem 6-Fach Schalter auch.
Zum testen benötigt ihr eine Led die an PD3 (http://giltesa.com/wp-content/uploads/2014/02/arduino-pinouts.jpg) gegen Masse
angeschlossen wird. Zum Pairen kann man eine Taste an PB8 gegen Masse anschliessen. Langer Tastendruck sendet dann den Pair String an
den Master. Weiterhin habe ich eine ZweifarbLED für die Statuserkennung angeschlossen. Die Pins für die LED sind PD4 und PD6 gegen Masse.
Alles in allem ist die NewAskSin deutlich kleiner geworden. destillRegs.pl überarbeite ich gerade, funktioniert also noch nicht...
Viel Spass beim testen!
Falls ihr Fehler findet, wäre es nett wenn ihr die entsprechenden Logs der seriellen Konsole hier einstellt mit einer kurzen Beschreibung des Fehlers,
bzw. dem Verhalten wie es sein soll...
Die NewAskSin bekommt ihr hier: https://github.com/trilu2000/NewAskSin
Ich kompiliere unter Arduino 1.5.7 mit Visual Micro plugin (http://www.visualmicro.com/) in Atmel Studio 6
Unter Arduino 1.0 kommt es zu fehlern....
Ich frage mich gerade ob es Sinn machen würde, für die NewAskSin einen neuen Thread aufzumachen. Das ist die Lib die ich weiter entwickeln möchte...
Dokumentation ist begonnen, aber auch noch nicht vorzeige fähig. Wer mit entwickeln möchte, bekommt gerne Schreibrechte für den GIT.
Nächste User Module sind, Switch Class zum Aufbau von 2 und 6 Fach Schaltern und eine universelle Sensor Class, bei der HW unabhängig Messwerte
genutzt werden können.
Viele Grüße
Horst
Hallo,
wollte mich nur mal "melden" - die letzten Wochen musste ich mich leider mit ganz anderen Dingen beschäftigen. Ich hoffe ich kann die neue Lib bald mal ausprobieren.
Freut mich dass immer noch daran gearbeitet wird! Es kommt auch wieder die Zeit, in der ich genügend Freizeit zum rumbasteln habe...
VG!
Hallo Horst,
zu mehr als einer oberflächlichen Durchsicht hat es mir bisher leider nicht gereicht (Baby, Hauskauf und so Späße haben gerade Prio), aber soweit sah die Sache wirklich sehr strukturiert und sauber aus. Hattest Du nicht irgendwann mal betont dass Du nicht vom Fach bist? Und dann sehe ich da Konzepte wie Delegates in C++ sowie einen absolut syntaktisch sauberen und durchgängig dokumentierten Code und kann's gar nicht wirklich glauben ;-)
Ich hab hier auf jeden Fall noch zwei PanStamps rumliegen die ganz gespannt auf Deine Library warten, hoffe ich komme da irgendwann mal dazu...
Danke für die Arbeit und viele Grüße, Marcel
Hi Marcel,
herzlichen Glückwunsch zu Baby und Haus, jetzt fehlt ja nur noch die Sache mit dem Baum :-)
Ja, habe vor 2 Jahren begonnen mich mit Proggen zu beschäftigen. Struktur ist das Einzige das mir hilft nicht die Übersicht zu verlieren ... Aber Danke für die Blumen!
Viel Spass beim testen und hoffentlich auf ganz viel Input.
Viele Grüße
Horst
Hallo trilu,
Ich finde es klasse, das Du nach eimem Jahr immer noch so motiviert bist, die Libary weiter zu enwickeln.
Freue mich schon, auf Experimente mit der neuen Libary.
Denke, in den Weihnachsferien wird es nicht langweilig :-)
Ich habe da noch eine Frage, welche noch die "alte" Libary betrifft.
Im Powermode3 wird das CC1101 Module mit der Funktion "void CC110x::setPowerDownState()" abgeschaltet und so schlafen gelegt.
Ich nehme an, nachdem ich obige Funktion aufgerufen habe, kann das CC1101 Module weder empfangen noch senden.
Wie wird das CC110 Module wieder aktiviert, um nach Aufruf obiger Funktion Daten zu senden oder zu empfangen ?
Wie funktioniert das ?
Grüsse Martin
Hi Martin,
aufwecken geht mit detect burst.
uint8_t CC110x::detectBurst(void) { // wake up CC1101 from power down state
// 10 7/10 5 in front of the received string; 33 after received string
// 10 - 00001010 - sync word found
// 7 - 00000111 - GDO0 = 1, GDO2 = 1
// 5 - 00000101 - GDO0 = 1, GDO2 = 1
// 33 - 00100001 - GDO0 = 1, preamble quality reached
// 96 - 01100000 - burst sent
// 48 - 00110000 - in receive mode
//
// Status byte table:
// 0 current GDO0 value
// 1 reserved
// 2 GDO2
// 3 sync word found
// 4 channel is clear
// 5 preamble quality reached
// 6 carrier sense
// 7 CRC ok
//
// possible solution for finding a burst is to check for bit 6, carrier sense
// set RXTX module in receive mode
cc1101_Select(); // select CC1101
wait_Miso(); // wait until MISO goes low
cc1101_Deselect(); // deselect CC1101
cmdStrobe(CC1101_SRX); // set RX mode again
delay(3); // wait a short time to set RX mode
// todo: check carrier sense for 5ms to avoid wakeup due to normal transmition
//Serial << "rx\n";
// return bitRead(hm.cc.monitorStatus(),6); // return the detected signal
return bitRead(monitorStatus(),6); // return the detected signal
}
Das ist die Funktion aus der alten Lib. In der Neuen habe ich es etwas anders gemacht, braucht dann nicht mehr so viel Zeit und ist damit energie sparender...
Viele Grüße
Horst
@trilu: Mit Freude entdecke ich deine neue Version der AskSin Lib und hoffte auf eine Verbesserung beim Pairing , weil ich mit der alten Version immer ein Dauerblinken der Status LED nach erfolgreichem Pairing bekomme. Dann half immer nur ein Reset (Arduino Strom aus/an). Mit der neuen Version funktionierte das Pairen auch wunderbar, wie bei den originalen Produkten.
Schade finde ich aber bei der neuen Version die vielen neuen "sophisticated" Aufrufe innerhalb des *.ino projects, wie "power_usart0_enable();", oder "regPCINT(PCMSK0,PCINT0);", das sollte in der Lib gekapselt bleiben. Ich glaube, das entspricht nicht der Arduino Philosophy. Ich weiß ja, dass du die ganze Mikroprozessor-Welt jetzt besser verstehst, aber als Arduino User will man eher auf "Do what I mean" Ebene bleiben. Lib einbinden und verständlich zusammen klimpern, was das Device machen soll.
Was ich eigentlich frage wollte ist: Leider kann ich zusammen mit der neuen Version nicht mehr die Arduino-Lib IRremote benutzen. https://github.com/shirriff/Arduino-IRremote. Vermutlich benutzt du jetzt die selben Timer, Interrupts, Ports oder was auch immer und die IRremote kann damit jetzt nix mehr senden. Ich baue gerade an einem kleinem Device, was per FHEM ein Gerät mittels IR ein/aus schalten soll und dabei auch den aktuellen Zustand übermittelt. Also Beamer einschalten und solange weiter senden, bis das Gerät an ist (5V am USB) und dann den Status des Beamers (an oder aus) zyklisch an FHEM übermitteln. Mit der alten Lib habe ich das wunderbar hinbekommen, nur die neue Lib verträgt sich nicht mit der IRremote Lib. Hast du eine Ahnung warum? Ich würde gerne die neue Version benutzen, weil sie die Batteriespannungsabfrage dabei hat, das Pairen auch als beendet von der LED angezeigt wird und weil ich denke, dass sie für meinen Anwendungsfall stromsparender ist.
Übrigens: die neue Lib bekomme ich unter der Arduino IDE 1.0.5 kompiliert, wenn ich statt:
HAL.CPP
struct s_pcINT {
uint8_t cur = 0xff;
uint8_t prev = 0xff;
uint32_t time;
} static volatile pcInt[3];
das dafür ersetze:
struct s_pcINT {
uint8_t cur;
uint8_t prev;
uint32_t time;
} static volatile pcInt[3];
Danke für das Feedback.
Die "sophisticated" Aufrufe im main sketch sind nicht zwingend. Alles wesentliche für die Hardware, also Anbindung der Led,
des Funkmoduls, usw. finden in der HAL statt. Die Portsettings im main sketch kann man genauso gut über digitalwrite usw. erledigen.
Zur IR-Remote
Eigentlich dürfte nichts von der IR lib mit Asksin kollidieren.
IR nutzt per default den Timer2, Asksin nutzt Timer0 für die Zeitmessung.
IRremoteInt.h
// Arduino Duemilanove, Diecimila, LilyPad, Mini, Fio, etc
#else
//#define IR_USE_TIMER1 // tx = pin 9
#define IR_USE_TIMER2 // tx = pin 3
#endif
Ich kann mir nur vorstellen, dass du im Main sketch den timer2 noch abgeschaltet hast.
Ergänze den main sketch mal bitte um power_timer2_enable();
Dann sollte es eigentlich gehen.
An welchem Port hängt dein IR Empfänger?
Ach ja und um zu testen würde ich immer das Stromsparen abschalten, also hm.pw.setMode(0);
Viele Grüße
Horst
Hallo Horst,
danke für deine Lösungsvorschläge. Mit power_timer2_enable(); funktioniert es jetzt. Die IR-LED hängt am PIN3.
Leider musste ich mich aber auch von der Komfort-Funktion delay(ms) verabschieden. Aber zum Glück konnte ich deinen waitTimer dafür benutzen, nach etwas Umbauen.
Viele Grüße
Mario
Mein Device wäre jetzt fertig und ich könnte es nutzen, leider musste ich feststellen, dass der Stromverbrauch viel zu hoch ist 15-20mA. Da ist die Batterie im Nu leer.
Mit dem RelaySketch (NewAskSin) liege ich auch bei 15mA, egal welcher Powermode. Auch wenn ich das CC1101 Modul abklemme, braucht der Relay-Sketch 3mA. Ich nutze Arduino Pro Mini 3,3V 8 MHz, Power LED abgeklemmt, 2xR03 Batterie an VCC/GND)
Mit dem Power Down Demo ( http://www.rocketscream.com/blog/2011/04/26/mini-ultra-8-mhz-current-consumption-part-2 )
komme ich auf 11µA runter, was mir zeigt, dass mein Messungen und das Board soweit okay ist.
Habt ihr noch Ideen, wo mein Fehler beim NewAskSin/HM_LC_SW1_BA_PCB ist? Alle Debug Defines habe ich auch rausgeschmissen.
Ich habe etwas geforscht. Es scheint etwas in der Power Class noch nicht optimal zu sein.
void PW::poll(void) {
.
// hier springt er immer raus, weil der Timer nie done wird
if (!pwrTmr.done()) return;
void PW::stayAwake(uint16_t time) {
// Das auskommentiert hilft, um den Timer ordentlich laufen zu lassen
//if (time < pwrTmr.remain()) return;
pwrTmr.set(time);
}
Vermutlich ist eine Variable nicht initial gesetzt und hat einen Zufallswert (zufälliger Speicherinhalt)
Damit komme ich nach einigen Sekunden warten von 22,7mA auf 0,4-0,7mA (schnell schwankend) runter.
Schon mal was ...
Aber der Anfangsstrom von 23mA ist bei mir einfach zuviel, damit ich 2xAAA Batterien benutzen kann. Damit startet die Schaltung nicht und die LED am Pin 6 blinkt dauernd schnell.
void PW::stayAwake(uint16_t time) {
// Das auskommentiert hilft, um den Timer ordentlich laufen zu lassen
//if (time < pwrTmr.remain()) return;
pwrTmr.set(time);
}
Auskommentieren ist keine gute Idee. Hier prüfe ich, ob bereits eine Wachzeit gesetzt ist und diese länger ist, als die die neu eingestellt werden soll.
Das Verhalten vom Relay Sketch stimmt so. Nach dem Booten bleibt der Sketch für 20 Sekunden wach und die Led blinkt.
Könnte man ändern um Strom zu sparen, aber so oft bootet ja das Device nicht.
Zitat0,4-0,7mA (schnell schwankend)
Das Schwanken kommt daher, das der Relay Sketch alle 250ms aufwacht, um zu prüfen ob ein Trägersignal aktiv ist, um gegebenenfalls einen Schaltbefehl zu empfangen. Wobei die 0,4ma aber immer noch sehr hoch sind. Vermutlich nutzt du einen Arduino Pro Mini und der Spannungsregler ist noch auf dem Board, oder die Led am SPI Bus die munter vor sich hin blinkt.
Bei meinem Test mit einem Panstamp, also ohne Spannungsregler und Led am SPI Bus bin ich auf eine theoretische Standby Zeit von 2 Jahren gekommen. Abhängig natürlich von der Kapazität der Batterien und der Schaltvorgänge. Ich bin von 2000ma Batterien ausgegangen. Kann aber heute Abend noch einmal das Messgerät dran hängen.
Die Frage ist aber auch, ob es für deine Anwendung nötig ist, das Funkmodul in den Lauschmodus zu schalten. Was ich verstanden habe, möchtest du IR Signale empfangen und dann weiter senden. Dazu würde ich einen Powermode ohne Empfangsmöglichkeit verwenden. Also Mode 2 oder 3.
// 0 - 19.9ma; no power management
// 1 - wake up every 250ms, check for wakeup signal on air and stay awake accordingly, timer gets updated every 250ms
// 2 - deep sleep, wakeup every 250ms, not able to receive anything while sleeping, timer gets updated every 256ms
// 3 - 0.04ma; deep sleep, wakeup every 8 seconds, not able to receive anything while sleeping, timer gets updated every 8192ms
// 4 - 0.00ma; deep sleep, wakeup only on interrupt
Das sind die implementierten Powermodes. Mode 4 habe ich für Schalter vorgesehen. Hier schläft das Gerät komplett, bis eine Taste gedrückt wird, also ein Interrupt ausgelöst wird. Dann kann man einen Schaltbefehl senden, auf ACK warten und dann schläft das Gerät wieder bis zum nächsten Interrupt.
In Mode 2 und 3 wacht das Gerät regelmäßig auf und setzt die Systemzeit. Eignet sich gut für Sensoren. Durch das regelmäßige Aufwachen kann man kontinuierlich einen Meßwert lesen und bei Bedarf senden. Empfang muss explizit eingeschaltet werden.
Mode 1 ist speziell für batteriebetriebene Schaltaktoren, hier wird auf ein Burstsignal gewartet. Dazu muss das Funkmodul alle 250ms eingeschaltet werden, was der eigentliche Batteriefresser ist.
Bei deinem IR Device sehe ich nur eine Schwierigkeit. Soweit ich weiß, basiert der IR Sketch auf einem Timer und einem Interrupt. IR Diode hängt an Pin3 und löst bei jedem Potentialwechsel einen Interrupt aus. Die IR Lib prüft dann auf Preambel und so weiter. Nachdem aber jede Menge IR Licht in der Luft ist, schaltet das Ding ziemlich häufig ein...
Deshalb würde ich dir zum Powermode 2 raten. Da hier nur der Atmel wach wird, bewegt sich das im kleinen ma Bereich.
Ich werde bei Gelegenheit noch einmal die Powermodes testen, aber bisher hatte ich keine Probleme mit dem Relay Sketch, also mode1 scheint zu funktionieren.
Viele Grüße
Horst
Hallo Horst,
zunächst einmal vielen Dank für die viele Arbeit mit der Bibliothek. Das ist die Wucht, und ich habe es auch geschafft, die NewAskSin Variante mit Panstamp in Betrieb zu nehmen. Das Dimmer Beispiel klappt wie eine eins.
Da ich versuchen möchte, empfangene IR Signale vom Panstamp zurück zum Fhem zu senden, wäre ich sehr für Tipps dankbar, wie man einen Wert an Fhem senden kann.
In den Beispielen der neuesten Version ist ja schon ein Sensor vorhanden. Ließe sich das damit schon machen?
Oder lässt sich vielleicht das Dimmermodul dazu verwenden?
Ich habe den kompletten Thread gelesen, leider ist es mir nicht gelungen, die für die alte Version diskutierten Ansätze auf die neue Bibliothek zu übertragen.
Wenn Du mich in die richtige Richtung stupsen könntest, würde mir das sehr helfen. Vielen Dank schon im Voraus.
Genau Horst, die Info brauche ich auch noch für mein nächstes Projekt, Stromverbrauch-Ermittlung per EmonLib. Aber ich glaube, die Klasse "THSensor" ist zur Zeit nur die Hülle, da arbeitet Horst noch dran.
@hsteinbo: Du könntest aber in die andern Devices (Relay, Dimmer) eine neue Funktion ergänzen mit einem Aufruf von hm->sendINFO_ACTUATOR_STATUS und damit vom Sketch aus einfache Integer Werte an FHEM übermitteln. Als Machbarkeitsstudie ausreichend, denke ich.
Es geht weiter mit der lib - habe mich am Wochenende um die Integration einer neuen Hardware gekümmert. Ist noch nicht komplett, aber Senden und Empfangen, sowie debuggen geht schon...
(http://busware.de/show_image.php?id=446&scalesize=0&nocount=y)
http://busware.de/tiki-browse_gallery.php?galleryId=49 (http://busware.de/tiki-browse_gallery.php?galleryId=49)
Das ganze basiert auf einem radino, ein AVR 32U4 mit eingebautem Funkmodul
http://shop.in-circuit.de/products/170/radino-CC1101-868-915MHz (http://shop.in-circuit.de/products/170/radino-CC1101-868-915MHz)
@setstate und hsteinbo
Das THSensor File ist noch ein Grundgerüst. Ich möchte hier eine Standard Sensor Class bauen, die von "außen" mit Meßwerten befüllt wird. Die Dimmer class und auch die Relay class sind Aktoren, die sollen nur ihren Status zurück liefern. Eignet sich also nicht für Meßwerte. Da ist die Sensor class schon besser.
Wie sehen denn die Werte aus, die ihr übertragen wollt?
Und ganz wichtig, was wollt ihr mit den übertragenen Meßwerten machen? Sollen die nur nach Fhem und angezeigt werden?
Oder wollt ihr mit den Meßwerten den Condition Table in Aktoren bedienen? Z.b. Lichtsensor schaltet Rolläden?
Bei dem IR Device bin ich mir nicht sicher, ob ich den Verwendungszweck schon begriffen habe. Soll das nur eine Bridge zwischen Wohnzimmer und FHEM sein, oder möchtest du per Fernbedienung z.b. einen Dimmer schalten? Sollen hier alle Fernbedienungsbefehle empfangen und gepostet werden, oder möchtest du filtern?
Viele Grüße
Horst
Ich würde die Messwerte nur im FHEM anzeigen / verarbeiten wollen. Ich nutze, außer Fensterkontakte zum Heizungsthermostat, keine Peers.
Hallo,
nach Evaluierung von verschiedenen Optionen (MySensors, Panstamp) plane ich jetzt auch einen Selbstbau Aktor mit der Asksin Library.
Auch bei mir geht es um Infrarot, aber erstmal ist nur ein Infrarot Sender geplant, also ein Funk-IR-Umsetzer mit Batteriebetrieb.
Vielleicht kann mir jemand noch diese Fragen beantworten:
- Unterstützt die Library die Wake-On-Radio Funktion des CC1101? Habe beim ersten Überfliegen des Codes nichts entsprechendes finden können.
Falls nein, wie wird ein möglichst geringer Energieverbrauch bei einem Aktor realisiert der eigentlich nicht zyklisch aufwachen muss?
- Empfiehlt sich für ein neues Projekt schon die Verwendung der NewAsksinLibrary oder ist die noch zu sehr im Fluss/instabil?
Danke,
Kai
Hi Kai,
Gute Entscheidung. Ich kann dir nur zur NewAskSin raten. An der Asksin werde ich nicht weiter arbeiten und bis auf Sensor und Schalter Class ist bereits der selbe Stand erreicht. Power management ist implementiert. Im Relaysketch ist ein Beispiel drin. Die verschiedenen Modi habe ich 4 oder 5 Löste weiter vorne aufgelistet.
Viele Größe
Horst
@setstate Danke für Deinen Vorschlag, aber die SensorClass klingt genau wie dass, was ich brauche
@trilu Danke für Dein schnelles Feedback! Meine Vorhaben ist, in Kombination mit der Arduino IR Remote Lib einen IR Empfänger zu bauen, der bei bestimmten IR Signalen (meiner Fernbedienung) in FHEM bestimmte Aktionen auslöst (z.B. Licht/Rolladen steuern)
Dabei brauche ich kein direktes Peering mit anderen Aktoren sondern lediglich die Möglichkeit, Zahlenwerte an FHEM zu schicken und dort darauf zu reagieren.
Mein erster Ansatz war die Stuerung via LIRC und das funktioniert auch im Prinzip, aber es ist (bei meinem Setup) eher unzuverlässig (schlechter WAF)
Bekommst du deine IR Befehle in ein Byte rein?
Irgendwie so
Bit 1 - 3 Kodierung, oder IR Typ
4 - 8 Befehl
Das wäre dann ziemlich einfach zu realisieren...
Ich hätte hier eine Experimentalversion für einen IR-Sender und IR-Empfänger.
Dazu gibt es auch ein experimentelles FHEM-Modul bzw. ein PM-File für HM.
Das Ganze ist aber nicht vollständig Arduino-Kompatibel weil ich als IR-Lib IRMP einsetze. Das ist auch noch mit der "alten" Asksin-Lib gebaut.
In IRMP sind jede Menge IR-Codes integriert und müssen ggf. nur einkommentiert werden.
Bei FHEM kommt bei einem Tastendruck dann der entsprechende IR-Code an. Zum Senden muss man "nur" den zu sendenden IR-Code in FHEM angeben.
Dafür gibt es auch schon ein Prototyp für ein Addon-Board für die Universalsensorplatine.
Aus Zeitgründen steht das Projekt aktuell. Aber vielleicht kann man da ja was gemeinsam entwickeln.
Bei Interesse lade ich das mal auf Github hoch.
Viele Grüße
Dirk
Zitat von: Dirk am 01 Dezember 2014, 21:12:02
Ich hätte hier eine Experimentalversion für einen IR-Sender und IR-Empfänger.
Dazu gibt es auch ein experimentelles FHEM-Modul bzw. ein PM-File für HM.
Das Ganze ist aber nicht vollständig Arduino-Kompatibel weil ich als IR-Lib IRMP einsetze. Das ist auch noch mit der "alten" Asksin-Lib gebaut.
In IRMP sind jede Menge IR-Codes integriert und müssen ggf. nur einkommentiert werden.
Bei FHEM kommt bei einem Tastendruck dann der entsprechende IR-Code an. Zum Senden muss man "nur" den zu sendenden IR-Code in FHEM angeben.
Sehr interessant! Ich wollte auch die IRMP verwenden, u.a. weil die auch in der culfw verwendet wird und so die IR-Codes 1:1 ausgetauscht werden könnten.
Zitat
Bei Interesse lade ich das mal auf Github hoch.
Ja, bitte. An dem Schaltplan bin auch auch interessiert, auch wenn IR-Sender kein Hexenwerk ist.
Gruß,
Kai
Zitat von: trilu am 01 Dezember 2014, 20:28:06
Hi Kai,
Gute Entscheidung. Ich kann dir nur zur NewAskSin raten. An der Asksin werde ich nicht weiter arbeiten und bis auf Sensor und Schalter Class ist bereits der selbe Stand erreicht. Power management ist implementiert. Im Relaysketch ist ein Beispiel drin. Die verschiedenen Modi habe ich 4 oder 5 Löste weiter vorne aufgelistet.
Viele Größe
Horst
Hallo Horst,
ich nehme an für einen Aktor empfiehlst du den Mode 1, oder?
Zitat
Mode 1 ist speziell für batteriebetriebene Schaltaktoren, hier wird auf ein Burstsignal gewartet. Dazu muss das Funkmodul alle 250ms eingeschaltet werden, was der eigentliche Batteriefresser ist.
Wenn ich das recht verstehe verwendet der dann aber nicht den Wake-On-Radio Modus des CC1101, oder? Oder ist mit "muss das Funkmodul alle 250ms eingeschaltet werden" nicht gemeint, dass der ATmega regelmäßig aufwacht, um das Funkmodul zu aktivieren?
Denn laut Datenblatt des CC1101 sollte es ja auch möglich sein, den Controller erst dann aufzuwecken, wenn tatsächlich etwas empfangen wurde:
Zitat
The optional Wake on Radio (WOR)
functionality enables CC1101 to periodically
wake up from SLEEP and listen for incoming
packets without MCU interaction.
@trilu:
Zitat von: trilu am 01 Dezember 2014, 20:44:34
Bekommst du deine IR Befehle in ein Byte rein?
Irgendwie so
Bit 1 - 3 Kodierung, oder IR Typ
4 - 8 Befehl
Das wäre dann ziemlich einfach zu realisieren...
Ein Byte reicht für meine Zwecke fett aus
Mein IR-Sender ist jetzt auch produktiv gegangen (NewAskSin). Ich habe Mode 1 genommen und messe 120µA, werde also ca. 400 Tage mit 2x AAA hinkommen. Ich steuere damit meinen Beamer, an und aus mit dem gleichen IR Signal. Mein addon für die NewAskSin, die IRrelay Klasse sendet dafür das Power Signal (maximal 10 Versuche) und testet aller 1 Sekunde, ob das Teil an ist (per Usb Kabel zum Pin5) und meldet den Zustand an FHEM. Das ist wichtig, wenn der Beamer nach 4 Stunden von selbst in den Stromsparmodus geht und ich von FHEM Off schalten würde, würde er mit dem Power-Signal wieder angehen. So kontrolliert aber die IRrelay Klasse vorher Ist und Soll Zustand und sendet nur, wenn nötig.
Den Code könnte ich auch allgemein zur Verfügung stellen, wenn Interesse besteht.
@ kaihs
Für einen Batterie betriebenen Aktor würde ich Powermode 1 nehmen. Wenn das Ding am Stromnetz hängt, dann würde ich Mode 0 nutzen.
Für mode 1 muss ein Burst von 300ms vor jeder Message gesendet werden, das belastet das Funknetz.
Wake on radio funktioniert für HM leider nicht. Wake up wird auch bei den original Geräten von HM wie folgt gelöst:
CPU wacht alle 250ms auf und schaltet das Funkmodul auf Empfang, dann wird kurz gelauscht ob ein Burst in der Luft ist, wenn nein wird das Funkmodul ausgeschaltet und die CPU geht schlafen. Falls ein Burst in der Luft ist, wird ein neuer watchdog von 50ms aktiviert, Funk aus, CPU schlafen gelegt.
Nach 50ms wacht die CPU auf, Funk an, prüft erneut und wenn immer noch das Burst Signal in der Luft ist, bleibt die CPU und Funk an, bis eine Message empfangen wurde oder erneut ein Timeout alles schlafen legt.
Viele Grüße
Horst
Zitat von: setstate am 02 Dezember 2014, 07:52:53
Mein IR-Sender ist jetzt auch produktiv gegangen (NewAskSin). Ich habe Mode 1 genommen und messe 120µA, werde also ca. 400 Tage mit 2x AAA hinkommen. Ich steuere damit meinen Beamer, an und aus mit dem gleichen IR Signal. Mein addon für die NewAskSin, die IRrelay Klasse sendet dafür das Power Signal (maximal 10 Versuche) und testet aller 1 Sekunde, ob das Teil an ist (per Usb Kabel zum Pin5) und meldet den Zustand an FHEM. Das ist wichtig, wenn der Beamer nach 4 Stunden von selbst in den Stromsparmodus geht und ich von FHEM Off schalten würde, würde er mit dem Power-Signal wieder angehen. So kontrolliert aber die IRrelay Klasse vorher Ist und Soll Zustand und sendet nur, wenn nötig.
Den Code könnte ich auch allgemein zur Verfügung stellen, wenn Interesse besteht.
@setstate
Hallo setstate, ich hätte Interesse an Deinem Code
kurzes update zur NewAskSin
Ich habe die gesamte Hardware Definition aus dem Library Ordner entfernt und in den Sketch Ordner verlagert. Relay, Dimmer und CUSTOM_LUX sind angepasst. Damit sollte die Library an sich jetzt Hardware unabhängig sein.
Die Funktionen zur externen Batteriemessung funktionieren noch nicht, muss ich noch anpassen.
Ansonsten geht es jetzt weiter mit der Arbeit an der Sensor Class.
Viele Grüße
Horst
Hallo Trilu,
die Lib geht wieder, auch in der Arduino IDE :D
Auch danke für die Datasheets. Die Radino's sind ziemlich interessant, nur aus Kostengründen werden wahrscheinlich kaum in Frage kommen.
Eine Bitte hätte ich noch, könntest du vielleicht später einen Normalen Taster (HM-PB-2-WM55-2) anlegen für die weniger erfahrenen Programmierer unter uns ;)
Da es noch keine ausführliche Dokumentation zur AskSin gibt, ist es nicht einfach die Zusammenhänge zu verstehen.
Ansonsten vielen Dank für die tolle Arbeit, verfolge mit großem Interesse deine Fortschritte.
Gruß
lech
Hallo,
ich bin seit ein paar Tagen stolzer Besitzer eines panstamps und auf die NewAskSin Bibliothek aufmerksam geworden. Ich arbeite mit der Arduino IDE 1.5.8 und den entsprechenden panstamp libs. Beim Übersetzen ist mir aufgefallen, dass ich in der hal.h noch die "HardwareSerial.h" einbinden muss. Die ist standrdmäßig bei der panstamp lib nicht mehr dabei. Aber so lies sich dann alles übersetzen und in die panstamp laden.
Allerdings hat sie dann erst mal jeden Dienst verweigert und ist in CC::init bei strobe(CC1101_SRES); ausgestiegen. Wenn ich die Zeile auskommentiere, scheint alles zu laufen, aber jeder Versuch eines pairen mit einen Funk LAN Adapter bleibt erfolglos.
Momentan bin ich ratlos. Welche Umgebung ist denn für die NewAskSin Lib und die Panstamp zu empfehlen?
Viele Grüße,
Karsten
Arduino IDE 1.5.8 passt schon ganz gut - die Panstamp libs sind nicht notwendig, sollten aber auch nicht stören.
Du musst die NewAskSin in den library Ordner packen und umbenennen von NewAskSin-master nach NewAskSin.
Dann sollte es eigentlich funktionieren. Fehler beim cc::init darf auch keiner kommen. Weil wenn das Kommunikationsmodul
nicht läuft, wird es auch nichts mit HM Kommunikation.
Viele Grüße
Horst
Hi,
ist es mit der library möglich, mit nur einem Arduino sowohl einen Dimmer als auch einen Sensor (zB Pir oder Taster) zu kombinieren?
Danke!
ja klar - dazu werden einfach mehrere channels definiert und die verbindung untereinander über peers hergestellt.
kommunikation läuft dann im device - ich werde bei gelegenheit ein schalter, relay device als beispiel bauen...
Super!
Du brauchst auch kein ganz neues Beispiel machen - eine Erweiterung des HM_LC_Dim1PWM_CV um einen Taster würde mir schon sehr weiterhelfen.
Ich habe mal den Dimmer nach gebaut, dabei ist mir aufgefallen, dass on for timer immer doppelt so lange dauert wie angegeben.
Außerdem geht wenn ich dimme die LED ein paar sekunden später immer wieder aus :(
Ist es normal, dass die Serielle Ausgabe nur noch HEX ausgibt ?
Ist aber ein Super Projekt, seine Eigenen Homematic Komponenten zu Entwickeln, daher ein großes dank an alle Mitwirkenden .
hmm, habe den dimmer schon einige tage nicht mehr am laufen gehabt und ein paar kleinigkeiten in der lib geändert, aber solche probleme sollte es eigentlich nicht geben.
was nutzt du für hardware?
wie hast du das peer eingetragen - mit der hm config soft?
die serielle schnittstelle musst du auf 57600 baud einstellen - per default zeige ich aber nur noch den traffic an, also keine modulausgaben, kannst du aber in jeder .cpp einschalten, ganz oben #define xx_DBG
Ich habe eine Panstamp (AVR) und habe es einfach über FHEM gepairt als Adapter nutze ich eine HM-LAN, kann aber auch mit einer CUNO testen.
Normales Ein/Aus geht auch wunder bar.
alles gut - hm-lan passt auch. ich vermute das problem der ausgehenden led an der fehlenden oder falschen config.
mach mal das peering mit der hm-config soft.
geht seriell jetzt?
Hallo Zusammen,
hat schon jemand Erfahrungen mit dem HM_LC_SW1_BA_PCB und der NewAskSim lib?
Danke
Marcus
So habe jetzt mal mit der HM Software gepairt, da konnte ich Einstellungen vornehmen, z.B. interne Taster usw...
Allerdings geht danach nichts mehr :(
Also falsche ports glaube ich kaum, da dimmen und sw. ja funktioniert hat (bis auf die Auschalterrei nach ein paar sekunden)
Habe danach mal das normale Batterie Aktor sketch geflasht und da geht auch nichts mehr, unter FHEM Pairing möglich unter der HM Software nicht, will immer einen Sicherheitsschlüssel.
Man, das ist echt zum verzweifeln, wollte danach mal das mit den Sensor testen, da ich hier einen CO2 sensor liegen habe.
Hallo trilu,
eine tolle Bibliothek!
Ich habe allerdings einige Probleme mit der Erzeugung der Register.h Datei. Die Verwendung von destillRegs scheint nur einen Teil der notwendigen Informationen zu generieren.
Kann das sein?
Vielen Dank
Marcus
Hallo Trilu,
mir ist aufgefallen, dass das manuele Einschalten durch den Taster (D8 gegen Masse) im Beispiel HM_LC_SW1_BA_PCB (NewAskSin), keine Rückmeldung an die Zentrale FHEM/CCU schickt.
Somit bleibt der Status in der Zentrale unverändert. Ist das beim Original auch so?
Kann man den Sketch so abändern, dass beim manuellen Einschalten zu FHEM/CCU kommuniziert wird?
Danke schon mal
habe heute noch mal den relay sketch überarbeitet - er müsste jetzt wie gewünscht funktionieren
@lech - stimmt, habe ich jetzt eingebaut, ist beim original auch so das ein status gesendet wird.
@MaSchu - mhh, bis auf die HMID, Seriennummer und device identification sollte sie eigentlich alles erzeugen
//- ----------------------------------------------------------------------------------------------------------------------
//- settings of HM device for AS class -----------------------------------------------------------------------------------
const uint8_t devIdnt[] PROGMEM = {
/* Firmware version 1 byte */ 0x15, // don't know for what it is good for
/* Model ID 2 byte */ 0x00, 0x6c, // model ID, describes HM hardware. Own devices should use high values due to HM starts from 0
/* Sub Type ID 1 byte */ 0x10, // not needed for FHEM, it's something like a group ID
/* Device Info 3 byte */ 0x41, 0x01, 0x00 // describes device, not completely clear yet. includes amount of channels
};
//- ----------------------------------------------------------------------------------------------------------------------
//- channel slice address definition -------------------------------------------------------------------------------------
const uint8_t cnlAddr[] PROGMEM = {
0x02,0x05,0x0a,0x0b,0x0c,0x12,
0x08,
0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte
//- channel device list table --------------------------------------------------------------------------------------------
EE::s_cnlTbl cnlTbl[] = {
// cnl, lst, sIdx, sLen, pAddr;
{0, 0, 0x00, 6, 0x000F},
{1, 1, 0x06, 1, 0x0015},
{1, 3, 0x07, 22, 0x0016},
}; // 18 byte
//- channel device list table --------------------------------------------------------------------------------------------
EE::s_peerTbl peerTbl[] = {
// cnl, pMax, pAddr;
{1, 6, 0x009A}
}; // 4 byte
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
EE::s_devDef devDef = {
1, 3, devIdnt, cnlAddr,
}; // 10 byte
//- module registrar -----------------------------------------------------------------------------------------------------
RG::s_modTable modTbl[1];
so müsste das ergebnis aussehen...
Hi Trilu,
super, funktioniert wie das Original ;D
Damit wird die Zirkulationspumpe zur bestimmten Zeiten angesteuert. Und wenn der Tempsensor plötzlichen Verbrauch erkennt, so springt die Pumpe wieder an und meldet über den Rückkanal an die Zentrale. Falls es jemanden interessiert, hier ein interessanter Beitrag:
http://www.stall.biz/?project=warmwasser-zirkulationspumpe-intelligent-geschaltet-mit-oder-ohne-homematic-anbindung
Wenn du mir noch einen Hinweis geben könntest wie ich aus diesem Sketch einen einfachen Taster machen könnte (HM-PB-2-WM55-2).
Ich wollte schon lange meine Türklingel an das System anbinden ::)
Die alte Lib lässt sich leider nicht mehr kompilieren, sonst würde ich den HM6TastenSwitch Sketsch missbrauchen. Ich habe jetzt versucht die alten Libs von Dirk und Unimatrix, die gehen aber auch nicht mehr.
Mein Problem ist, dass ich als Anfänger deinen Sketch nicht ganz verstehe. Manchmal verwendest du Komanden wie beispielsweise "PORTB = PORTC = PORTD = 0x00", das ist bestimmt nicht "arduinisch", damit meinst wahrscheinlich sowas wie "pinMode(ledPin, OUTPUT/INPUT)" aus Processing oder C Sprache.
In den ganzen Arduino Büchern ist es viel einfacher beschrieben. So bin ich dann auf deine Beispiele angewiesen.
Trotzdem vielen Dank für deine tolle Arbeit und wünsche noch frohe Weihnachten und einen guten Rutsch!
P.S. zu Weihnachten habe ich mir das dickste Arduino Kochbuch gewünscht ;)
@lech - Danke fürs Testen und die Rückmeldung!
Am Anfang habe ich mich auch strikt an Arduino gehalten, habe aber im Laufe der Zeit gemerkt, das Arduino manchmal doch recht einschränkt.
Um alle Pins sicher in den Zustand low zu versetzen müsste man in Arduino für jeden Pin einzeln den Befehl pinMode(pin,direction) und digitalWrite(pin, state) verwenden. In c++ geht das viel einfacher. Man setzt Input/Output über das Data Direction Register DDR für einen oder alle Pins auf einmal, danach setzt man die entsprechenden PIN Zustände über das PORT Register.
"PORTB = PORTC = PORTD = 0x00" setzt alle Pins an allen Ports auf LOW.
Den Tasten Switch werde ich bei Gelegenheit bauen. Bin mit der Sensor Class noch nicht ganz durch, aber danach kommt der Switch dran, versprochen.
Ich will einen Touch Sensor Switch bauen. Soll sich verhalten wie ein HM Switch, aber eben nicht per Taster sondern Touch. Gibt einen recht interessanten Chip dazu, den MPR121. Braucht 29ua im Bereitschaftsmodus, somit batterieschonend genug.
http://cache.freescale.com/files/sensors/doc/data_sheet/MPR121.pdf?fasp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf (http://cache.freescale.com/files/sensors/doc/data_sheet/MPR121.pdf?fasp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf)
Frohe Weihnachten!
Nach etlichen Versuchen tut der dimmer jetzt wieder :D
Allerdings immer noch mit dem Problem, das sobald man up oder down drückt bzw. pct auf einen Wert einstellt nach ca. 8 sekunden die LED wieder ausgeht.
wenn man pct auf 100 Stellt funktioniert es gar nicht (geht nicht ein).
Der Config taster hat leider auch keine Funktion außer Anlernen.
Hatte mir den Source code mal aqngeschaut aber nirgendwo gefunden, woran das liegen kann.
P.S. on for time ist ja auch doppelt so lange wie angegeben, könnte das ewtl. zusammenhängen.
Wäre für tips, wo ich schauen muss dankbar, da ich auch erst mit arduino angefangen habe und versuche, das ganze zu verstehen..
Schönes Fest an alle :D :D :D
Gerade von der Kirche zurück und Kinder sind mit Geschenken beschäftigt :)
Ich schaue mir den Dimmer nach den Tagen mal an. Das der Taster nur zum leeren geht ist klar, die Original Funktionalität basiert auf einem weiteren Kanal bei dem der Taster als Switch funktioniert. Die Switch Claes habe ich aber noch nicht fertig. Kommt aber noch...
Hast du mal mit der HM Config Soft das peer konfiguriert? Ich bin mir nicht sicher ob die Default Werte in der Dimmer Claes passen. Ich habe den Sketch mit der HM Soft getestet, da lief das peer mit einem 6 Tasten Switch gut.
Das mit der doppelten Zeit wundert mich etwas, aber kann gut sein, das ich was über sehen habe. Im Vergleich zur Relay Claes ist der Dimmer ziemlich aufwendig.
So, zurück unter den Christbaum.
Liebe Grüsse und viele Geschenke ;D
PS: Habe eine CNC 3040 vom Christkind bekommen!
Auch wenn die Lib keine CUL werden soll, ist es einfach (und möglichst ohne das Klassenkonzept zuzerstören, darin bin ich Experte) die empfangenden Daten der Stellmotoren/Thermostate auszuwerten und dabei noch ein Taster zu sein um die Scahltaktoren zu steuern?
Lösungsansatz: Mit Stellmotor als Stellmotor peeren, doch frisst der Schaltaktor das Peering dann noch?
Beim Dimmer (HM_LC_Dim1PWM_CV) habe ich nur das Problem, wenn ich ihn über CCU einschalte, dann geht er nach einer knappen Sekunde wieder aus.
Steuerung über den Schieberegler bis zu 100% funktioniert dagegen einwandfrei.
@wirfman - ich verstehe noch nicht ganz was du willst? soll die lib einen stellmotor emulieren und einen taster kanal zur verfügung stellen?
was wäre der verwendungszweck des stellmotors?
@lech - hast du das als virtuellen kanal gepeert mit der ccu? hast du nur gepeert, oder auch das peer konfiguriert?
habe festgestellt, das ich noch probleme mit den default werten habe...
viele grüße
trilu
Zitat von: trilu am 29 Dezember 2014, 14:00:06
@wirfman - ich verstehe noch nicht ganz was du willst? soll die lib einen stellmotor emulieren und einen taster kanal zur verfügung stellen?
was wäre der verwendungszweck des stellmotors?
Eigentlich will ich nur die Temperaturen des Stellmotors abhören (Geht das auch zuverlässing ohne Peering?) und manchmal einen Aktor steuern.
Hallo Trilu,
den Dimmer habe gar nicht gepeert, sondern nur gepairt - an der CCU2 angelernt.
Der funktioniert soweit ganz gut, nur wenn man auf den Button "Ein" klickt, dann geht er zunächst kontinuierlich an und gleich wieder aus.
Wie kann man hier im Forum Screenshots einfügen? Wenn ich aufs Symbol "Bild einfügen" drücke, dann macht er mir nur paar eckigen Klammern.... (//)
PS: schönes Geschenk. Jetzt kann man die Platinen selber machen ;)
kopier doch mal bitte das serielle log file hier mit rein.
bilder kannst du nur hochladen, also als anhang zum text...
Ok, hier:
m> 0E 09 A0 11 2D 7D 34 01 02 04 02 01 C9 00 A0 (54459)
<- 0E 09 80 02 01 02 04 2D 7D 34 01 01 C9 60 51 (54562)
b> 0F 5D 86 10 22 10 B0 00 00 00 0A 88 B8 0D 00 00 (54904)
<- 0E 01 A0 10 01 02 04 2D 7D 34 06 01 C9 00 5F (56562)
m> 0A 01 80 02 2D 7D 34 01 02 04 00 (56707)
m> 0E 0A A0 11 2D 7D 34 01 02 04 02 01 00 00 A0 (56976)
<- 0E 0A 80 02 01 02 04 2D 7D 34 01 01 00 50 51 (57079)
<- 0E 02 A0 10 01 02 04 2D 7D 34 06 01 00 00 51 (59079)
b> 0F 7A 86 10 22 10 A2 00 00 00 0A 88 BB 0C 00 00 (59146)
m> 0A 02 80 02 2D 7D 34 01 02 04 00 (59223)
b> 0C A9 86 70 1F 4A D3 00 00 00 00 DD 2D (61812)
b> 0F 78 86 10 22 11 3D 00 00 00 0A 90 CD 0D 00 00 (65153)
b> 0F 59 86 10 22 2B 38 00 00 00 0A 90 C4 0C 00 00 (70938)
ich schalte den Dimmer in der CCU2 ein und aus....
hier nochmal:
b> 0F 0B 86 10 22 10 D7 00 00 00 0A 90 BC 0E 00 00 (509445)
b> 0C AC 86 70 1F 4A D3 00 00 00 00 DD 2D (513070)
b> 0F 60 86 10 22 10 B0 00 00 00 0A 88 B8 0D 00 00 (514317)
b> 0F 5C 86 10 22 2B 38 00 00 00 0A 90 C5 0C 00 00 (524414)
m> 0E 0D A0 11 2D 7D 34 01 02 04 02 01 C9 00 A0 (543483)
<- 0E 0D 80 02 01 02 04 2D 7D 34 01 01 C9 60 50 (543586)
b> 0F 7B 86 10 22 11 3D 00 00 00 0A 90 CD 0D 00 00 (545582)
<- 0E 05 A0 10 01 02 04 2D 7D 34 06 01 C9 00 4F (545588)
m> 0A 05 80 02 2D 7D 34 01 02 04 00 (545731)
b> 0F 7D 86 10 22 10 A2 00 00 00 0A 88 BA 0C 00 00 (551943)
m> 0E 0E A0 11 2D 7D 34 01 02 04 02 01 00 00 A0 (556186)
<- 0E 0E 80 02 01 02 04 2D 7D 34 01 01 00 50 4B (556289)
<- 0E 06 A0 10 01 02 04 2D 7D 34 06 01 00 00 4B (558289)
m> 0A 06 80 02 2D 7D 34 01 02 04 00 (558434)
b> 0F 68 86 10 22 10 AF 00 00 00 0A 88 B4 0C 00 00 (564663)
b> 0F 6C 86 10 22 10 A9 00 00 00 0A 90 C8 0C 00 00 (565955)
b> 0C 24 86 70 20 6B 37 00 00 00 7F D4 58 (577500)
Die CCU2 zeigt den eingeschalteten Zustand obwohl der Dimmer von alleine ausging...
0E 0D A0 11 2D 7D 34 01 02 04 02 01 C9 00 A0 (543483)
sehr seltsam, die CCU schickt dem dimmer ein C9 - das wäre 201, der dimmer kann aber nur status 200.
ich schaue mir das später mal an....
@trilu Danke für Deine rege Unterstützung, trotz attraktivem Weihnachtsgeschenk:-)
Lässt sich das CUSTOM_LUX Beispiel eigentlich schon nutzen, um ein Byte an FHEM zu schicken (von panstamp an FHEM via gepairten HMLAN), oder gibt es da einen anderen Trick?
Meine eigenen Versuche verlaufen gerade etwas im Sande, deshalb wäre ich für Tipps sehr dankbar.
Ich versuche mich gerade daran, einen Speziellen Garagen Schalter für die Toransteuerung zu Bauen :D
Ausgangstellung:
von 220V auf 12V umgebauter Gargentorantrieb (Betrieben über Solarzelle und AKKU).
Problem: Garagentorantriebssteuerung braucht ca. 500 bis 700ma im Standby, was die Anlage schnell leer saugt.
Lösung Aktuell: 4fach Batterie Homematic schalter mit KEYmatic Fernbedienung.
Taste Licht -> Ausgang 1 für 10min Ein ( Schaltet Strom ein)
Taste Tür auf -> =0,2 sec Ausgang 2 ein (schaltet den Antrieb)
So jetzt habe ich mir gedacht, warum nicht den Relais sketch zu nehmen und diesen so zu modifizieren, dass er diese Funktion automatisch macht. :D
Taste bzw Fernbedienung Ein -> Ralais 1 für 10min Ein (sollte schon über register gehen), mit 5secunden Verzögerung Relais 2 für 0,2 sec. Einschalten. bei jedem weiteren Ein Befehl sollte nur das Relais 2 für 0,2 sec Einschalten.
Habe zum Testen mal den Sketch angepasst.
if (status) {
setPinHigh(PORTD,3);
Garage(); //rufe Garagen Funktion auf
} // check status and set relay pin accordingly
else {
setPinLow(PORTD,3);
void Garage() {
//delay (50000);
pinMode(9,OUTPUT); //hier pinmode setzen, da ansonsten irgendwo wieder überschrieben wird.
digitalWrite(9, HIGH); //LED ein
delay (50000);
digitalWrite(9, LOW); //LED aus
}
Das funktioniert zumindest, dass er den 2 Ausgang bei Ein, kurz Schaltet :D, allerdings bei weiteren ein wird das ja nicht mehr ausgeführt :(
Ich habe leider auch noch nicht verstanden, wo ich die Funktionen abgreifen kann, wenn man einen Befehl an den Aktor sendet, hatte mir die Relais klasse mal angeschaut aber nicht gefunden, wo eine Funktion set on aufgerufen wird :(
P.S. Set on time läuft übrigens ca. 25% zu lange ansonsten funktioniert die Aktuelle Version als einfacher Schalter schon echt super :D
hallo maiks,
warum peerst du deinen aktor nicht einfach, dann hast du doch diverse register zum konfigurieren. wenn du keinen realen schalter hast, nimmst du einen virtuellen.
Hallo Frank,
der 4 fach Schalter ist ja gepeert und es funktioniert mit 2 tasten, allerdings will ich auf 1 Taste runter wie ein Normaler Garagentorantrieb) und der Batterie Schalter hat keine Verbindung zur Zentrale.
Mit der Askinlib könnte man so etwas ja schön selber machen, ich verstehe halt nur die Libary überhaupt noch nicht (Anfänger mit Arduino).
@hsteinbo
Zitat@trilu Danke für Deine rege Unterstützung, trotz attraktivem Weihnachtsgeschenk:-)
Lässt sich das CUSTOM_LUX Beispiel eigentlich schon nutzen, um ein Byte an FHEM zu schicken (von panstamp an FHEM via gepairten HMLAN), oder gibt es da einen anderen Trick?
Meine eigenen Versuche verlaufen gerade etwas im Sande, deshalb wäre ich für Tipps sehr dankbar.
Sehr gerne! Ja, der Custom Lux sollte schon senden, im Moment ist er eingestellt, dass er alle 2 bis 3 Minuten sendet.
Die Frage ist aber, ob FHEM damit schon was anfangen kann :-)
Gedulde dich noch ein paar Tage, muss gerade an der destillRegs basteln, da mir der Dimmer Schwierigkeiten macht. Danach geht es am Sensor weiter.
@Maiks - verstehe ich dich richtig, du möchtest mit einem Schaltbefehl ein Relais einschalten, etwas warten und dann einen Pin setzen um das Garagentor zu öffnen?
relay.config(&initRly, &switchRly); // hand over the relay functions of main sketch
Hier übergebe ich der Relay Class zwei Sprungadressen. initRly, wie der Name sagt ist die Funktion um die Pins für Das Relais zu initialisieren.
Das sieht so aus:
void initRly() {
// setting the relay pin as output, could be done also by pinMode(3, OUTPUT)
pinOutput(DDRD,3); // init the relay pins
setPinLow(PORTD,3); // set relay pin to ground
}
switchRly ist das was du suchst, hier wird bei einem Schaltbefehl hin gesprungen.
Derzeit schalte ich nur einen Pin, hier kannst du aber rein schreiben was du willst.
void switchRly(uint8_t status) {
// switching the relay, could be done also by digitalWrite(3,HIGH or LOW)
if (status) setPinHigh(PORTD,3); // check status and set relay pin accordingly
else setPinLow(PORTD,3);
}
Ein delay solltest du aber nicht verwenden. Die ganze Library basiert zum größten Teil auf polling. Ein delay unterbricht das, es kann also nichts mehr empfangen werden.
Danke für die Antwort, hatte es genau in dieser Stelle rein gebaut, allerdings wird das nur aufgerufen, wenn das Relay aus ist, ein wiederholtes drücken der Ein Taste funktioniert dort halt leider nicht mehr.
Werde mal schauen wie das mit timern funktioniert um ohne delay auszukommen..
Mir ist beim Ausprobieren übrigens augefallen, dass ich keinen Taster manuell an den Aktor Anlernen konnte, über die Zentrale ging es schon.
Kann man den Aktor irgendwie auf Werkseinstellungen zurücksetzen, denn 2 mal lange drücken hat bei mir nichts gemacht.
Das delay verhindert ein Empfangen von weiteren Befehlen, das ist das Problem.
Reset geht über die Zentrale, sobald das Device angelernt wird, löscht es selbst den Eeprom. Aber hast recht, muss ich noch einbauen. Ich leere immer über die HM config soft, das funktioniert prima bei mir. Auch der Relay sketch kann das.
Wenn ich die Tage dazu komme, Bau ich dir was entsprechendes in den Sketch :)
Was meinst du mit manuell an lernen?
Manuell Anlernen, den Batterie Aktor direkt an einen Taster Anlernen ohne Zentrale.
Auch ohne Delay wird die Funktion nur aufgerufen, wenn eine Statusänderung stattfindet.
das 13-->xxxxx habe ich gar nicht verstanden, habe nämlich versucht dort bei den Statusänderungen den Aufruf rein zu machen, allerdings nicht mit den gewünschten erfolg.
Hallo zusammen,
ich versuche grade meinen Arduino UNO zu Flashen.
Leider bekomme ich beim kompilieren Fehler ohne ende.
Ich habe es mit AskSin und mit NewAskSin versucht.
Mit Arduino IDE 1.06 und mit 1.5.8 das selbe.
Ich habe beide Ordner in den entsprechenden Library Ordner Entpackt.
Werden noch weitere Librarys gebraucht?
In file included from hardware.cpp:1:
/hardware.h:40:3: error: #error "Error: LEDS not defined for your hardware in hardware.h!"
/hardware.h:66:3: error: #error "Error: Configuration key not defined for your hardware in hardware.h!"
/hardware.h:114:3: error: #error "Error: CC1101 interface not defined for your hardware in hardware.h!"
/hardware.h:172:3: error: #error "Error: External battery measurement not defined for your hardware in hardware.h!"
hardware.cpp: In function 'void initLeds()':
hardware.cpp:26: error: 'ledRedDDR' was not declared in this scope
hardware.cpp:26: error: 'ledRedPin' was not declared in this scope
hardware.cpp:27: error: 'ledGrnDDR' was not declared in this scope
hardware.cpp:27: error: 'ledGrnPin' was not declared in this scope
hardware.cpp:28: error: 'ledActiveLow' was not declared in this scope
hardware.cpp:29: error: 'ledRedPort' was not declared in this scope
hardware.cpp:30: error: 'ledGrnPort' was not declared in this scope
hardware.cpp: In function 'void ledRed(uint8_t)':
hardware.cpp:34: error: 'ledActiveLow' was not declared in this scope
hardware.cpp:35: error: 'ledRedPort' was not declared in this scope
hardware.cpp:35: error: 'ledRedPin' was not declared in this scope
hardware.cpp:36: error: 'ledRedPort' was not declared in this scope
hardware.cpp:36: error: 'ledRedPin' was not declared in this scope
hardware.cpp:37: error: 'ledRedPort' was not declared in this scope
hardware.cpp:37: error: 'ledRedPin' was not declared in this scope
hardware.cpp: In function 'void ledGrn(uint8_t)':
hardware.cpp:40: error: 'ledActiveLow' was not declared in this scope
hardware.cpp:41: error: 'ledGrnPort' was not declared in this scope
hardware.cpp:41: error: 'ledGrnPin' was not declared in this scope
hardware.cpp:42: error: 'ledGrnPort' was not declared in this scope
hardware.cpp:42: error: 'ledGrnPin' was not declared in this scope
hardware.cpp:43: error: 'ledGrnPort' was not declared in this scope
hardware.cpp:43: error: 'ledGrnPin' was not declared in this scope
hardware.cpp: In function 'void initConfKey()':
hardware.cpp:48: error: 'confKeyDDR' was not declared in this scope
hardware.cpp:48: error: 'confKeyPin' was not declared in this scope
hardware.cpp:49: error: 'confKeyPort' was not declared in this scope
hardware.cpp:52: error: 'confKeyPCIE' was not declared in this scope
hardware.cpp:53: error: 'confKeyPCMSK' was not declared in this scope
hardware.cpp:53: error: 'confKeyINT' was not declared in this scope
hardware.cpp: In function 'void ccInitHw()':
hardware.cpp:105: error: 'CC_GDO0_DDR' was not declared in this scope
hardware.cpp:105: error: 'CC_GDO0_PIN' was not declared in this scope
hardware.cpp:106: error: 'CC_CS_DDR' was not declared in this scope
hardware.cpp:106: error: 'CC_CS_PIN' was not declared in this scope
hardware.cpp:108: error: 'SPI_DDR' was not declared in this scope
hardware.cpp:108: error: 'SPI_MOSI' was not declared in this scope
hardware.cpp:109: error: 'SPI_SCLK' was not declared in this scope
hardware.cpp:110: error: 'SPI_MISO' was not declared in this scope
hardware.cpp:115: error: 'CC_GDO0_PCICR' was not declared in this scope
hardware.cpp:115: error: 'CC_GDO0_PCIE' was not declared in this scope
hardware.cpp: In function 'uint8_t ccGetGDO0()':
hardware.cpp:123: error: 'CC_GDO0_PCIE' was not declared in this scope
hardware.cpp:123: error: 'CC_GDO0_INT' was not declared in this scope
hardware.cpp: In function 'void enableGDO0Int()':
hardware.cpp:128: error: 'CC_GDO0_PCMSK' was not declared in this scope
hardware.cpp:128: error: 'CC_GDO0_INT' was not declared in this scope
hardware.cpp: In function 'void disableGDO0Int()':
hardware.cpp:131: error: 'CC_GDO0_PCMSK' was not declared in this scope
hardware.cpp:131: error: 'CC_GDO0_INT' was not declared in this scope
hardware.cpp: In function 'void waitMiso()':
hardware.cpp:135: error: 'SPI_PORT' was not declared in this scope
hardware.cpp:135: error: 'SPI_MISO' was not declared in this scope
hardware.cpp: In function 'void ccSelect()':
hardware.cpp:138: error: 'CC_CS_PORT' was not declared in this scope
hardware.cpp:138: error: 'CC_CS_PIN' was not declared in this scope
hardware.cpp: In function 'void ccDeselect()':
hardware.cpp:141: error: 'CC_CS_PORT' was not declared in this scope
hardware.cpp:141: error: 'CC_CS_PIN' was not declared in this scope
hardware.cpp: In function 'void setSleep()':
hardware.cpp:224: error: 'PRR' was not declared in this scope
hardware.cpp:231: error: 'BODS' was not declared in this scope
hardware.cpp:231: error: 'BODSE' was not declared in this scope
hardware.cpp: In function 'uint16_t getAdcValue(uint8_t)':
hardware.cpp:275: error: 'PRR' was not declared in this scope
hardware.cpp: In function 'void initExtBattMeasurement()':
hardware.cpp:333: error: 'battMeasDDR' was not declared in this scope
hardware.cpp:333: error: 'battMeasPin' was not declared in this scope
hardware.cpp:334: error: 'battMeasPort' was not declared in this scope
hardware.cpp:335: error: 'battEnblDDR' was not declared in this scope
hardware.cpp:335: error: 'battEnblPin' was not declared in this scope
hardware.cpp: In function 'void switchExtBattMeasurement(uint8_t)':
hardware.cpp:339: error: 'battEnblDDR' was not declared in this scope
hardware.cpp:339: error: 'battEnblPin' was not declared in this scope
hardware.cpp:340: error: 'battEnblPort' was not declared in this scope
hardware.cpp:341: error: 'battEnblDDR' was not declared in this scope
hardware.cpp:341: error: 'battEnblPin' was not declared in this scope
melde mich zurück 8)
Habe den Dimmer Sketch überarbeitet, hatte einen blöden Fehler in der Registerdefinition, dadurch hat sich alles was Long ist um ein Byte verschoben.
Sollte jetzt gehen.
@Maiks - Du meinst das Anlernen ohne Zentrale, oder? Das muss ich mir mal anschauen wie das geht, wäre auch Zufall wenn es gehen würde ...
@Henno - AskSin und NewAskSin im Library Ordner funktioniert nicht. Lösch beide mal raus. Dann lädst du die NewAskSin neu vom Git, entpackst sie in den Library Ordner und benennst sie um - das -master muss weg, der Ordner muss dann NewAskSin heissen. Damit sollte es dann gehen....
@ trilu
Danke für deine Antwort.
Natürlich hatte ich das "-master" aus dem Ordnernamen gelöscht.
Jetzt habe ich nurnoch einen AskSin Ordner
C:\Users\xxxxx\Documents\Arduino\libraries\NewAskSin
Wenn ich aus dem Unternordner /examples/HM_LC_Dim1PWM_CV die Datei HM_LC_Dim1PWM_CV.ino in Arduino öffne bekomme ich den selben Fehlercode wie vorher.
Dazu muss ich sagen das ich unter Windows 8.1 x64 kompiliere.
Ich werde es aber nachher auch mal auf meinen Linux Server versuchen.
@henno
liegt denn in dem Unterordner die Datei hardware.h und hardware.cpp?
Deine Fehlermeldung sagt aus, dass die nicht da sind?
@ trilu
Ja sind sie
hardware.cpp
hardware.h
register.h
und der jeweilige Sketch
Arduino IDE öffnet auch alle drei Dateien mit.
wer lesen kann ist klar im vorteil ;D
LEDS not defined for your hardware in hardware.h!
welche hardware nutzt du denn?
Ich wollte einen Arduino Uno nutzen.
Habs aber auch mit einem Mega und mit einem Pro Mini versucht.
Als Sendemodul ein original Homematic Modul
ich habe in der hardware.h verschiedene sektionen für die hardware eingebaut - derzeit gibt es den avr 328 und den 32u4
mit dem mini pro müsste es eigentlich funktionieren, ist halt wichtig das ein avr328 drauf ist...
zumindest weiss ich jetzt woher dein problem kommt. teste mal mit dem 328 und poste die fehlermeldung
Die fehlermeldung bleibt bei allen boards gleich.
Unter Linux klappt es ohne Probleme.
Ich habe grade mal unter Windows Arduino IDE deinstalliert und neu installiert und siehe da es klappt mit dem Uno und auch mit dem Mini Pro.
Was auch immer das Problem war, es ist gelöst.
Danke für deine Hilfe
Zitat von: trilu am 04 Januar 2015, 11:51:33
melde mich zurück 8)
Habe den Dimmer Sketch überarbeitet, hatte einen blöden Fehler in der Registerdefinition, dadurch hat sich alles was Long ist um ein Byte verschoben.
Sollte jetzt gehen.
@Maiks - Du meinst das Anlernen ohne Zentrale, oder? Das muss ich mir mal anschauen wie das geht, wäre auch Zufall wenn es gehen würde ...
Ja genau, wie bei den richtigen Aktoren. Mit den Dimmer probiere ich gerne mal aus :D
Mit deiner Lib könnte man doch auch den Bewegungsmelder nachbilden oder ?
Mfg
Maik
@all
Ich habe ein wenig an der Config Button Class gearbeitet.
Um einen Device Reset zu machen, muss der Config Taster für 3 Sekunden gedrückt werden, daraufhin beginnt die rote Led zu blinken.
Taster loslassen und Taster innerhalb von 2 Sekunden erneut lange (3 Sekunden) drücken. Geräte Eeprom wird geleert...
Ich frage auch das Register 0x18 (local Reset disable) im Channel 0, List 0 ab. Falls 0x18 vorhanden ist und auf 1 gesetzt ist,
wird das Gerät nicht gelöscht :-)
Hallo Trilu,
Zitatmelde mich zurück 8)
Habe den Dimmer Sketch überarbeitet, hatte einen blöden Fehler in der Registerdefinition, dadurch hat sich alles was Long ist um ein Byte verschoben.
Sollte jetzt gehen.
Falls es dich interessiert, habe gerade den neuseten Sketch auf pro Mini geladen. Der Dimmer geht beim Einschalten nach Erreichen von 100% wieder aus, also keine Änderung.
Hier sind nochmal die Strings von der CCU2:
EIN:
m> 0E 1B A0 11 2D 7D 34 01 02 04 02 01 C9 00 A0 (237968)
<- 0E 1B 80 02 01 02 04 2D 7D 34 01 01 C9 60 4E (238071)
<- 0E 13 A0 10 01 02 04 2D 7D 34 06 01 C9 00 4E (238476)
m> 0A 13 80 02 2D 7D 34 01 02 04 00 (238621)
AUS:m> 0E 1D A0 11 2D 7D 34 01 02 04 02 01 00 00 A0 (353960)
<- 0E 1D 80 02 01 02 04 2D 7D 34 01 01 00 40 4E (354063)
<- 0E 15 A0 10 01 02 04 2D 7D 34 06 01 00 00 4E (354468)
m> 0A 15 80 02 2D 7D 34 01 02 04 00 (354613)
Gruß
@lech - hab mal einen fix für die c9 eingebaut - teste mit dem aktuellen git bitte noch mal...
Perfekt! ;)
Jetzt ist der Dimmer wie das Original, versteht auch die CCU.
Danke Trilu!
Hallo trillu,
erstmal recht herzlichen Dank für deine Arbeit.
Ich habe folgendes Problem:
Wenn ich in Fhem den HM_LC_SW1_BA_PCB ein "on-for-timer" oder "on-till" sende dann bekomme ich in Fhem ein "MISSING ACK" angezeigt.
Hast Du eine Idee?
Hier mal die serielle Ausgabe:
HM_LC_SW1_BA_PCB
SN.
RV.
HMID: 01 02 05, MAID: 00 00 00
<- 0E 00 80 10 01 02 05 0���������������B��ʺJRx> 10 1E B0 11 F1 22 22 01 02 05 02 01 C8 00 00 06 40 (56767)
<- 0E 1E 80 02 01 02 05 F1 22 22 01 01 C8 00 4A (56774)
x> 10 1F B0 11 F1 22 22 01 02 05 02 01 C8 00 00 06 40 (60459)
<- 0E 1F 80 02 01 02 05 F1 22 22 01 01 C8 40 49 (60472)
x> 10 1F B0 11 F1 22 22 01 02 05 02 01 C8 00 00 06 40 (64615)
<- 0E 1F 80 02 01 02 05 F1 22 22 01 01 C8 40 49 (64628)
<- 0E 01 80 10 01 02 05 00
so wie es aussieht ist dein device nicht gepaired - zumindest fehlt ihm die master id :-)
device sendet nach langem tastendruck den pairing string, also 3-4 sekunden auf die taste drücken...
natürlich muss der master, fhem im pairing modus sein...
viele grüße
trilu
Hallo trillu,
so, gebunden ist er sauber, er lässt sich schalten, aber es stimmt immer noch nicht ;-)
Beim einschalten kommt ein NACK und dann ein MISSING ACK
Beim abschalten wird der falsche Status geliefert ("on")
Hier die Ausgabe von Fhem:
2015-01-11 20:39:41 CUL_HM HM_Switch set_on-till 20:40:00
2015-01-11 20:39:41 CUL_HM HM_Switch NACK
2015-01-11 20:39:44 CUL_HM HM_Switch level: 100
2015-01-11 20:39:44 CUL_HM HM_Switch pct: 100
2015-01-11 20:39:44 CUL_HM HM_Switch deviceMsg: on (to CUL_868_HM)
2015-01-11 20:39:44 CUL_HM HM_Switch on
2015-01-11 20:39:44 CUL_HM HM_Switch timedOn: running
2015-01-11 20:39:44 CUL_HM HM_Switch battery: ok
2015-01-11 20:39:48 CUL_HM HM_Switch ResndFail
2015-01-11 20:39:49 CUL_HM HM_Switch MISSING ACK
Und die dazu gehörige serielle Ausgabe:
m> 10 1E B0 11 BA F0 75 07 05 00 02 01 C8 00 00 17 C0 (635314)
<- 0E 1E 84 02 07 05 00 BA F0 75 01 01 C8 00 54 (635321)
m> 10 1F B0 11 BA F0 75 07 05 00 02 01 C8 00 00 17 C0 (638192)
<- 0E 1F 84 02 07 05 00 BA F0 75 01 01 C8 40 56 (638205)
Beim Abschalten:
2015-01-11 20:40:06 CUL_HM HM_Switch level: 100
2015-01-11 20:40:06 CUL_HM HM_Switch pct: 100
2015-01-11 20:40:06 CUL_HM HM_Switch deviceMsg: on (to CUL_868_HM)
2015-01-11 20:40:06 CUL_HM HM_Switch on
2015-01-11 20:40:06 CUL_HM HM_Switch timedOn: off
2015-01-11 20:40:06 CUL_HM HM_Switch battery: ok
<- 0E 08 A4 10 07 05 00 BA F0 75 06 01 C8 00 56 (657345)
m> 0A 08 80 02 BA F0 75 07 05 00 00 (657500)
Bei set on-for-timer zeigt sich das gleiche Verhalten.
Gruß
Björn
ich muss mir das noch mal anschauen -
m> 10 1E B0 11 BA F0 75 07 05 00 02 01 C8 00 00 17 C0 (635314)
<- 0E 1E 84 02 07 05 00 BA F0 75 01 01 C8 00 54 (635321)
m> heißt, die message kommt vom master und die adresse ist auch bekannt
bei der antwort, deutet die 84 darauf hin, dass der master nicht bekannt ist, deshalb wurde das bidi flag nicht beachtet.
FHEM interpretiert anscheinend die 84 als NACK
sehr seltsam...
Hallo trilu,
so wie lech berichtet funktioniert der Dimmer an der CCU. Mit FHEM ist es aber immer noch so daß versucht wird einen Wert zu setzen, nach kurzer Zeit geht der Wert wieder auf Null und der Slider springt zurück.
x> 10 0A A0 11 32 1C BA 01 02 04 02 01 58 03 20 FF FF (1609490)
RL:trigger11, val:88, rampT:2500, duraT:0
<- 0E 0A 80 02 01 02 04 32 1C BA 01 01 58 60 57 (1609598)
<- 0E 09 80 10 01 02 04 00 00 00 06 01 00 10 57 (1611998)
<- 0E 0A 80 10 01 02 04 00 00 00 06 01 00 00 57 (1613998)
Volker
x> 10 0A A0 11 32 1C BA 01 02 04 02 01 58 03 20 FF FF (1609490)
RL:trigger11, val:88, rampT:2500, duraT:0
<- 0E 0A 80 02 01 02 04 32 1C BA 01 01 58 60 57 (1609598)
<- 0E 09 80 10 01 02 04 00 00 00 06 01 00 10 57 (1611998)
<- 0E 0A 80 10 01 02 04 00 00 00 06 01 00 00 57 (1613998)
// now it could be a message from the master to us, but master is unknown because we are not paired
if ((isHMIDValid(toId)) && isEmpty(MAID,3)) return 'x';
es scheint der dimmer ist nicht gepaired mit FHEM...
Hallo trilu,
hier noch einmal die serielle Ausgabe und die Angaben zum Device in FHEM. Der Dimmer ist augenscheinlich über FHEM bedienbar nur wird letztenendes der gewünschte Wert nicht gesetzt.
m> 10 3D A0 11 32 1C BA 01 02 04 02 01 62 03 20 FF FF (72275)
RL:trigger11, val:98, rampT:2500, duraT:0
<- 0E 3D 80 02 01 02 04 32 1C BA 01 01 62 60 55 (72382)
<- 0E 05 A0 10 01 02 04 32 1C BA 06 01 00 10 55 (74783)
m> 0A 05 80 02 32 1C BA 01 02 04 00 (74928)
<- 0E 06 A0 10 01 02 04 32 1C BA 06 01 00 00 50 (76783)
m> 0A 06 80 02 32 1C BA 01 02 04 00 (76929)
Volker
das sieht jetzt aber schon besser aus!
m> 10 3D A0 11 32 1C BA 01 02 04 02 01 62 03 20 FF FF (72275)
RL:trigger11, val:98, rampT:2500, duraT:0
m = jetzt ist er gepaired, du setzt einen wert von 98 (0x62) als Dimmwert von max. 200, also etwa 50%
Dann kommt aber eine Ramptime von 2500? Hast du eine Ramptime eingestellt?
Sende den String mal bitte in der Arduino Console an dein Gerät:
10 3D A0 11 32 1C BA 01 02 04 02 01 62 00 00 00 00
und poste das Ergebnis
Hallo trilu,
ich habe den Sketch aus der NewAskSin unverändert in den Arduino hochgeladen, habe also keine Ramptime eingestellt. Wenn ich den String von der Arduino Console sende passiert weder auf der Console noch in den Readings etwas.
Volker
Hallo,
auch von mir vielen herzlichen Dank für die tolle Arbeit an der Asksin library. Ich habe seit einiger Zeit Module wie z.B. HM-PB-2-WM55, HM-MOD-Re-8 und HM_LC_SW4_BA_PCB aus der ersten library erfolgreich am laufen. Vielen Dank auch für die tolle Hilfe zu dem Dimmer. Ich werde mir den dann wohl kaufen.
Volker
Hallo,
ich möchte Asksin auf meinen Panstamps benutzen, bin aber mit der Informationsflut aktuell etwas überfordert.
Gibt es irgendwo eine Informationsquelle, die den aktuellen Stand und ein HowTo enthält?
Ich habe komplett den Überblick verloren, was jetzt Asksin ( für Panstamp oder Arduino + Funkmodul ) betrifft und was diese Platine von Dirk.
Was ich zum Beispiel überhaupt nicht verstehe, ist, wie man die Geräte dann den HM-Units bekannt macht. Ich habe grob verstanden, wie man die Register.h erzeugt, um existierende Geräte zu emulieren. Aber gibt es auch die Möglichkeit, neue Gerätetypen zu definieren, ohne jedesmal die HM-Sources zu ändern?
Was macht man mit diesen DevDefinition.pm ? Wo finde ich die / bzw. wo gehören die hin und was tun sie?
Sorry für die blöden Fragen, aber ich steh echt aufm Schlauch.
Viele Grüße
Carsten
Zitat von: Carsten am 26 Januar 2015, 14:06:31
ich möchte Asksin auf meinen Panstamps benutzen, bin aber mit der Informationsflut aktuell etwas überfordert.
Gibt es irgendwo eine Informationsquelle, die den aktuellen Stand und ein HowTo enthält?
Ich habe komplett den Überblick verloren, was jetzt Asksin ( für Panstamp oder Arduino + Funkmodul ) betrifft und was diese Platine von Dirk.
Hehe, danke! Genau so geht es mir auch. Der Thread ist schon extrem lang geworden. Hatte mich aber auch nicht getraut das mal zu fragen. Sobald ich mal alle Teile zusammen habe und es verstanden habe würde ich auch an einem wiki Artikel dazu mitarbeiten. Aber bis dahin dauert es wohl noch etwas.
VG
Boris
Hallo,
lasst mich doch nicht doof sterben! :'(
Was entgeht mir denn hier? Überall seh ich, dass Funktionen wie culHmModel, culHmRegModel etc. wie selbstverständlich verwendet werden, aber ich finde nirgendwo eine Erklärung dazu.
Gibt es da eine Doku zu? Wie ist das Stichwort?
Viele Grüße
Carsten
Hi Carsten,
hat ja keiner vor, dich doof sterben zu lassen - ich denke so alt bist du noch nicht, das für Erklärungen keine Zeit mehr ist :-)
Es gibt einiges an Doku, aber eben nicht gesammelt.
In der Anfänger Doku FHEM gibt es ein riesen Kapitel zu HM, das ist schon mal ganz hilfreich um Kanäle, Register und deren Settings zu verstehen.
Bei Homegear gibt es auch einiges an Doku zur Kommunikation zwischen Zentrale und Devices.
Ich will mich ja schon seit langem an die Doku für AskSin setzen, aber es kommen immer wieder andere Dinge dazwischen...
Z.b. bastle ich gerade an der destillregs.pm wieder rum. Derzeit erzeugt die destillregs nur die register.h settings. Die sind aber nur für das Device.
Ich möchte in Zukunft noch ein xml file generieren, dass die user-defined Devices dann Homegear oder der CCU bekannt macht.
Momentan ist es am Einfachsten sich an die examples zu halten, die funktionieren so weit schon ganz gut, nächster Schritt ist es dann, wenn die
neue destillregs funktioniert, komplett neue Devices zusammen zu stellen.
Viele Grüße
trilu
Hallo,
ich möchte mich bei der Gelegenheit auch noch mal in Erinnerung bringen. Zum Glück muß ja hier keiner doof sterben.
Ich habe bisher mit FHEM alles Mögliche versucht um z.B. den Dimmer mit irgendeinem x-beliebigen Wert einzuschalten, er fährt aber prinzipiell immer wieder auf Null zurück. Bei set on geht der Dimmer auf Einhundert Prozent und bleibt dort. Auf ein Hochdimmen folgt immer sofort oder nach einer eingestellten Zeit ein Runterdimmen. Der Slider in der FHEM-Oberfläche suggeriert einem daß man den Dimmer auf irgendeinen Wert zwischen Null und Einhundert Prozent einstellen kann. Macht man das wird in den Readings z.B.set_50 angezeigt, kurz darauf geht level wieder auf Null bzw. state auf off.
Volker
Zitat von: trilu am 29 Januar 2015, 17:49:59
Hi Carsten,
hat ja keiner vor, dich doof sterben zu lassen - ich denke so alt bist du noch nicht, das für Erklärungen keine Zeit mehr ist :-)
Hach... Danke! ;)
Zitat von: trilu am 29 Januar 2015, 17:49:59
In der Anfänger Doku FHEM gibt es ein riesen Kapitel zu HM, das ist schon mal ganz hilfreich um Kanäle, Register und deren Settings zu verstehen.
Bei Homegear gibt es auch einiges an Doku zur Kommunikation zwischen Zentrale und Devices.
Ich will mich ja schon seit langem an die Doku für AskSin setzen, aber es kommen immer wieder andere Dinge dazwischen...
Z.b. bastle ich gerade an der destillregs.pm wieder rum. Derzeit erzeugt die destillregs nur die register.h settings. Die sind aber nur für das Device.
Ich möchte in Zukunft noch ein xml file generieren, dass die user-defined Devices dann Homegear oder der CCU bekannt macht.
Die Anfänger-Doku kenne ich. Hab gerade extra nochmal reingeschaut, aber dazu finde ich nichts.
Zu behaupten, dass ich den Arduino-Teil der Asksin-Lib verstanden habe, wäre gewaltig übertrieben, aber ich habe eine ungefähre Ahnung, was sie macht.
Was ich in erster Linie versuche herauszufinden, ist, wie man ein Gerät, das Protokollmäßig nicht 1:1 einem existierenden entspricht, in FHEM bekannt macht.
Wenn ich mir z.B. die HMConfig_SenTHPL.pm von Dirk anschaue, scheint es ja Funktionen zu geben, die die Definitionen da von der Seite aus reinschießen ( "culHmModel" oder "culHmRegModel" ).
Ich finde aber nirgends eine Erklärung, wie das zu benutzen ist und ich weiß auch nicht, nach welchem Stichwort ich dafür suchen soll. Wenn ich nach den beiden Stichworten suche, finde ich nur Detailfragen und Antworten, aber soweit möchte ich überhaupt erstmal kommen.
*edit*
Im Wiki habe ich diesen vielversprechenden Eintrag (http://www.fhemwiki.de/wiki/Neues_HomeMatic_Device) gefunden, der aber leider unvollendet zu sein scheint.
Viele Grüße
Carsten
P.S.: So oder so: Vielen Dank für diese Lib. So viele Möglichkeiten tun sich auf. ( Wenn man es denn verstanden hat )
ZitatWenn ich mir z.B. die HMConfig_SenTHPL.pm von Dirk anschaue, scheint es ja Funktionen zu geben, die die Definitionen da von der Seite aus reinschießen ( "culHmModel" oder "culHmRegModel" ).
das sind funktionen von martin. siehe 10_cul_hm.pm. dazu hmconfig.pm. sie dienen irgendwie dazu, die devices in cul_hm zu definieren.
Hallo Trilu
In der NewAskSin gibt es die Konsolen-Commandos nicht mehr ?!
Wäre es nicht sinnvoll diese analog zu den Debuginfos zu bei Bedarf aktivieren.
Somit braucht für man für Tests z.B. nicht immer den Config-Taster um zu pairen ;)
Gruss Peter
Legende Available commands:
p - start pairing with master
b[0] b[n] s - send a string, b[0] is length (50 bytes max)
i[0]. i[1]. e - show eeprom content, i[0]. start address, i[1]. length
i[0]. b[1] f - write content to eeprom, i[0]. address, i[1] byte
c - clear eeprom complete, write 0 from start to end
t - gives an overview of the device configuration
$nn for HEX input (e.g. $AB,$AC ); b[] = byte, i[]. = integer
Wollte nur mal kurz nachfragen wegen dem Beispiel, wo ein Taster und ein Dimmer gleichzeitig auf einem Arduino laufen.
Geht das noch nicht, oder war bisher nur keine Zeit für das Beispiel?
Danke!
Hallo,
da ich auch großes Interesse am Bauen von custom Homematic Devices hätte, möchte ich mich der Frage anschließen. Wird noch an der Library gearbeitet?
Gruß,
Mathea
Klar wird noch an der Lib gearbeitet, nur leider mit zu wenig Zeit. Dirk hat in der letzten Woche noch Einiges zur HAL beigetragen und strukturiert. Ich bastle zur Zeit wieder mal an der destillRegs, mit der dann Gerätekonfigurationen möglichst einfach erstellt werden sollen. Dimmer und Relay Beispiele müssten funktionieren, der Sensor bedarf noch etwas Arbeit. Danach folgt der Schalter. Ab dann sollten auch alle möglichen Kombinationen gehen.
Viele Grüsse
Horst
Top :) vielen Dank für die ganze Arbeit, die ihr reinsteckt. Das ist bemerkenswert!
Hallo,
Ich möchte mir mittels Ultraschall eine Füllstandsanzeige für meine Zysterne basteln. Bis jetzt hätte ich das mit nem Raspi und ner 2ten Fhem Instanz geplant gehabt. Das würde aber auch bedeuten das ich Kabel verlegen muss und irgendwo einen größeren Kasten benötige wo ich alles rein packen kann.
Wenn ich mir euere Arbeit hier so ansehen und wenn ich es richtig verstehe, könnte ich mir vielleicht das gleiche mit einem Arduino mit Batterie Betrieb (ohne Kabel) in Viel kleiner bauen.
Sehe ich das richtig so oder liege ich total daneben? Bzw. Könnt ihr etwas schätzen wann es evtl soweit sein könnte, dass man eigene HM Komponenten kreieren kann?
Sorry falls die frage blöd ist, aber ich finde das genial was ihr hier auf die Beine stellt. Und wenn es noch ein Jahr dauert würde ich vermutlich auch gerne darauf warten bevor ich Kabel ziehe. ..
Viele Grüsse
Markus
Hallo Zusammen,
zu allererst möchte ich mich für die sehr umfangreiche Arbeit bei den Entwicklern bedanken und möchte mich zukünftig hier auch mit einbringen.
Leider bleibe ich derzeit an einer Fehlermeldung hängen, die definitiv nicht schwer zu lösen ist, doch ich komme nicht drauf.
Aktueller Library Stand ist die NewAskSin-Library, die unter:
▸ Dokumente ▸ Arduino ▸ libraries ▸ NewAskSin
liegt.
Beim öffnen des Sketches und kompilieren kommt die Fehlermeldung:
In file included from hardware.h:9:0,
from hardware.cpp:9:
/Users/CZ/Documents/Arduino/libraries/NewAskSin/HAL.h:76:27: error: 'Print' does not name a type
template<class T> inline Print &operator <<(Print &obj, T arg) { obj.print(arg); return obj; }
^
/Users/CZ/Documents/Arduino/libraries/NewAskSin/HAL.h:85:9: error: 'Print' does not name a type
inline Print &operator <<(Print &obj, const _HEXB &arg) { obj.print(hiHexB(arg.val)); obj.print(loHexB(arg.val)); return obj; }
^
In file included from hardware.h:9:0,
from hardware.cpp:9:
/Users/CZ/Documents/Arduino/libraries/NewAskSin/HAL.h:92:9: error: 'Print' does not name a type
inline Print &operator <<(Print &obj, const _HEX &arg) { for(uint8_t i=0;i<arg.len;i++) { obj.print(hiHexB(arg.val[i])); obj.print(loHexB(arg.val[i])); if(i+1<arg.len) obj.print(' '); }; return obj; }
^
/Users/CZ/Documents/Arduino/libraries/NewAskSin/HAL.h:95:9: error: 'Print' does not name a type
inline Print &operator <<(Print &obj, _eTIME arg) { obj.print('('); obj.print(getMillis()); obj.print(')'); return obj; }
^
Fehler beim Kompilieren.
Woran kann das liegen? ( nicht gefundene Library sollte ja als zusätzliche Fehlermeldung auftauchen?!?! )
Grüße
Christopher
Hi,
in HAL.h wird ein
#include "Print.h"
benötigt. Möglicherweise abhängig von der verwendeten Arduino-Version?
Ich will einen Helligskeitsensor bauen. Habe mir Arduino 1.6.4 mit Panstamp-Patch geladen und die Lib aus dem Git. Custom_lux geöffnet und kompiliert, doch es will nicht, da Serial in der .ino und HAL nicht definiert sind, wenn ich SoftwareSerial einbinden, dann gibt es Konflikte :(
Warum vergisst diese Forum den Beitrag, wenn man angeblich die Rechenaufgabe falsch hat oder Zitronen nicht gelb sind
Hier nochmal die Fehlermeldung, falls nicht klar war wo:HM_Helligkeitssensor.ino:110:2: note: in expansion of macro 'dbg'
HM_Helligkeitssensor.ino: In function 'void measureTH1()':
arduino-1.6.4\libraries\NewAskSin/HAL.h:77:14: error: 'Serial' was not declared in this scope
#define dbg Serial
^
HM_Helligkeitssensor.ino:119:2: note: in expansion of macro 'dbg'
HM_Helligkeitssensor.ino: In function 'void serialEvent()':
HM_Helligkeitssensor:128: error: 'Serial' was not declared in this scope
'Serial' was not declared in this scope
Hi, versuch mal, als Board den
Arduino Pro or Pro Mini (3.3V, 8MHz) w/ ATmega328
wählen, damit sollte alles tun. Die AskSin Library bringt ohnehin alles mit, was Du brauchst.
Grüße,
Andy.
Ohne Panstamp-Patch kompiliert es! Danke
EDIT: Kann es sein, dass das SendDelay von THSensor nicht funktioniert, wenn es größer als 32 Sekunden ist?
hallo trilu,
ich versuche gerade der alternativen firmware für den sw1pbu-fm das sensor_event beizubringen. dazu habe ich mir deine umsetzung in der newasksin-library (trigger41) kopiert und angepasst. dabei sind mir ein paar fehler bei den vergleichen aufgefallen (fälle 0,1,4,5). jedes "msgVal > ..." müsste in "msgVal >= ..." geändert werden. ausserdem sollte es im fall 5 (outS) eine oder-verknüpfung sein.
// X GE COND_VALUE_LO - geLo - >= low - 0
// X GE COND_VALUE_HI - geHi - >= high - 1
// X LT COND_VALUE_LO - ltLo - < low - 2
// X LT COND_VALUE_HI - ltHi - < high - 3
// COND_VALUE_LO LE X LT COND_VALUE_HIGH - betW - low <= X > high - 4
// X LT COND_VALUE_LO OR X GE COND_VALUE_HIGH - outS - < low or >= high - 5
//dbg << "curStat: " << curStat << ", isLng: " << isLng << ", val: " << msgVal << ", cond: " << ctTbl << '\n';
if (ctTbl == 0) if (msgVal >= l3->ctValLo) trigger40(isLng, msgCnt);
else if (ctTbl == 1) if (msgVal >= l3->ctValHi) trigger40(isLng, msgCnt);
else if (ctTbl == 2) if (msgVal < l3->ctValLo) trigger40(isLng, msgCnt);
else if (ctTbl == 3) if (msgVal < l3->ctValHi) trigger40(isLng, msgCnt);
else if (ctTbl == 4) if ((msgVal >= l3->ctValLo) && (msgVal < l3->ctValHi)) trigger40(isLng, msgCnt);
else if (ctTbl == 5) if ((msgVal < l3->ctValLo) || (msgVal >= l3->ctValHi)) trigger40(isLng, msgCnt);
gruss frank
oh, danke. ja mit den msgval's habe ich mich noch nicht viel gespielt
viele grüße
trilu
Hallo,
interessantes Projekt, habe mir deshalb heute Arduino 1.6.4 installiert und auch die ASKIN-Library vom https://github.com/trilu2000/AskSin (ftp://github.com/trilu2000/AskSin) herunterladen. Wie beschrieben unter D:\Program Files\Arduino\libraries\AskSinmaster\.. entpackt. Dann versucht die Besipiele aufzurufen, leider kommt dann immer die Fehlermeldung
In file included from HM_LC_Sw1_Pl.ino:4:0:
Register.h:1:24: fatal error: AskSinMain.h: No such file or directory
#include <AskSinMain.h>
^
compilation terminated.
Fehler beim Kompilieren.
Habe schon mehrfach hin und her kopiert, die Files werden aber nie gefunden. :(
Kann mir jemand schnell mal auf die Sprünge helfen.
Danke
Zitat von: Maxl am 21 Mai 2015, 16:49:33
https://github.com/trilu2000/AskSin (ftp://github.com/trilu2000/AskSin)
Es gibt mittlerweile unter https://github.com/trilu2000/NewAskSin eine überarbeite Version, ist aber egal, die alte funktioniert grundsätzlich auch
Zitat von: Maxl am 21 Mai 2015, 16:49:33
D:\Program Files\Arduino\libraries\AskSinmaster\..
Bitte entferne das "-master", das macht GitHub dahin, weil man sonst die Branches nicht unterscheiden könnte
Hallo,
ich habe mir die neue Version unter https://github.com/trilu2000/NewAskSin (ftp://github.com/trilu2000/NewAskSin) heruntergeladen, die funktioniert wie beschrieben, Askinnew_Test ohne Fehler kompiliert. Anschliessend hätte ich das Tasterprojekt HM_LC_Sw1_PI kompilieren wollen, dafür aus dem alten Example Verzeichnis ins neue kopiert, gleiche Fehlermeldung wie vorher. Im testprojekt wird aber wie ich es verstehe keine Asksin.h includiert.
Gruß
die beiden versionen sind nicht kompatibel. hin und her kopieren der beispiele kann nicht funktionieren.
im prinzip ist die newasksin besser, da ziemlich viele änderungen und erfahrungen aus dem ersten anlauf eingeflossen sind.
die newasksin müsste mit den beispielen auch soweit funktionieren. einzig es fehlt die key-class, damit ist das simulieren des hm schalters derzeit nicht möglich.
Hallo,
ist irgendwo ein Beispiel für einen Taster mit Relais wie das HM_LC_Sw1_PI oder was mache ich mit der alten AskSin-Version falsch.
Danke
nein, in der neuen lib gibt es so ein beispiel noch nicht
du kannst dich aber am HM_LC_SW1_BA_PCB orientieren, eigentlich nichts anderes als der steckdosenzwischenschalter.
Für ein THSensor-basierendes System an Homegear muss man die Event-ID in einem der beiden System zuschießen, ist die Event-ID absichtlich so gewählt oder einfach nicht aufgefallen, weil FHEM das egal ist?Habe gerade nocheinmal in den Code geschaut und gesehen sendWeatherEvent exsiteriert, hat aber keinen Inhalt, man könnte ja erstmal die Funktion genau so aufbauen wie sendSensor_event, nur mit anderem mTyp
Jetzt muss ich nur noch lösen wie man weniger als alle 30 Sekunden sendet, siehe
Zitat von: wirfman am 16 Mai 2015, 22:59:45
EDIT: Kann es sein, dass das SendDelay von THSensor nicht funktioniert, wenn es größer als 32 Sekunden ist?
eigentlich dürfte es da keine limitierung geben, wieso möchtest du kleiner 30 sekunden senden?
Ich möchte weniger senden, also mehr als 30 Skeunden einstellen, aber bei 2*30 Sekunden geht es schon nciht mehr(siehe nächsten Post)
Kommando zurück! Es lag an der Multiplikation für die Millisekunden >:(
kurze Zwischenfrage:
ich möchte 2x HM_LC_SW1_BA_PCB mit verschiedenen Seriennummern an der CCU2 betreiben.
Wenn ich in der register.h in den Zeilen 7 und 11 "tlu1001235" mit beispielsweise "tlu1001237" überschreibe, dann kann ich das zweite Gerät (mit der 7) nicht mehr anlernen.
CCU2 erkennt die zweite Platine automatisch und steuert die beiden gleichzeitig. Muss die Seriennummer dann noch irgendwo geändert werden?
Danke
Es gibt zwei Variablen die du ändern musst. Die Seriennummer und die HMId. Die Seriennummer wird eigentlich nur zum Pairen verwendet. Die HMId bei jeder Kommunikation.
Super, jetzt funktioniert es! :D
Die Doku ist leider noch unvollständig und der Thread zu unübersichtlich geworden.
Wird es noch weitere Beispiele geben wie Taster oder Bewegungsmelder?
Danke Trilu.
ja, wird es - ich habe einfach zu wenig zeit :-)
aber meine anderen baustellen sind jetzt einigermassen fertig - so dass ich hier definitiv wieder weitermachen möchte
brauche immer noch ein paar sensoren, den dimmer muss ich noch ein wenig umbauen damit die nicht lineare helligkeitssteuerung für leds besser klappt, einen sensor schalter hätte ich auch noch gerne, zum strom und gas zähler ablesen will ich nicht in den keller ....
Hallo!
Nachdem ja nun a) der AES-Schlüssel ab Werk bekannt ist und b) der AES-Signing Algorithmus (https://git.zerfleddert.de/hmcfgusb/AES/) bekannt ist, wollte ich mal nachfragen, ob hier schon an dem Einbau in die Asksin-Lib gearbeitet wird?
(siehe auch: http://forum.fhem.de/index.php?topic=38317.0)
Hallo,
ich habe dazu auch eine Frage
Gibt es damit eine Chance neue Firmware zu erstellen, die sich OTA einspielen lässt, ohne den Bootloader flashen zu müssen?
Der Schaltaktor ist ja von sich aus bereits OTA-fähig.
Danke
Chipmunk
Hallo Zusammen,
Dirk hat bereits an der Implementierung von AES gearbeitet, erste Teile sind bereits im Github. Habe aber noch nicht getestet.
Eigene Soft über einen HM Overtheair Bootloader wird wohl in absehbarer Zeit nicht funktionieren, da die Verschlüsselung der Firmware nicht bekannt ist.
Es gibt aber von Dirk einen OTA Bootloader für Arduino, damit klappts. Ist im Thermometer/Hygrometer Thread.
Viele Grüße
Horst
Hallo Horst,
bau gerade nach längerer Pause an meinem Sensor weiter. Im Moment versuche ich herauszufinden, wie ich in NewAskSin für List0 Defaultwerte definieren kann. Gibt es dafür eine Möglichkeit?
Danke,
Andy.
Hi Andy,
sorry, zu spät gesehen. Klar gibt es eine Funktion dafür, ist nur noch nicht dokumentiert :-)
Zuerst musst du ein Array erzeugen das die Länge der List0 in Byte hat, dieses Array übergibst Du mit folgender Funktion
hm.ee.uint8_t EE::setListArray(uint8_t cnl, uint8_t lst, uint8_t idx, uint8_t len, uint8_t *buf) {
Parameter - Channel, List sind klar - Index, falls es eine List3 oder 4 ist abhängig von der Peer Position.
Len Länge des Arrays und der Pointer zum Array.
Um ein Peer per default einzufügen:
uint8_t pT[] = {0x01,0x02,0x04,0x01,0x00};
hm.ee.addPeer(1, pT);
Viele Grüße
Horst
Hi Horst,
danke für den Tipp! Wann rufe ich die Funktion auf, ich vermute mal das kommt nach dem Aufruf von AS::init() ?
Wird der Inhalt von buf dann auch ins EEProm geschrieben falls dieses noch ungültige Daten enthält? Und bleiben später die Daten erhalten wenn ich per regSet etwas geändert habe?
Im Moment ist es so, dass die Register allesamt auf 0 stehen wenn sich hinreichend viel geändert hat. Ich fange das dadurch ab, dass ich dann intern einen anderen Wert (z.B. für measureInterval) verwende, der Registerinhalt wird von FHEM aber immer noch als 0 ausgelesen. Eleganter fände ich, wenn nach dem ersten FW-upload die Registerinhalte auf meinen Defaults stehen, die ich dann bei Bedarf mit regSet ändere (von wo an die Defaults nicht mehr gelten).
So wie ich setListArray() verstehe, kann ich für einen neuen Peer die Defaults für List1 und List3/4 festlegen, die dann ins EEprom geschrieben werden, wenn ich den Peervorgang initiiere. Registerinhalte für bestehende Peers dürften davon unberührt bleiben.
Aber wie funktioniert das bei List0, wird hier der Inalt von buf beim pairing ins EEprom geschrieben? Wie ist es dann wenn mein Sensor notfalls ungepaired an broadcast senden und dazu mit den Default-Einstellungen aus der List0 arbeiten soll?
Ich werde mal setListArray() testen (sehe gerade dass es ein (auskommentiertes) Beispiel in examples/HM_LC_Dim1PWM_CV gibt), geht aber eher gemächlich voran..
Etwas OT, aber weil wir gerade beim Dimmer Beispiel sind: Ich habe damit gelernt, wie ich ein PWM Signal ausgebe und habe versucht, eine RGB-Led per PWM anzusteuern. Resultat meiner zahlreichen Versuche: an/aus-Schalten der drei output-pins funktioniert noch (langweilig, nur 8 Farben), PWM auf Rot (PORTD5/OCR0A) und Grün (PORTD6/OCR0B) auch, nur meine blaue LED (PORTB1/OCR1A) bleibt aus, dafür geht die interne Uhr plötzlich nur noch halb so schnell. Mein Code für die PWM-Ausgabe:
void init_RGB()
{
dbg << "init pwm\n";
// Timer0 (8Bit)
DDRD |= (1 << DDD6); // PD6 is now an output (OC0A) GRN
DDRD |= (1 << DDD5); // PD5 is now an output (OC0B) RED
OCR0A = 128; // set PWM for 50% duty cycle GRN
OCR0B = 128; // set PWM for 50% duty cycle RED
TCCR0A |= (1 << COM0A1)| (1 << COM0B1); // set none-inverting mode
TCCR0A |= (1 << WGM01) | (1 << WGM00); // set fast PWM Mode
TCCR0B |= (1 << CS01); // set prescaler to 8 and starts PWM
DDRB |= (1 << DDB1); // PB1 is now an output (OC1A) BLU
TCCR1A |= (1 << COM1A1); // set none-inverting mode
TCCR1A |= (1 << WGM10);
TCCR1B |= (1 << WGM12); // set Fast PWM mode, 8bit, TOP 0xff
TCCR1B |= (1 << CS10); // set prescaler to 8 and starts PWM
}
void set_RGB(byte r, byte g, byte b)
{
OCR0A = g; // set PWM for 50% duty cycle GRN
OCR0B = r; // set PWM for 50% duty cycle RED
OCR1A = b; // set PWM for 50% duty cycle BLU
}
Ist aber nicht soo wichtig, nur ein Nebenschauplatz. Hat sicher damit zu tun, dass einer der Timer für die Systemzeit dient, die über getMillis() statt millis() auszulesen ist.
Danke für Deine Unterstützung,
Grüße,
Andy.
Ich habe zwei neue Funktionen in die library integriert - sind auf dem Git im master branch verfügbar.
Die Funktionen befinden sich in der register.h des sketches, hab sie auch in die Beispiele integriert.
void everyTimeStart(void) {
// place here everything which should be done on each start or reset of the device
// typical use case are loading default values or user class configurations
}
void firstTimeStart(void) {
// place here everything which should be done on the first start or after a complete reset of the sketch
// typical use case are default values which should be written into the register or peer database
}
firstTimeStart wird beim ersten Start des Devices angesprungen, also nicht bei einem Reset oder Restart, weil Strom unterbrochen war.
Ich prüfe das gegen eine Magic Nummer die ins EEprom geschrieben wird. Die Magic Nummer ist abhängig von der Register Definition in register.h
Damit möchte ich erreichen das ich Code ändern kann, ohne das jedes mal der EEprom überschrieben wird. Wenn ich aber an einem neuen Device arbeiten möchte, das erkannt wird und der EEprom geläuscht wird.
Diese Funktion eignet sich also für das Setzen von Default Werten.
everyTimeStart wird nach dem Einschalten bzw. einem Reset angesprungen. Damit eignet sich die Funktion für das setzen von Default Werten die Grundsätzlich gebraucht werden. Hier hin möchte ich nach und nach die Starteinstellungen verlagern.
Also alle Funktionen wie das hier:
hm.confButton.config(1, CONFIG_KEY_PCIE, CONFIG_KEY_INT); // configure the config button, mode, pci byte and pci bit
hm.ld.init(2, &hm); // set the led
hm.ld.set(welcome); // show something
hm.pw.setMode(1); // set power management mode
hm.bt.set(27, 600000); // 3600000 = 10min. // set battery check, internal, 2.7 reference, measurement each hour
Damit zu deinen weiteren Fragen - setze deine Default Werte für List0 in der Funktion firstTimeStart. Wenn du im laufenden Betrieb neue Register Inhalte setzt, wird der Default Wert im EEprom überschrieben und bleibt erhalten.
Mit setListArray kannst du prinzipiell in jede List schreiben, also auch in List3 und 4. Hier musst du aber die Index Position der Peer-Adresse beachten. Es gibt ja eine eigene List3/4 für jede PeerID - Ich habe deshalb das setzen der List3/$ Default Werte in die User Module verlagert.
Das setzen der Default Werte in List3/4 wird beim peering automatisch gemacht. Kannst du dir in der Dimmer Class anschauen.
Das PWM Problem beim Dimmer kenne ich :-) Der 328 hat leider nur 3 Timer und einen benötige ich für die millis() - Das Problem hättest du aber auch ohne AskSin. Um einen 3 Kanal Dimmer zu bauen gibt es drei Möglichkeiten - auf einen anderen Chip mit mehr PWM Kanälen auszuweichen, wie den 644 oder 32u4. Eine zusätzliche HW zu verwenden, es gibt einen I2C nach PWM Baustein. Weiss gerade nicht mehr wie der heißt.
Oder diese 2811/12 LED Bänder mit eingebauter Logic verwenden...
So, ganz schön viel Text - Teste mal ob du mit den neuen Funktionen klar kommst ...
Viele Grüße
Horst
Super, genau das meinte ich, vielen Dank für die beiden Funktionen, damit komme ich gut zurecht :-) Feedback kommt nach den Tests
An einen externen PWM controller mit i2c hatte ich auch schon gedacht, der PCA9685 ist mit 12 bit ganz gut, um eine halbwegs brauchbare brightness/luminance Anpassung hinzubekommen ohne wahrnehmbare Helligkeitssprünge im unteren Bereich. Mit 16 Kanälen ist er natürlich etwas überdimensioniert. Es gibt sicher andere die besser in Frage kämen, aber mein Hauptproblem ist im Moment, dass ich schon Probleme habe, den code für den BMP185 noch in den Speicher meines Panstamp zu bekommen, der auch über i2c angebunden ist. Dann wird das Firmware Image so groß, dass nach dem upload bei Byte 0x7000 ein verify-error geworfen wird. Deshalb hatte ich gehofft, es gibt eine Möglichkeit, den internen pwm zu verwenden. Komplett vom Panstamp verabschieden würde ich mich bei dem Projekt auch nur ungern, zur Not lieber Features abspecken.
Welchen timer verwendest du denn für millis? Im Grunde komme ich ja für rot und grün mit nur einem timer (Timer0) aus, dessen zwei compare-Register für die PWM herhalten. Der Timer1 sollte die blaue LED bedienen, was aber so gar nicht tun will, also vermute ich mal du verwendest den. Timer2 hatte ich noch nicht in Betracht gezogen, weil dessen einziger verfügbare Pin D3 (der andere ist SPI MOSI) bei mir belegt ist. Sollte ich aber umwidmen können, noch existiert der Sensor nur auf dem Steckbrett. Oder ist Timer2 auch belegt?
Beste Grüße,
Andy.
Hallo Horst, hab mir vor Arbeitsbeginn noch kurz versucht, die Änderungen von github zu pullen, dort ist die letzte Änderung aber der 6 Tage alte commit 70a8151 - darf ich Dich bitten, deine letzten Änderungen noch zu pushen? :-)
Danke,
Andy.
stimmt, habe vergessen auf den knopf zu drücken - jetzt ist es im git :-)
Danke Horst, habs gepullt und getested, funktioniert wie ich es mir erhofft hatte :-)
Kleiner Unterschied: Das übergebene Array muss nicht alle Bytes der Channel-List angeben, vielmehr muss ein Array von Paaren aus REGNUM:VALUE übergeben werden. Ich habe die Funktion mal so dokumentiert, wie ich sie verstanden habe (und hochgeladen) Schau bitte, ob Du damit einverstanden bist, dann pushe ich das zusammen mit einer minimalen Änderung (const für uint8_t*buf, sollte ohne Auswirkung auf bestehenden Code bleiben).
Zudem habe ich testhalber in AS::recvMessage einen Aufruf an firstTimeStart() bei einem RESET eingefügt. So kann ich meine aktuellen Factory-Defaults sehr schön von FHEM aus laden :-)
Aktuell nur bei mir lokal, bis Du dein OK gibst.
Grüße,
Andy.
du hast recht - setlistarray erwartet die addresse und das byte
gibt aber noch eine weitere funktion
uint8_t setList(uint8_t cnl, uint8_t lst, uint8_t idx, uint8_t *buf); // set a complete list to the eeprom
hier wird einfach nur die list ins eeprom geschrieben, d.h. man braucht keine addressierung und spart die addressbytes im flash :-)
deine änderungen schau ich mir nach dem grillen an 8)
hi andy,
in welchem branch finde ich deine änderungen - ist das in gh-pages?
sehe in gh-pages aber auch, das jede menge files einfach nur gelöscht sind...
mhhh, ich hab zu wenig ahnung von github ::)
aber grillen war lecker!
horst
Nachträglich noch guten Appetit - heute reicht's sicher die Würstchen zum Grillen auf den nächst größeren Stein zu legen :-)
Die Änderungen an EEprom.cpp und EEprom.h (Dokumentation der setListArray()) gibt es aktuell nur in meiner Arbeitskopie, noch nicht in einem der Branches auf GitHub. Daraus habe ich mit Doxygen neue HTML-Seiten erzeugt (Stand heute, master-branch + meine Änderungen) und die Webseiten nach gh_pages auf GitHub gepusht. Damit sind sie über http://trilu2000.github.io/NewAskSin zugänglich, weil gh_pages ein spezieller Branch zum Hosten der Projekt-Webseiten ist (insbesondere kann man nicht unterscheiden zwischen Seiten die für den einen oder anderen Branch gedacht sind). Wenn Du jetzt eigene Seiten dort vermisst, vermute ich, dass Du diese ursprünglich aus dem dev-Branch erzeugt hattest? Kann auch sein, dass Du eine andere Doxygen Version verwendest, die die Seiten etwas anders erstellt.
Edit: Kann auch sein dass ich das nächste mal erst ein 'git pull' absetze bevor ich loslege... :o man sollte mich ab 28° Aussentemperatur einfach nichts tun lassen 8)
So oder so stellt sich die Frage für die Dokumentation, auf welches Vorgehen wir uns einigen wollen. Vielleicht sollte nur einer von uns die Seiten für gh_pages erzeugen, dann immer aus dem gleichen branch, vorzugsweise master, wenn der die aktuell gültige Version enthält. Statt direkt auf gh_pages zu schreiben könnte ich dir auch einen temporären Link auf die mit noch nicht committeten Quellen erzeugte Seite schicken.
Und danke für den Tip mit setList(), ich versuche die bei der Gelegenheit mal zu dokumentieren und schick Dir dann einen Link auf die betreffende Seite(n) zum Review. Soll ich in master oder dev dokumentieren?
Verstanden, hatte mich schon gewundert. Habe gerade master und dev gemerged. Sind also wieder gleich. Lass uns den Master zum Dokumentieren verwenden. Master sollte zu jeder Zeit lauffähig sein. Dev zum trsten und basteln..
Das mit dem doxygen ist mir noch nicht ganz klar, ich glaube da muss ich noch lesen. Ich werde in Zukunft halt im Master dokumentieren und Du sorgst von Zeit zu Zeit für ein aktuelles doxygen?
Langsam wird die Wärme schon unangenehm, in der Arbeit ist schöner weil gut klimatisiert :-)
Gern auch so :) Neue Funktionen können natürlich auch gleich in dev dokumentiert werden, erscheinen dann mit Übernahme des neuen Codes in master auch gleich in der offiziellen API-Dokumentation.
Ich such gern den oder die Links raus wo ich damals das mit den gh_pages gefunden hatte. Eine Kurzzusammenfassung habe ich mit doc/Readme.md versucht, könnte aber noch ausbaufähig sein...
In der Arbeit ist das Fenster die Klimaanlage der Wahl - dafür bleibts zuhause dank FHEM und reichlich HM-LC-Bl1PBU-FM trotz viel Fensterfläche halbwegs erträglich, im Moment ist draussen immer noch wärmer als drinnen ;D
Hi Horst,
nachdem es draussen kaum auszuhalten ist, habe ich ein wenig geschrieben und dabei auch ein wenig mehr verstanden, zumindest denke ich das. Die Änderungen an der Doku sind auf origin/master gepusht und gh_pages habe ich aktualisiert. Magst Du Dir bitte die Seiten http://trilu2000.github.io/NewAskSin/classEE.html und http://trilu2000.github.io/NewAskSin/EEprom_8h.html aufmerksam durchlesen, ob ich alles korrekt beschrieben habe? Ich habe gerade den Eindruck, es schölt sich ein Konzept für die Doku von register.h Inhalten heraus, ein paar Steinchen fehlen mir noch.
Viele Grüße,
Andy.
Ich bin echt begeistert von dem doxgen - sieht Klasse aus und geht absolut in die richtige Richtung
Helper class for providing access to non-volatile data in the EEprom.
This class is used by the main AS class to handle non-volatile data stored in the EEprom and accessed in form of Registers in the context of Lists.
As a second function it is also handling the Peer database, to validate incoming messages or as a information provider for outgoing messages.
Every device requires a set of definitions that define its properties and capabilities.
Todo:
Describe device properties and how they are represented (register.h)
A subset of definitions provided within the register.h is directly depending on the EE Class.
//- channel slice address definition -------------------------------------------------------------------------------------
const uint8_t cnlAddr[] PROGMEM = {
0x05, 0x0a, 0x0b, 0x0c, 0x12,
0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8c,
}; // 27 byte
The channel address table reflects a collection of available register addresses. In the example above you find in the first line the definition for channel 0, list 0
0x0a, 0x0b, 0x0c is the address for storing the pair id.
2nd line reflects channel >1, list 3 for a switch channel.
//- channel device list table --------------------------------------------------------------------------------------------
EE::s_cnlTbl cnlTbl[] = {
// cnl, lst, sIdx, sLen, pAddr;
{ 0, 0, 0x00, 5, 0x000f },
{ 1, 1, 0x05, 0, 0x0014 },
{ 1, 3, 0x05, 22, 0x0014 },
}; // 12 byte
The channel table reflects the real configuration of the device. The first variable refelcts the channel, 2nd the respective list, 3rd the slice index, 4th the len in bytes of the assigned slice and the 5th variabl gives the address were the information gets stored in the eeprom.
Analysing this line for explanation { 0, 0, 0x00, 5, 0x000f },
It is the configuration for channel 0, list 0 (first two parameters)
Slice index starts at byte 0 with a 5 byte len, have a look now on the channel address table - 0x05, 0x0a, 0x0b, 0x0c, 0x12,
These are the register address bytes which are valid for channel 0, list 0
Last parameter within the line - 0x000f is the address were the values for the register bytes are stored.
//- peer device list table -----------------------------------------------------------------------------------------------
EE::s_peerTbl peerTbl[] = {
// cnl, pMax, pAddr;
{ 1, 6, 0x0098 },
}; // 4 byte
As the second function for the ee class is to remember on peer addresses, there is a database in place to store the details.
This database is defined by the peer table and you have to define it per channel.
Explanation of the example above - { 1, 6, 0x0098 },
Channel 1, is able to store 6 peer addresses at eeprom address 0x0098
//- handover to AskSin lib -----------------------------------------------------------------------------------------------
EE::s_devDef devDef = {
1, 3, devIdnt, cnlAddr,
}; // 10 byte
The device definition table holds the overall information regarding available channels, lists and points to the respective structs in the register.h
Within the example you see - we have a device with 1 Channel (1st value), 3 Lists as defined in the channel table and two pointers.
First pointer refers to a byte array, which holds the information mainly used for the pairing string.
//- settings of HM device for AS class -----------------------------------------------------------------------------------
const uint8_t devIdnt[] PROGMEM = {
/* Firmware version 1 byte */ 0x10,
/* Model ID 2 byte */ 0x00, 0x6c,
/* Sub Type ID 1 byte */ 0x00,
/* Device Info 3 byte */ 0x41, 0x01, 0x00,
};
Second pointer points to the slice address table.
Hallo Horst,
danke für Dein Feedback und den weiteren Input. In der Tat hatte ich schon angefangen, die structures zu dokumentieren, brauch aber noch, um das ein wenig glattzuziehen. Eine Frage hat sich allerdings für mich ergeben: s_devDef benutzt einen Pointer auf den device identifier, der aber nicht weiter über eine struct definiert ist. Hat das eine besondere Bewandtniss, warum Du das so gelöst hast und nicht über weitere Member der s_devDef? Und welche Bedeutung und Auswirkung haben die letzten 3 Bytes für "Device Info" (evtl einzelner Bits darin?)
Ich hatte vergessen auf http://trilu2000.github.io/NewAskSin/structEE_1_1s__cnlTbl.html hinzuweisen, in der ein (kleines) Beispiel für diese struct enthalten ist, wobei ich das derweil überarbeitet und ähnliches auch für die anderen structs gemacht habe. Bestimmt hast du das auch so gefunden :) In die Beschreibung der class EE habe ich jetzt einen Verweis auf diese Structs aufgenommen, was aber nicht so den Überblick vermittelt, den ich mir vorstellen würde. Vielleicht wäre das die richtige Stelle für ein komplettes Beispiel einer Device-Definition incl peerTbl und cnlTbl - mal überlegen.
Was mir auch noch nicht ganz klar ist (ich aber denke ich schonmal verstanden hatte) ist, woher Adresse 0x000f für die List0/Channel0 kommt, sprich: was ist im EEprom auf 0x0000-0x000e gespeichert?
Danke schonmal,
Andy.
sehr gerne, danke dir, für das dokumentieren!
Der devIdnt ist eigentlich nicht wichtig und ist ein relikt aus der ersten version der asksin lib - der string wird nur für den pairing string verwendet, deshalb habe ich das als string definiert.
const uint8_t devIdnt[] PROGMEM = {
/* Firmware version 1 byte */ 0x10,
/* Model ID 2 byte */ 0x00, 0x6c,
/* Sub Type ID 1 byte */ 0x00,
/* Device Info 3 byte */ 0x41, 0x01, 0x00,
};
This information are only needed for a proper device pairing and double checked by the HM configuration software or FHEM.
Firmware version is needed by the HM config soft to identify the set of registers/channels within the XML file.
Model Id is the real identifier of the device:
ModelID FW
0x0060 0x00 HM-PB-4Dis-WM HM Remote Display 4 buttons rf_4dis.xml
0x007e 0x00 ZEL STG RM DWT 10 HM Remote Display 4 buttons Roto rf_4dis.xml
0x008e 0x00 263 155 HM Remote Display 4 buttons Schueco rf_4dis.xml
0x000e 0x00 ASH550I ASH550I rf_ash550.xml
0x000d 0x00 ASH550 ASH550 rf_ash550.xml
0x003d 0x00 HM-WDS10-TH-O HM-WDS10-TH-O rf_ash550.xml
0x0093 0x00 263 158 HM-WDS10-TH-O Schueco rf_ash550.xml
0x003c 0x00 HM-WDS20-TH-O HM-WDS20-TH-O rf_ash550.xml
0x003f 0x00 HM-WDS40-TH-I HM-WDS40-TH-I rf_ash550.xml
0x0094 0x00 263 157 HM-WDS40-TH-I Schueco rf_ash550.xml
0x0048 0x00 IS-WDS-TH-OD-S-R3 IS-WDS-TH-OD-S-R3 rf_ash550.xml
0x0006 0x00 HM-LC-Bl1-SM radio-controlled blind actuator 1-channel (surface-mount) rf_bl.xml
0x0005 0x00 HM-LC-Bl1-FM radio-controlled blind actuator 1-channel (flush-mount) rf_bl.xml
0x0053 0x00 HM-LC-Bl1-PB-FM radio-controlled blind actuator 1-channel (flush-mount) rf_bl.xml
0x007b 0x00 ZEL STG RM FEP 230V radio-controlled blind actuator 1-channel (flush-mount) Roto rf_bl.xml
0x0086 0x00 263 146 radio-controlled blind actuator 1-channel (flush-mount) Schueco rf_bl.xml
0x006a 0x22 HM-LC-Bl1PBU-FM radio-controlled blind actuator 1-channel (flush-mount) rf_bl_conf_644.xml
0x0087 0x22 263 147 radio-controlled blind actuator 1-channel (flush-mount) Schueco rf_bl_conf_644.xml
0x006a 0x20 HM-LC-Bl1PBU-FM radio-controlled blind actuator 1-channel (flush-mount) rf_bl_conf_644_le_v2_1.xml
0x0087 0x20 263 147 radio-controlled blind actuator 1-channel (flush-mount) Schueco rf_bl_conf_644_le_v2_1.xml
0x0095 0x00 HM-CC-RT-DN ClimateControl-RadiatorThermostat rf_cc_rt_dn.xml
0x00bd 0x00 HM-CC-RT-DN-BoM ClimateControl-RadiatorThermostat rf_cc_rt_dn_bom.xml
0x0039 0x20 HM-CC-TC ClimateControl-ThermoControl rf_cc_tc.xml
0x0079 0x20 ZEL STG RM FWT ClimateControl-ThermoControl Roto rf_cc_tc.xml
0x0039 0x19 HM-CC-TC ClimateControl-ThermoControl rf_cc_tc_le_v1_9.xml
0x003a 0x00 HM-CC-VD ClimateControle-ValveDrive rf_cc_vd.xml
0x007a 0x00 ZEL STG RM FSA ClimateControle-ValveDrive Roto rf_cc_vd.xml
0x005c 0x10 HM-OU-CF-Pl radio chime with light flash rf_cf.xml
0x0075 0x10 HM-OU-CFM-Pl radio chime with light flash rf_cfm.xml
0x00af 0x10 HM-OU-CM-PCB wireless chime module mp3 with memory rf_cm.xml
0x0018 0x00 CMM CMM rf_cmm.xml
0x0013 0x20 HM-LC-Dim1L-Pl 1 channel dimmer L (plug) rf_d.xml
0x00a3 0x20 HM-LC-Dim1L-Pl-2 1 channel dimmer L (plug) rf_d.xml
0x0012 0x20 HM-LC-Dim1L-CV 1 channel dimmer L (ceiling voids) rf_d.xml
0x0088 0x20 263 132 1 channel dimmer L (ceiling voids) Schueco rf_d.xml
0x0016 0x20 HM-LC-Dim2L-CV 2 channel dimmer L (ceiling voids) rf_d.xml
0x002e 0x20 HM-LC-Dim2L-SM 2 channel dimmer L (surface mount) rf_d.xml
0x004e 0x16 HM-LC-DDC1-PCB radio-controlled door drive controller 1-channel (PCB) rf_ddc.xml
0x006f 0x25 HM-LC-Dim1L-Pl-644 1 channel dimmer L (plug) rf_dim_1l_644.xml
0x006e 0x25 HM-LC-Dim1L-CV-644 1 channel dimmer L (ceiling voids) rf_dim_1l_644.xml
0x00b3 0x25 HM-LC-Dim1L-Pl-3 1 channel dimmer L (plug) rf_dim_1l_644.xml
0x00b7 0x25 HM-LC-Dim1L-CV-2 1 channel dimmer L (ceiling voids) rf_dim_1l_644.xml
0x006f 0x24 HM-LC-Dim1L-Pl-644 1 channel dimmer L (plug) rf_dim_1l_644_le_v2_4.xml
0x006e 0x24 HM-LC-Dim1L-CV-644 1 channel dimmer L (ceiling voids) rf_dim_1l_644_le_v2_4.xml
0x0067 0x25 HM-LC-Dim1PWM-CV 1 channel dimmer PWM (ceiling voids) rf_dim_1pwm_644.xml
0x00b5 0x25 HM-LC-Dim1PWM-CV-2 1 channel dimmer PWM (ceiling voids) rf_dim_1pwm_644.xml
0x0067 0x24 HM-LC-Dim1PWM-CV 1 channel dimmer PWM (ceiling voids) rf_dim_1pwm_644_le_v2_4.xml
0x0068 0x25 HM-LC-Dim1TPBU-FM 1 channel dimmer TPBU (flush mount) rf_dim_1tconf_644.xml
0x00b6 0x25 HM-LC-Dim1TPBU-FM-2 1 channel dimmer TPBU (flush mount) rf_dim_1tconf_644.xml
0x0068 0x24 HM-LC-Dim1TPBU-FM 1 channel dimmer TPBU (flush mount) rf_dim_1tconf_644_le_v2_4.xml
0x008a 0x24 263 133 1 channel dimmer TPBU (flush mount) Schueco rf_dim_1tconf_644_le_v2_4.xml
0x0071 0x25 HM-LC-Dim1T-Pl-644 1 channel dimmer T (plug) rf_dim_1t_644.xml
0x0072 0x25 HM-LC-Dim1T-CV-644 1 channel dimmer T (ceiling voids) rf_dim_1t_644.xml
0x0073 0x25 HM-LC-Dim1T-FM-644 1 channel dimmer T (flush mount) rf_dim_1t_644.xml
0x00b4 0x25 HM-LC-Dim1T-Pl-3 1 channel dimmer T (plug) rf_dim_1t_644.xml
0x00b9 0x25 HM-LC-Dim1T-CV-2 1 channel dimmer T (ceiling voids) rf_dim_1t_644.xml
0x00ba 0x25 HM-LC-Dim1T-FM-2 1 channel dimmer T (flush mount) rf_dim_1t_644.xml
0x0071 0x24 HM-LC-Dim1T-Pl-644 1 channel dimmer T (plug) rf_dim_1t_644_le_v2_4.xml
0x0072 0x24 HM-LC-Dim1T-CV-644 1 channel dimmer T (ceiling voids) rf_dim_1t_644_le_v2_4.xml
0x0073 0x24 HM-LC-Dim1T-FM-644 1 channel dimmer T (flush mount) rf_dim_1t_644_le_v2_4.xml
0x0070 0x25 HM-LC-Dim2L-SM-644 2 channel dimmer L (surface mount) rf_dim_2l_644.xml
0x00b8 0x25 HM-LC-Dim2L-SM-2 2 channel dimmer L (surface mount) rf_dim_2l_644.xml
0x0070 0x24 HM-LC-Dim2L-SM-644 2 channel dimmer L (surface mount) rf_dim_2l_644_le_v2_4.xml
0x0074 0x25 HM-LC-Dim2T-SM-644 2 channel dimmer T (surface mount) rf_dim_2t_644.xml
0x00bb 0x25 HM-LC-Dim2T-SM-2 2 channel dimmer T (surface mount) rf_dim_2t_644.xml
0x0074 0x24 HM-LC-Dim2T-SM-644 2 channel dimmer T (surface mount) rf_dim_2t_644_le_v2_4.xml
0x0057 0x20 HM-LC-Dim1T-Pl 1 channel dimmer T (plug) rf_dim_t.xml
0x00a4 0x20 HM-LC-Dim1T-Pl-2 1 channel dimmer T (plug) rf_dim_t.xml
0x0058 0x20 HM-LC-Dim1T-CV 1 channel dimmer T (ceiling voids) rf_dim_t.xml
0x0089 0x20 263 134 1 channel dimmer T (ceiling voids) Schueco rf_dim_t.xml
0x005a 0x20 HM-LC-Dim2T-SM 2 channel dimmer T (surface mount) rf_dim_t.xml
0x0059 0x20 HM-LC-Dim1T-FM 1 channel dimmer T (flush mount) rf_dim_t.xml
0x0057 0x19 HM-LC-Dim1T-Pl 1 channel dimmer T (plug) rf_dim_t_le_v1_9.xml
0x0058 0x19 HM-LC-Dim1T-CV 1 channel dimmer T (ceiling voids) rf_dim_t_le_v1_9.xml
0x005a 0x19 HM-LC-Dim2T-SM 2 channel dimmer T (surface mount) rf_dim_t_le_v1_9.xml
0x0059 0x19 HM-LC-Dim1T-FM 1 channel dimmer T (flush mount) rf_dim_t_le_v1_9.xml
0x0013 0x17 HM-LC-Dim1L-Pl 1 channel dimmer L (plug) rf_d_le_v1_7.xml
0x0012 0x17 HM-LC-Dim1L-CV 1 channel dimmer L (ceiling voids) rf_d_le_v1_7.xml
0x0016 0x17 HM-LC-Dim2L-CV 2 channel dimmer L (ceiling voids) rf_d_le_v1_7.xml
0x002e 0x17 HM-LC-Dim2L-SM 2 channel dimmer L (surface mount) rf_d_le_v1_7.xml
0x0013 0x19 HM-LC-Dim1L-Pl 1 channel dimmer L (plug) rf_d_le_v1_9.xml
0x0012 0x19 HM-LC-Dim1L-CV 1 channel dimmer L (ceiling voids) rf_d_le_v1_9.xml
0x0016 0x19 HM-LC-Dim2L-CV 2 channel dimmer L (ceiling voids) rf_d_le_v1_9.xml
0x002e 0x19 HM-LC-Dim2L-SM 2 channel dimmer L (surface mount) rf_d_le_v1_9.xml
0x00ac 0x00 HM-ES-PMSw1-Pl power meter switch actuator 1-channel rf_es_pmsw.xml
0x0078 0x10 HM-Dis-TD-T radio-controlled flip sign rf_fs_ba.xml
0x0019 0x00 HM-Sec-Key KeyMatic white rf_keymatic.xml
0x0026 0x00 HM-Sec-Key-S KeyMatic silver rf_keymatic.xml
0x0027 0x00 HM-Sec-Key-O KeyMatic bronze rf_keymatic.xml
0x0007 0x00 KS550 KS550 rf_ks550.xml
0x001f 0x00 KS888 KS888 rf_ks550.xml
0x002c 0x00 KS550Tech KS550Tech rf_ks550.xml
0x0033 0x00 KS550LC KS550LC rf_ks550.xml
0x0040 0x00 HM-WDS100-C6-O HM-WDS100-C6-O rf_ks550.xml
0x006d 0x11 HM-OU-LED16 HM output unit LED16 rf_ou_led16_ge_v1_1.xml
0x006d 0x10 HM-OU-LED16 HM output unit LED16 rf_ou_led16_le_v1_0.xml
0x0034 0x00 HM-PBI-4-FM HM Push Button Interface rf_pbi.xml
0x007f 0x00 ZEL STG RM FST UP4 HM Push Button Interface Roto rf_pbi.xml
0x008f 0x00 263 145 HM Push Button Interface Schueco rf_pbi.xml
0x00a0 0x00 HM-RC-4-2 HM Remote 4-2 rf_rc-4-2.xml
0x00a9 0x00 HM-PB-6-WM55 HM Push Button 6 rf_rc-4-2.xml
0x00a6 0x00 HM-RC-Key4-2 HM Remote KeyMatic 4-2 rf_rc-key4-2.xml
0x00a5 0x00 HM-RC-Sec4-2 HM Remote Security 4-2 rf_rc-sec4-2.xml
0x0008 0x00 HM-RC-4 HM Remote 4 buttons rf_rc.xml
0x003b 0x00 HM-RC-4-B HM Remote 4 buttons (black) rf_rc.xml
0x001a 0x00 HM-RC-P1 HM Remote 1 button rf_rc.xml
0x001b 0x00 HM-RC-Sec3 HM Remote 3 buttons (Sec) rf_rc.xml
0x001c 0x00 HM-RC-Sec3-B HM Remote 3 buttons (Sec black) rf_rc.xml
0x001d 0x00 HM-RC-Key3 HM Remote 3 buttons (Key) rf_rc.xml
0x001e 0x00 HM-RC-Key3-B HM Remote 3 buttons (Key black) rf_rc.xml
0x0035 0x00 HM-PB-4-WM HM Push Button 4 rf_rc.xml
0x0036 0x00 HM-PB-2-WM HM Push Button 2 rf_rc.xml
0x0054 0x00 RC-H DORMA Remote 4 buttons rf_rc.xml
0x0064 0x00 atent DORMA Remote 3 buttons rf_rc.xml
0x0080 0x00 ZEL STG RM HS 4 HM Remote 4 buttons Roto rf_rc.xml
0x0029 0x00 HM-RC-12 HM Remote 12 buttons rf_rc_12.xml
0x002a 0x00 HM-RC-12-B HM Remote 12 buttons (black) rf_rc_12.xml
0x004c 0x00 HM-RC-12-SW HM Remote 12 buttons (softtouch white) rf_rc_12.xml
0x0037 0x00 HM-RC-19 HM Remote 19 buttons rf_rc_19.xml
0x0038 0x00 HM-RC-19-B HM Remote 19 buttons (black) rf_rc_19.xml
0x004d 0x00 HM-RC-19-SW HM Remote 19 buttons (softtouch white) rf_rc_19.xml
0x0065 0x00 BRC-H Dorma Remote 4 single buttons rf_rc_single_on.xml
0x006b 0x00 HM-PB-2-WM55 HM Push Button 2 rf_rc_wakeup.xml
0x007d 0x00 ZEL STG RM WT 2 HM Push Button 2 Roto rf_rc_wakeup.xml
0x008d 0x00 263 135 HM Push Button 2 Schueco rf_rc_wakeup.xml
0x00a7 0x14 HM-Sen-RD-O HomeMatic Rain detector rf_rd.xml
0x00a7 0x13 HM-Sen-RD-O HomeMatic Rain detector rf_rd_le_v1_3.xml
0x0076 0x10 HM-Sys-sRP-Pl selective repeater rf_rep.xml
0x009b 0x00 263_149_/_263_150 WCS-TipTronic-Modul Schueco rf_resc_win_pcb_sc.xml
0x0030 0x18 HM-Sec-RHS HM Rotary Handle Sensor rf_rhs.xml
0x0081 0x18 ZEL STG RM FDK HM Rotary Handle Sensor Roto rf_rhs.xml
0x0030 0x17 HM-Sec-RHS HM Rotary Handle Sensor rf_rhs_e_v1_7.xml
0x0030 0x16 HM-Sec-RHS HM Rotary Handle Sensor rf_rhs_le_v1_6.xml
0x0096 0x00 WDF solar ROTO WDF solar rf_roto_wdf_solar.xml
0x0011 0x16 HM-LC-Sw1-Pl radio-controlled socket adapter switch actuator 1-channel rf_s.xml
0x00a1 0x16 HM-LC-Sw1-Pl-2 radio-controlled socket adapter switch actuator 1-channel rf_s.xml
0x0002 0x16 HM-LC-Sw1-SM radio-controlled switch actuator 1-channel (surface-mount) rf_s.xml
0x000a 0x16 HM-LC-Sw2-SM radio-controlled switch actuator 2-channel (surface-mount) rf_s.xml
0x0003 0x16 HM-LC-Sw4-SM radio-controlled switch actuator 4-channel (surface-mount) rf_s.xml
0x002d 0x16 HM-LC-Sw4-PCB radio-controlled switch actuator 4-channel (PCB) rf_s.xml
0x0066 0x16 HM-LC-Sw4-WM radio-controlled switch actuator 4-channel (wall-mount) rf_s.xml
0x0004 0x16 HM-LC-Sw1-FM radio-controlled switch actuator 1-channel (flush-mount) rf_s.xml
0x008b 0x16 263 130 radio-controlled switch actuator 1-channel (flush-mount) Schueco rf_s.xml
0x0009 0x16 HM-LC-Sw2-FM radio-controlled switch actuator 2-channel (flush-mount) rf_s.xml
0x0051 0x16 HM-LC-Sw1-PB-FM radio-controlled switch actuator 1-channel (flush-mount) rf_s.xml
0x0052 0x16 HM-LC-Sw2-PB-FM radio-controlled switch actuator 2-channel (flush-mount) rf_s.xml
0x0061 0x16 HM-LC-Sw4-DR radio-controlled switch actuator 4-channel (DIN rails) rf_s.xml
0x0062 0x16 HM-LC-Sw2-DR radio-controlled switch actuator 2-channel (DIN rails) rf_s.xml
0x007c 0x16 ZEL STG RM FZS radio-controlled socket adapter switch actuator 1-channel Roto rf_s.xml
0x00a2 0x16 ZEL STG RM FZS-2 radio-controlled socket adapter switch actuator 1-channel Roto rf_s.xml
0x000f 0x00 S550IA S550IA rf_s550ia.xml
0x003e 0x00 HM-WDS30-T-O HM-WDS30-T-O rf_s550ia.xml
0x002f 0x18 HM-Sec-SC HM Shutter Contact rf_sc.xml
0x0082 0x18 ZEL STG RM FFK HM Shutter Contact Roto rf_sc.xml
0x00b1 0x22 HM-Sec-SC-2 HM Shutter Contact rf_sc.xml
0x0056 0x10 HM-CC-SCD HM SENSOR_FOR_CARBON_DIOXIDE rf_scd_v1_0.xml
0x0084 0x10 263 160 HM SENSOR_FOR_CARBON_DIOXIDE Schueco rf_scd_v1_0.xml
0x005f 0x01 HM-SCI-3-FM HM Shutter Contact Interface rf_sci_3.xml
0x002f 0x17 HM-Sec-SC HM Shutter Contact rf_sc_e_v1_7.xml
0x002f 0x16 HM-Sec-SC HM Shutter Contact rf_sc_le_v1_6.xml
0x004a 0x16 HM-Sec-MDIR HM radio-controlled motion detector rf_sec_mdir.xml
0x0090 0x16 263 162 HM radio-controlled motion detector Schueco rf_sec_mdir.xml
0x004a 0x15 HM-Sec-MDIR HM radio-controlled motion detector rf_sec_mdir_v1_5.xml
0x0090 0x15 263 162 HM radio-controlled motion detector Schueco rf_sec_mdir_v1_5.xml
0x0042 0x00 HM-Sec-SD HM Smoke Detector rf_sec_sd.xml
0x0091 0x00 263 167 HM Smoke Detector Schueco rf_sec_sd_schueco.xml
0x0050 0x01 HM-Sec-SFA-SM radio-controlled siren flash actuator (surface-mount) rf_sec_sfa.xml
0x0044 0x00 HM-Sen-EP HM Sensor for Electronic Pulses rf_sen_ep.xml
0x004f 0x16 HM-Sen-MDIR-SM HM radio-controlled motion detector surface-mount rf_sen_mdir.xml
0x005d 0x16 HM-Sen-MDIR-O HM radio-controlled motion detector outdoor rf_sen_mdir.xml
0x004f 0x15 HM-Sen-MDIR-SM HM radio-controlled motion detector surface-mount rf_sen_mdir_v1_5.xml
0x005d 0x15 HM-Sen-MDIR-O HM radio-controlled motion detector outdoor rf_sen_mdir_v1_5.xml
0x009f 0x10 HM-Sen-Wa-Od HomeMatic capacitive filling level sensor rf_sen_wa_od.xml
0x0046 0x00 HM-SwI-3-FM HM Switch Interface 3 switches rf_swi.xml
0x0083 0x00 ZEL STG RM FSS UP3 HM Switch Interface 3 switches Roto rf_swi.xml
0x0092 0x00 263 144 HM Switch Interface 3 switches Schueco rf_swi.xml
0x0069 0x22 HM-LC-Sw1PBU-FM radio-controlled switch actuator 1-channel (flush-mount) rf_s_1conf_644.xml
0x008c 0x22 263 131 radio-controlled switch actuator 1-channel (flush-mount) Schueco rf_s_1conf_644.xml
0x0069 0x20 HM-LC-Sw1PBU-FM radio-controlled switch actuator 1-channel (flush-mount) rf_s_1conf_644_le_v2_1.xml
0x008c 0x20 263 131 radio-controlled switch actuator 1-channel (flush-mount) Schueco rf_s_1conf_644_le_v2_1.xml
0x00ab 0x10 HM-LC-Sw4-Ba-PCB radio-controlled switch actuator 4-channel PCB rf_s_4_ba.xml
0x006c 0x10 HM-LC-Sw1-Ba-PCB radio-controlled switch actuator 1-channel PCB rf_s_ba.xml
0x0011 0x15 HM-LC-Sw1-Pl radio-controlled socket adapter switch actuator 1-channel rf_s_le_v1_5.xml
0x0002 0x15 HM-LC-Sw1-SM radio-controlled switch actuator 1-channel (surface-mount) rf_s_le_v1_5.xml
0x000a 0x15 HM-LC-Sw2-SM radio-controlled switch actuator 2-channel (surface-mount) rf_s_le_v1_5.xml
0x0003 0x15 HM-LC-Sw4-SM radio-controlled switch actuator 4-channel (surface-mount) rf_s_le_v1_5.xml
0x002d 0x15 HM-LC-Sw4-PCB radio-controlled switch actuator 4-channel (PCB) rf_s_le_v1_5.xml
0x0004 0x15 HM-LC-Sw1-FM radio-controlled switch actuator 1-channel (flush-mount) rf_s_le_v1_5.xml
0x0009 0x15 HM-LC-Sw2-FM radio-controlled switch actuator 2-channel (flush-mount) rf_s_le_v1_5.xml
0x0001 0x00 HM-LC-Sw1-Pl-OM54 1 channel switch (plug OM54) rf_s_mega168.xml
0x0014 0x00 HM-LC-Sw1-SM-ATmega168 1 channel switch (surface mounted) rf_s_mega168.xml
0x0015 0x00 HM-LC-Sw4-SM-ATmega168 4 channel switch (surface mounted) rf_s_mega168.xml
0x00ad 0x00 HM-TC-IT-WM-W-EU ThermalControl-IndoorTemperatureSensor rf_tc_it_wm-w-eu.xml
0x0043 0x11 HM-Sec-TiS HM Tilt Sensor rf_tis.xml
0x0043 0x10 HM-Sec-TiS HM Tilt Sensor rf_tis_le_v1_0.xml
0x00a8 0x00 HM-WDS30-OT2-SM HM-WDS30-OT2-SM rf_wds30_ot2.xml
0x00bc 0x00 HM-WDS40-TH-I-2 HM-WDS40-TH-I-2 rf_wds40_th_i_2.xml
0x0045 0x10 HM-Sec-WDS HM Waterdetectionsensor rf_wds_v1_0.xml
0x0045 0x11 HM-Sec-WDS HM Waterdetectionsensor rf_wds_v1_1.xml
0x00b2 0x13 HM-Sec-WDS-2 HM Waterdetectionsensor rf_wds_v1_1.xml
0x0028 0x00 HM-Sec-Win WinMatic white rf_winmatic.xml
0x000b 0x00 WS550 WS550 rf_ws550.xml
0x0022 0x00 WS888 WS888 rf_ws550.xml
0x002b 0x00 WS550Tech WS550Tech rf_ws550.xml
0x0031 0x00 WS550LCB WS550LCB rf_ws550.xml
0x0032 0x00 WS550LCW WS550LCW rf_ws550.xml
0x0041 0x00 HM-WDC7000 HM-WDC7000 rf_ws550.xml
Sub Type describes the purpose of the device, therefore it gets checked while peering with other devices:
## -- Sub Type ID information -------------------------------------------------------------------------------
## "0x01" => "AlarmControl" "0x41" => "sensor" "0x70" => "THSensor"
## "0x10" => "switch" "0x42" => "swi" "0x80" => "threeStateSensor"
## "0x12" => "outputUnit" "0x43" => "pushButton" "0x81" => "motionDetector"
## "0x20" => "dimmer" "0x44" => "singleButton" "0xC0" => "keyMatic"
## "0x30" => "blindActuator" "0x51" => "powerMeter" "0xC1" => "winMatic"
## "0x39" => "ClimateControl" "0x58" => "thermostat" "0xC3" => "tipTronic"
## "0x40" => "remote" "0x60" => "KFM100" "0xCD" => "smokeDetector"
Device Info - i have no idea. I guess, the first parameter indicates the possible amount of peers, the second parameter indicates on some devices the amount of channels.
Bezüglich deiner zweiten frage:
First 15 bytes of eeprom used by some mandatory device specific information
//- eeprom defaults table ------------------------------------------------------------------------------------------------
uint16_t EEMEM eMagicByte;
uint8_t EEMEM eHMID[3] = {0x01,0x02,0x05};
uint8_t EEMEM eHMSR[10] = {'t','l','u','1','0','0','1','2','3','5'};
eMagicByte - it is a 2 byte magic number to recognize a configuration change of the HW. On startup or reset the asksin framework calculates a 16bit crc number of the channel definition table and compares the crc agains the magic byte in eeprom. If it is different, a first time start is indicated, eeprom gets prepared and firstTimeStart function executed.
If magic is equal to crc, only everyTimeStart will be executed.
Hallo zusammen,
ich bin frisch in ein neues Projekt eingestiegen und benötige zur Einarbeitung erstmal ein funktionierendes Beispiel.
Ich durchsuche zur Zeit sämtliche Quellen die ich finden kann um erstmal meinen arduino mini pro zu füttern.
Soweit ich diesen Thread folgen konnte, ist das Wiki nicht mehr aktuell (sketch_aug05a.ino ist der Userbereich).
Derzeit habe ich die newasksin getestet, bekomme aber noch fatale errors.
Kann mir jemand einen Hinweis geben, wie aktuell vorgegangen werden muss um zunächst z.B. die LedSampleRelay ans laufen zu bekommen?
Ein paar Seiten vorraus gabs den Tipp die librarie von AskSin-master in AskSinmaster umzubenennen, das hatte bei mir leider noch keinen Erfolg.
Arduino: 1.6.5 (Windows 7), Platine: "Arduino Duemilanove or Diecimila, ATmega328"
In file included from C:\Users\ckay\Documents\Arduino\libraries\AskSin-master/AskSinMain.h:31:0,
from Register.h:1,
from LedLampeRelay.ino:4:
C:\Users\ckay\Documents\Arduino\libraries\AskSin-master/utility/StatusLed.h:18:20: fatal error: Serial.h: No such file or directory
#include <Serial.h>
^
compilation terminated.
Fehler beim Kompilieren.
Dieser Report hätte mehr Informationen mit
"Ausführliche Ausgabe während der Kompilierung"
aktiviert in Datei > Einstellungen
Darauf hin habe ich die Serial.h mal von "/libraries/AskSin-master/utility" nach "/libraries/AskSin-master" verschoben was mir den nächsten Fehler brachte. (es fehlte die wire.h die ich jedoch nirgends finden konnte.
Ein kleiner schups (Link) in die richtige Richtung würde mir schon sehr helfen.
MfG
Ckay
Entferne testweise "-master" aus dem Ordnernamen vollständig
Wähle das richtige Board
Hallo wirfman,
die Antwort kam schnell.
Das Entfernen des "-master" hat keine Änderung gebracht. (ide neu gestartet)
Probeweise habe ich das Board auch mal auf mini pro und mini gestellt, brachte aber keine Änderung.
Die Fehler habe ich wohlgemerkt auch ohne den Arduino angeklemmt zu haben (nur kompilieren).
Mit der Einstellung"Arduino Duemilanove or Diecimila" habe ich andere sketche auf dem Arduino ans laufen gebracht. (display ansteuern, buttons... kein Problem)
Vorgehensweise war: zip-downloaden, include librarie from zip, ordnername manuel bearbeiten, beispiel laden und kompilieren.
danke schonmal und gute Nacht... (für heute ;-) )
Gruß
Ckay
die newasksin muss in den user library ordner, das master muss aus dem ordnernamen raus, da die arduino gui mit dem bindestrich nicht umgehen kann.
als hardware musst du den avr 328 mit 8mhz und 3.3 volt wählen, duemilanove, etc wird nicht unterstützt.
viele grüße
horst
Hallo trilu
Ich nutze einen Panstamp und die IDE bemängelt beim Kompilieren folgendes:
fatal error: avr/sleep.h: No such file or directory
Dies wird in der HAL.h verwendet.
Welches AVR-Paket hast du zusätzlich installiert ?
Gruss Peter
ich habe bisher auch diverse Varianten (auch die unlogischen) versucht.
Ich habe auch schon überlegt ob es an dem Clon liegt, aber da ich den Fehler bereits krige bevor ich die Hardware anschließe kann ich das ja ausschließen.
Muss - für die Beispiele - noch irgendeine Datei vorher bearbeitet oder erzeugt werden?
Ich bin arduino Frischling. Bisher habe ich nur die Adafruit_GFX; Adafruit_PCD8544 und die pcd8544-1.4.3 libraries hinzugefügt. (testweise rausgelöscht... keine Änderung)
Neuinstallation hat auch nichts gebracht.
Wenn der meckert dass er die Serial.h nicht findet... wo müsste die hin?
Man was bin ich gespannt wo ich den Fehler finde....
es sind keine weiteren pakete notwendig - welche arduino version nutzt ihr und welchen zweig der library habt ihr gedownloaded?
Hallo trilu
Ich nutze die Arduino IDE 1.6.5 und habe den Zweig unter https://github.com/trilu2000/NewAskSin downgeloaded.
Gruss Peter
sehr seltsam - avr/sleep.h ist eine headerdatei des GCC, sollte folglich vorhanden sein in der Arduino IDE
bei mir liegt sie in
C:\Program Files\arduino-1.5.8\hardware\tools\avr\avr\include\avr
sollte aber auch bei neueren versionen dort liegen...
Hallo zusammen,
bin leider gerade erst auf diesen Thread gestoßen. Gibt es vielleicht irgendwo im wiki eine Aufbauanleitung? Oder sollte ich doch lieber alle 60 Seiten von diesem Thread lesen?
Danke schonmal!
Luus
Hallo trilu
Die Dateien sind auch in der neuesten IDE im Hardware-Ordner vorhanden, werden aber beim Kompilieren trotzdem nicht gefunden.
Probiere mal noch ein paar Sachen :-)
Gruss Peter
Hallo luus.
Eigentlich sollte es reiche die Bibliothek im wiki zu nehmen und das -master aus dem Namen zu löschen. Steht in den letzten 5 beiträgen. Wäre gut zu wissen wie es bei dir läuft, da es offenbar irgendwo ein Problem gibt...
Gesendet von meinem GT-I9505 mit Tapatalk
Hallo,
erstmal danke für die Antwort. Allerdings bin ich bereits bei der verwendeten Hardware hängen geblieben. Da ich beruflich Programmierer bin, habe ich leider von der Hardware wenig Ahnung. Wäre schön, wenn mir diesbezüglich jemand behilflich sein könnte, gerne auch inklusive Aufbau.
Danach kann ich natürlich gerne berichten, wie ich mit der Software zurecht komme! :)
Danke
Luus
Edit: Okay, ich nehme wohl einfach den Aufbau aus dem Wiki... sorry :D
Bei mir ist´s übrigens auch die 1.6.5 und der selbe download.
Wie ist beim debuggen eigentlich vorzugehen. Mir ist noch nicht klar wie ich rausbekomme wo er die dateien sucht.
muss die serial.h auch nach C:\Program Files\arduino\hardware\tools\avr\avr\include\avr oder ist das ein spezieller fall mit dem Panstamp?
Ich glaube ich habe was grundlegendes falsch gemacht. Ich habe jetzt mal testweise eine datei nach der anderen in den o.g. ordner geschoben.
serial.h (aus asksin-lib)
battery.h (aus asksin-lib)
wire.h (C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire)
und bei der memory.h bin ich dann mangels datei nicht weiter gekommen.
Wenn eine Datei nach der anderen fehlt, spricht das zwar dafür das ich die an die richtige Stelle gepackt habe, aber auch, das mir ein ganzes Paket(librariy) fehlt.
Leider Gottes bin ich kein Beruflicher Programmierer. Eher ein Hobby-durchwurschtler... ;-)
@Luus. Hast du auch ohne Hardware mal versucht den Sketch zu kompilieren?
Hallo zusammen,
Habe nun die ganzen Sachen mal heruntergeladen und versucht zu kompilieren. Habe dazu den "AskinNew_test"-Sketch geöffnet und versucht zu kompilieren. Funktionierte natürlich nicht, also die ganzen Header- und Source-Dateien in den Arduino Ordner kopiert. Die IDE meckerte dann, dass die Funktionen firstTimeStart und everyTimeStart nicht gefunden werden. In den anderen Projekten sind diese in den register.h-Header-Dateien. Also rauskopiert und in die register.h von dem Projekt eingefügt. Danach konnte ich den Sketch kompilieren. Getestet auf einem Arduino hab ich das ganze leider noch nicht.
Hoffe ich konnte schon dem ein oder anderen hier weiter helfen.
Lutz
Hallo lutz,
... also die ganzen Header- und Source-Dateien in den Arduino Ordner kopiert.....
Kannst du das für weniger begabte ein bischen genauer ausführen?
Hast du einfach die header dateien aus der librarie in das user Projekt geschoben ?
Gruß ckay
Gesendet von meinem GT-I9505 mit Tapatalk
Hallo zusammen,
Bei mir ist die Arduino IDE installiert unter
C:\Program Files (x86)\Arduino
In diesem Ordner gibt es einen Ordner mit dem Namen "libraries". In diesem haben ich einen neuen Ordner "NewAskSin" erstellt. In diesen habe ich die Header- und Source-Dateien kopiert.
Lutz
Danke luus.
Ich habe alles erstmal bereinigt und neu runtergeladen. Die Änderungen wie von dir beschrieben durchgeführt. Hat funktioniert.
Wenn mein neuer usb-seriel adapter kommt werde ichs testen.
Danke schonmal.
Gesendet von meinem GT-I9505 mit Tapatalk
Nach einen Sonntag ohne Erfolg, komme ich offensichtlich ohne Hilfe auch nicht weiter:
Aktuelle NewAskSin von Github zur Arduino IDE (1.64) hinzugefügt
Beispiel HM_LC_SW1_BA_PCB geladen und erfolgreich kompiliert
Sketch auf einen Arduino Nano geladen an dem ein CC1101-868 Mhz (wie beim NanoCul) angeschlossen ist
Ausserdem noch eine grüne und eine rote Led an Pin 4
Dazu habe ich einen Taster an Pin 8, der default HIGH angeschlossen ist und bem Betätigen auf Low
==> Ist das so richtig, ich habe dazu irgendwie keine Infos gefunden?
An FHEM betreibe ich ein HMLAN.
Beim Pairen mit dem HMLAN wird ein Device angelegt (2 mal mehr als 3 sekunden auf die Taste), allerdings ist das beste was ich erreichen kann ein
State: RESPONSE TIMEOUT:RegisterRead
Sobald ich versuche ein getConfig oder unpair auszuführen geht fast sofort der HMlan in den overload (1%-Regel)
Ich kann zwar mit dem Taster schalten, aber ist der HM_LC_SW1_BA_PCB offensichtlich selebr nicht der Ansicht er sei gepaired und sendet alle Komandos (toggle) als broadcast.
Also Softwareseitig (Arduino) scheint es soweit ok zu sein, aber trotzdem ist irgendwo etwas falsch...
Hilfe ist sehr willkommen,
Johannes
Und noch eine Anschlussfrage, je mehr ich mir die hardware.h des HM_LC_SW1_BA_PCB-Beispiels in der NewAskSin-Lib anschaue, desto unklarer wird es:
- sowohl CC_CS_PIN als auch CC_GDO0_PIN sind als PORTB2 definiert. Ich vermute es sollte wohl PORTD2 heistten, das ist zwar unkritisch, weil die Definition auf denselben Wert lautet, war aber verwirrend
- In den Beschriebungen finde ich keinen Pin für GD02, allerdings macht zumindest das CC1101-Modul Gebrauch von Daten dieses Pins?
Alles in allem würde mir eine kurze Zusammenfassung wie ein CC1101-Modul mit einem Arduino Nano / AVR328p zu verdrahten wäre. Die Bescheibung im Wiki bezieht sich wohl nur auf die alte asksin?
Ich bin auch gerne bereit im wiki mal ein wenig Text dazu zu verfassen, aber dazu müsste ich wissen wie es gedacht ist :D
Guten abend.
Da die Fehlerquellen bei diesem Projekt schier unendlich sind und ich mir heute nach Anschluss des TRX868 aus einem 4fach aktor beinahe auch meinen neuen usb seriell adapter gegrillt habe, würde ich gerne wissen ob mein vorhaben auch erfolgversprechend ist.
Ich möchte 6 taster und ein display anschließen. Nach tastendruck soll von fhem ein text als string versendet werden der dann auf dem display erscheint.
Ist das grundsätzlich machbar oder ist das hier der falsche ansatz?
Gesendet von meinem GT-I9505 mit Tapatalk
Hallo,
ich habe mir bei ELV das Modul HF-Sendemodul TX868-75, 868 MHz (68-06 20 11) bestellt und gehofft, dass ich es an den Arduino anschliessen kann. Leider hat das Modul nur einen Data Eingang.
http://files.elv.de/service/manuals/TX868_75/TX868_75_UM_G_080519.pdf
Gibt es eine Möglichkeit auch dieses Modul zu benutzen?
Gruss Thomas
Hi Thomas,
das war leider ein Fehlkauf.
Mit diesem Modul kann man erstens nur Senden und zweitens unterstützt das nicht die Modulationsart welche bei Homematic eingesetzt wird.
Mit diesem Modul könntest du aber FS20 Daten senden.
Viele Grüße
Dirk
Hallo Zusammen,
zuerst einmal großen respekt und dank an die entwickler die das hier auf die reihe gestellt haben.
ich verfolge dieses projekt hier schon eine ganze weile. habe mir die letzten tage hier die letzten 25 seiten durchgelesen. ich denke alles was mit der neuen bibliothek zu hat.
aber irgendwie bekomme ich gar nichts zum laufen. vielleicht könnte mir jemand einen kleinen schubs geben wo es hacken könnte.
ich verwende einen arduino nano (china model) und einen rf1100se auch aus china.
den anschluss hatte ich zuerst wie beim nano-cul. nachdem keine verbindung zu stande kam habe ich GDO0 von PD3 auf PD2 gelegt und GDO2 weggelassen. PB0 gegen Ground habe ich als Config Taster verstanden. Doch es geht einfach gar nichts.
Wenn ich in der c1101.h den debug modus mittels #define CC_DBG aktiviere, zählt die ausgabe 12 und dann kommt nur noch .......
also hängt er in folgender schleife
ich habe auch schon ein zweites modul ausprobiert, daran scheint es nicht zu liegen, eine andere pinbelegung habe ich auch nirgends gefunden.
sehe ich das richtig das wohl das funkmodul nicht antwortet, quasi irgendwas an der spi kommunikation nicht passt?
Stop, hab den Fehler gefunden. Das Problem war vor dem PC :) Ich hatte 2 Leitungen verdreht. Tut mir Leid. Jetzt klappt es Prima!
VG
Markus
Naja, ich War wohl zu voreilig mit der Aussage das es nun prima läuft.
Der nano hängt nur nicht mehr. Das ist alles. Im Prinzip bin ich auf dem gleichen stand wie viegener,
nur das bei mir nicht mal das Device in fhem auftaucht, also das pairen nicht funktioniert.
Beim durchlesen der letzten 25 seien hier hatte ich eigentlich das Gefühl das es schon ziemlich gut läuft.
Kann es vielleicht sein das die 16 MHz mit der der nano läuft das problem sind?
Ich denke was von benötigten 8MHz gelesen zu haben.
Wenn ja stellt sich die Frage was man da tun kann, kann man das wo umstellen oder muss man die fuses im nano ändern was dann vermutlich nur mittels ISP geht.
Wäre super wenn mir das jemand bestätigen kann, bevor es eine sackgasse ist und ich zuviel zeit da rein stecke.
Viele Grüße
Markus
Zitat von: ckaytwo am 16 August 2015, 21:25:00
Guten abend.
Da die Fehlerquellen bei diesem Projekt schier unendlich sind und ich mir heute nach Anschluss des TRX868 aus einem 4fach aktor beinahe auch meinen neuen usb seriell adapter gegrillt habe, würde ich gerne wissen ob mein vorhaben auch erfolgversprechend ist.
Ich bin auch gerade dabei die "New Asksin" auszuprobieren. Vermutlich ist dir was ähnliches passiert wie mir:
Als ich das schmale TRX868 Modul aus dem HM 8 Kanal Sendemodul mit dem Arduino 328p, 3,3V verbunden habe ist mir aufgefallen, dass folgende Zeichnung nicht stimmen kann:
http://www.fhemwiki.de/wiki/Datei:2013-11-13_-_Fritzing-Screenshot_-_schmal_-CutUSM_800x601_85P.jpeg
Wenn man von oben auf die Metallabschirmung schaut (Antenne oben) ist PIN 1 (VCC) unten links und NICHT oben links.
Das konnte ich anhand der Bauanleitung für das 8-Kanal Sendemodul soweit entziffern.
Hallo,
vielleicht kann mir jemand auf die Sprünge helfen:
Ich möchte mir mit Hilfe der "New Askin" Library eigene Sensoren bauen (wie z.B. 2x DS18B20 an einem Arduino, bei gewisser Temp-Differenz/Zeiteinheit soll ein Schaltevent ausgelöst werden -> f. Zirkulationspumpensteuerung).
Ich verwende kein FHEM, sondern eine CCU2!
Aktuell habe ich mir zum Testen / Einarbeiten mal die folgende Hardware aufgebaut:
- TRX Modul aus dem Homematic 8-Kanal Sendemodul
- Arduino 328p 8Mhz 3,3V + Ext LDO
- LED an Pin 3 gegen GND
- LED an Pin 4 gegen GND
- Taster an PIn 8 gegen GND (ohne Pullup)
- Das Beispiel "HM_LC_SW1_BA_PCB" mittels Arduino 1.6.4 unverändert aufgespielt
-> Über die serielle Schnittstelle meldet sich der Arduino auch über die Konsole in der Arduino GUI
Nach meiner Vorstellung sollte ich doch nun druch Drücken des Tasters das Gerät in der CCU2 über die ubliche Vorgehensweise anmelden können...
---> Dies habe ich allerdings nicht hinbekommen!?
Läuft die Lib bzw. das o.g. Beispiel evtl. nur mit FHEM oder sollte das auch mit der CCU2 funktionieren?
Jochen
Zitat von: Jochen222 am 25 September 2015, 21:12:03
- TRX Modul aus dem Homematic 8-Kanal Sendemodul
Schau mal auf dem Sendemodul nach, ob es ein TRX868-TFK-TI oder ein TRX868-TFK-SL ist. Es funktioniert nur mit einem TRX868-TFK-TI.
Zitat von: Telekatz am 25 September 2015, 21:48:18
Schau mal auf dem Sendemodul nach, ob es ein TRX868-TFK-TI oder ein TRX868-TFK-SL ist. Es funktioniert nur mit einem TRX868-TFK-TI.
Hallo,
in der Tat, es ist das Modul "TRX868-TFK-SL"! Wie unterscheiden sich die Module denn? Ich dachte es ist nur ein CC1101 Transceiver verbaut...
Jochen
Im TRX868-TFK-SL ist ein Si4431 von Silicon Labs verbaut. Der CC1101 ist im TRX868-TFK-TI verbaut.
Hallo,
mal eine Frage an die Spezialisten. Ich habe auf einen Panstamp ein Beispiel aus den AskSin Sketches aufgespielt. Eigentlich nur so zum testen. Es funktioniert, aber .....
Wenn ich jetzt wieder einen Sketch aus der SWAP Reihe aufspiele, verhält sich der Panstamp nicht mehr richtig. Als Sender kommt an dem anderen Ende (Modem Sketch) nichts an, und mit dem Modem Sketch werden nicht alle Geräte eimpfangen.
Kann es sein, das in der AskSin Bibliothek etwas in den CC1101 Registern verstellt wird, was auch mit SWAP toFactoryDefaults() nicht zurück gesetzt wird ?
Gruß Christoph
Uhi - hier hat sich ja richtig was getan. Irgendwie schaltet sich bei dem Board immer wieder die Benachrichtigung aus...
ZitatEigentlich nur so zum testen. Es funktioniert, aber .....
Wenn ich jetzt wieder einen Sketch aus der SWAP Reihe aufspiele, verhält sich der Panstamp nicht mehr richtig. Als Sender kommt an dem anderen Ende (Modem Sketch) nichts an, und mit dem Modem Sketch werden nicht alle Geräte eimpfangen.
Kann es sein, das in der AskSin Bibliothek etwas in den CC1101 Registern verstellt wird, was auch mit SWAP toFactoryDefaults() nicht zurück gesetzt wird ?
Ich kann mir nur vorstellen das es am EEprom Inhalt liegt. Die Register des CC1101 lassen sich nicht dauerhaft setzen. Die sind auf default, wenn die Stromzufuhr getrennt wurde.
ZitatLäuft die Lib bzw. das o.g. Beispiel evtl. nur mit FHEM oder sollte das auch mit der CCU2 funktionieren?
Bis auf die AES Kommunikation sollte sich die Lib wie das Original verhalten, folglich sollte sich der PCB Sketch auch an der CCU2 anlernen lassen.
ZitatKann es vielleicht sein das die 16 MHz mit der der nano läuft das problem sind?
Die Lib hat zwei Ableitungen von der CPU Frequenz - Timer und SPI. Die musst Du anpassen und dann sollte es auch mit 16 MHz klappen.
Zitat- sowohl CC_CS_PIN als auch CC_GDO0_PIN sind als PORTB2 definiert. Ich vermute es sollte wohl PORTD2 heistten, das ist zwar unkritisch, weil die Definition auf denselben Wert lautet, war aber verwirrend
- In den Beschriebungen finde ich keinen Pin für GD02, allerdings macht zumindest das CC1101-Modul Gebrauch von Daten dieses Pins?
Für die Lib reicht der GDO0 Pin, über GDO2 könnte man weitere Dinge vom CC1101 signalisieren lassen, brauch ich aber nicht :-)
Im Normalfall sollte auch kein User an der hardware.h schrauben müssen. Ziel der Lib ist es, sie einzubinden und sich ausschließlich auf die ino zu konzentrieren...
ZitatIch möchte 6 taster und ein display anschließen. Nach tastendruck soll von fhem ein text als string versendet werden der dann auf dem display erscheint.
Ist das grundsätzlich machbar oder ist das hier der falsche ansatz?
Soll das Display auch Sachen von der Zentrale empfangen? Das mit den Tastern ist machbar, ich muss mich endlich mal an das Key Modul setzen. Es wird ein Beispielsketch für Taster folgen...
ZitatDazu habe ich einen Taster an Pin 8, der default HIGH angeschlossen ist und bem Betätigen auf Low
==> Ist das so richtig, ich habe dazu irgendwie keine Infos gefunden?
An FHEM betreibe ich ein HMLAN.
Beim Pairen mit dem HMLAN wird ein Device angelegt (2 mal mehr als 3 sekunden auf die Taste), allerdings ist das beste was ich erreichen kann ein
State: RESPONSE TIMEOUT:RegisterRead
Sobald ich versuche ein getConfig oder unpair auszuführen geht fast sofort der HMlan in den overload (1%-Regel)
Ich kann zwar mit dem Taster schalten, aber ist der HM_LC_SW1_BA_PCB offensichtlich selebr nicht der Ansicht er sei gepaired und sendet alle Komandos (toggle) als broadcast.
Taster ist low aktiv. Den Port setze ich auf High und mit dem Taster wird er auf Masse gezogen. Poste doch mal ein Log des Pairing Versuch.
Hallo Trilu,
mit dem Panstamp das ist irgendwie sehr komisch. Ich habe auch schon mit Daniel darüber geschrieben, aber auch der weiß keinen Rat.
Also Modem bekommt er nur Daten von einem Gerät, das andere wird nicht empfangen. Als Sender kommen keine Daten am Fhem Modem an, wenn ich aber den HM_LC_SW1_BA_PCB Sketch draufschreibe, sendet und empängt er. Sehr komisch - alles ausprobiert, auch toFactoryDefault ohne Erfolg. Der will anscheinend ein HM-Device werden.
Den Sketch mit dem Taster würde ich gerne flashen, aber leider wird der so wie er jetzt ist sehr komisch in Fhem angelegt. Am Device kann man nichts einstellen und irgendwie wird das als "global" angelegt, so das ich am Device alle möglichen reading anderer Geräte sehe. Dann scheint das Teil keine eigene HM ID zu haben. Von daher bin ich schon sehr auf einen neuen Taster-Sketch gespannt.
Gruß Christoph
Hallo Trilu,
nun habe ich das mit einem pro mini mit 8mhz ausprobiert. leider funktioniert auch hier nichts.
ich habe einen rf1100se , wie auch beim wiki vom nano cul beschrieben wird.
aber nicht die 868er, sondern die 433er Version.
Ich dachte die register der 433er version werden umgeschrieben so dass auf 868 gesendet wird, nur mit weniger leistung/reichweite.
kannst du das bestätigen oder liegt hier das problem?
ich wäre schon mega glücklich wenn ich deine beispiele zum laufen bekommen könnte.
Gruß Markus
Hi Marcus,
die 868er und 433er Version unterscheidet sich lediglich hardwareseitig in der Antennenanpassung.
Daher spielt das hier für die Registersettings keine Rolle.
Viele Grüße
Dirk
Hallo Dirk,
vielen dank für diene Antwort. Das bedeutet es sollte eigentlich funktionieren.
Dann werde ich nochmal alles von neuem aufbauen, vielleicht hat sich irgendwo ein Fehler eingeschlichen...
Ich habe mich mit der Bauteilerstellung von Fritzing noch nicht beschäftigt. Aber falls zufällig jemand von dem RF1100SE ein Bauteil für mich hat, würde ich die Schaltung nach meinem Wissensstand zeichnen, mit euch abstimmen und der Allgemeinheit zur Verfügung stellen.
viele Grüsse
Markus
ich habe eben den pcb sketch noch einmal überarbeitet und getestet - das ding funktioniert...
hardwareseitig ist nicht viel nötig - wenn ihr einen panstamp nutzt, dann muss nur ein taster gegen ground an pin d8.
d1 ist der schaltausgang.
d4 und d6 gegen masse eine zwei farb led als statusanzeige.
wenn ihr keinen panstamp habt, dann braucht ihr ein cc1101 modul.
so ein cc1101 modul hat folgende anschlüsse
VCC -> 3Volt
GND -> Ground
SI -> Slave in - muss also beim AVR an MOSI (master out slave in) PB3
SCLK -> Serial clock - muss beim AVR an PB5
SO -> Slave out - also beim AVR an MISO (master in slave out) PB4
GDO2 -> Digital output, wird bei NewAskSin nicht benötigt
GDO0 -> Digital output, zeigt dem AVR an, das Pakete empfangen wurden - AVR PD2 (int0)
CSN -> Chip select, zum adressieren am SPI Bus - AVR PB2
ich gehe davon aus, dass dieses RF1100SE genau die selben anschlüsse hat :-)
wenn die hardware soweit steht, dann kompiliert ihr den HM_LC_SW1_BA_PCB sketch aus dem ordner examples und ladet ihn auf euren AVR.
danach müsstet ihr in der seriellen console so etwas sehen:
Opening port
Port open
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
wenn das nicht in der console erscheint, ist vermutlich mit der hw was nicht ok, also fehlersuche...
wenn der oben gezeigte text erscheint, ist euer pcb-sketch fertig zum anlernen. ccu oder fhem in den anlernmodus schalten und lange (2 sekunden) auf den taster drücken.
dann erscheint so etwas:
<- 1A 03 A0 00 58 23 FF 63 19 63 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (2502486)
m> 0A 03 80 02 63 19 63 58 23 FF 00 (2502630)
oder so ähnlich - meiner ist ja schon angelernt :-)
<- ist das zeichen das der string von eurer hw gesendet wurde
m> das eure zentrale geantwortet hat...
wenn etwas nicht funktioniert, ist es immer hilfreich hier ein kurzes protokoll der seriellen konsole mit rein zu stellen, dann kann man erkennen ob es an der hw liegt, oder an den einstellungen oder was auch immer
viele grüße
horst
hallo horst,
danke für die erklärung der belegung.
ich war da wohl etwas daneben gelegen. aber so ganz funktioniert es immer noch nicht.
der ausgang lässt sich ein- und ausschalten, wenn ich das richtig interpretiere wird auch an die zentrale gefunkt, aber von dort gibt es keine antwort. im event monitor von fhem kommt auch nichts an. ich weiß nicht ob das immer schon war, aber der hmlan meldet ab und zu loadLvl: low wenn ich den pairing taster für 2 sekunden drücke. ich habe allerdiings auch einen cuno und verwende die vccu.
hier ist das was von der seriellen raus kam. vielleicht kannst du was etwas erkennen?
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
switchRly: 1, 200
<- 0E 01 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (19269)
switchRly: 1, 0
<- 0E 02 80 10 58 23 FF 00 00 00 06 01 00 00 00 (23726)
<- 1A 03 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (43746)
switchRly: 1, 200
<- 0E 04 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (62012)
<- 1A 05 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (65589)
<- 1A 06 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (104892)
switchRly: 1, 0
<- 0E 07 80 10 58 23 FF 00 00 00 06 01 00 00 00 (150258)
<- 1A 08 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (155457)
<- 1A 09 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (182732)
switchRly: 1, 200
<- 0E 0A 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (194489)
viele grüsse
markus
ein und ausschalten funktioniert und es wird auch der status gesendet.
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
switchRly: 1, 200
<- 0E 01 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (19269)
switchRly: 1, 0
zum starten des pairings ist dieser string
<- 1A 03 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (43746)
er wird aber nicht beantwortet...
das kann eigentlich nur zwei gründe haben, dein funkmodul sendet den string nicht oder deine zentrale beantwortet ihn nicht.
dein log ist etwa 3 minuten lang, mich wundert es ein wenig dass ich gar keine HM status meldungen darin sehe. das könnte daran liegen, dass du wenig geräte hast, oder das dein modul nicht empfängt...
such dir mal bitte die datei cc1101.cpp im lib verzeichnis und ändere entferne das auskommentieren bei m #define ganz oben
#define CC_DBG
#include "CC1101.h"
// private: //---------------------------------------------------------------------------------------------------------
CC::CC() {
}
void CC::init(void) { // initialize CC1101
danach speichern, sketch neu kompilieren und auf die hw laden. das uploadfile müsste jetzt etwas größer geworden sein...
cc1101 dient der ansteuerung des funkmoduls, mit dem parameter #define CC_DBG werden zusätzliche ausgaben in der seriellen konsole gemacht.
poste diese mal bitte.
viele grüße
horst
naja wenig geräte habe ich nicht gerade glaube ich. ich habe ein ganzes haus über 3 stockwerke ausgestattet.
ich habe testweiße auch mal die rollos hoch und runter gefahren mit dem ergebniss dass nichts von empfangenen daten zu sehen war.
und ich habe 2 dieser cc1101se module, habe in dem folgenden log zwischen durch auch mal gewechselt...ohne ergebniss.
komisch ist auch das der prozessor öfter mal neu startet. wackelkontakt scheint es keiner zu sein.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
switchRly: 1, 200
<- 0E77
<- 0E 01 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (3982)
<- 1A74
<- 1A 02 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (10700)
switchRly: 1, 0
<- 0E75
<- 0E 03 80 10 58 23 FF 00 00 00 06 01 00 00 00 (54923)
<- 1A72
<- 1A 04 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (67481)
<- 1A73
<- 1A 05 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (95495)
switchRly: 1, 200
<- 0E70
<- 0E 06 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (105436)
<- 1A71
<- 1A 07 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (111642)
<- 1A7E
<- 1A 08 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (140401)
<- 1A7F
<- 1A 09 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (179613)
<- 1A7C
<- 1A 0A 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (188815)
<- 1A7D
<- 1A 0B 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (221099)
<- 1A7A
<- 1A 0C 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (236217)
switchRly: 1, 0
<- 0E7B
<- 0E 0D 80 10 58 23 FF 00 00 00 06 01 00 00 00 (250975)
switchRly: 1, 200
<- 0E78
<- 0E 0E 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (254140)
<- 1A79
<- 1A 0F 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (257770)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
switchRly: 1, 200
<- 0E77
<- 0E 01 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (24166)
switchRly: 1, 0
<- 0E74
<- 0E 02 80 10 58 23 FF 00 00 00 06 01 00 00 00 (29580)
<- 1A75
<- 1A 03 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (33427)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
switchRly: 1, 200
<- 0E77
<- 0E 01 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (9103)
switchRly: 1, 0
<- 0E74
<- 0E 02 80 10 58 23 FF 00 00 00 06 01 00 00 00 (14400)
<- 1A75
<- 1A 03 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (18861)
<- 1A72
<- 1A 04 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (45144)
<- 1A73
<- 1A 05 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (52514)
switchRly: 1, 200
<- 0E70
<- 0E 06 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (61394)
switchRly: 1, 0
<- 0E71
<- 0E 07 80 10 58 23 FF 00 00 00 06 01 00 00 00 (64967)
switchRly: 1, 200
<- 0E7E
<- 0E 08 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (77050)
switchRly: 1, 0
<- 0E7F
<- 0E 09 80 10 58 23 FF 00 00 00 06 01 00 00 00 (79968)
switchRly: 1, 200
<- 0E7C
<- 0E 0A 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (81438)
switchRly: 1, 0
<- 0E7D
<- 0E 0B 80 10 58 23 FF 00 00 00 06 01 00 00 00 (86240)
switchRly: 1, 200
<- 0E7A
<- 0E 0C 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (103907)
<- 1A7B
<- 1A 0D 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (108402)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (10999)
switchRly: 1, 200
<- 0E74
<- 0E 02 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (18126)
<- 1A75
<- 1A 03 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (44033)
<- 1A72
<- 1A 04 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (60914)
switchRly: 1, 0
<- 0E73
<- 0E 05 80 10 58 23 FF 00 00 00 06 01 00 00 00 (64693)
switchRly: 1, 200
<- 0E70
<- 0E 06 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (66532)
switchRly: 1, 0
<- 0E71
<- 0E 07 80 10 58 23 FF 00 00 00 06 01 00 00 00 (68975)
switchRly: 1, 200
<- 0E7E
<- 0E 08 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (72971)
<- 1A7F
<- 1A 09 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (75363)
<- 1A7C
<- 1A 0A 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (84213)
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
kannst du was erkennen?
viele grüsse
markus
hmm, die reboots sind komisch, aber der init string zum cc1101 über SPI scheint zu laufen.
damit müsste miso, mosi, clk, cs richtig angeschlossen sein. wie hast du den gdo0 verdrahtet?
den gdo0 nutze ich zur erkennung von empfangenen paketen - also per interrupt. der gdo0 muss an den PD2 (int0) beim AVR 328
welches funkmodul hast du eigentlich?
den gdo0 habe ich genau so angeschlossen.
die resets würde ich jetzt mal links liegen lassen. ich arbeite mit so einem billig bread board. vielleicht kommt es davon. bis vor ein par tagen war das auch noch nicht und im moment ist es auch wieder verschwunden.
funkmodul habe ich dieses hier:
http://www.ebay.de/itm/CC1101-Wireless-Module-SMA-Antenna-Wireless-Transceiver-Module-for-Arduino-DE-/251539869904?hash=item3a90f1d0d0 (http://www.ebay.de/itm/CC1101-Wireless-Module-SMA-Antenna-Wireless-Transceiver-Module-for-Arduino-DE-/251539869904?hash=item3a90f1d0d0)
für was ist eigentlich die led an d6? die war noch nie an.
Hmm, das Modul ist nicht ideal da falsches Frequenzband, sollte aber funktionieren. Zumindest auf kurze Distanz. Hast Du das Layout für die Anschlüsse? Ich glaube immer noch das es ein Problem mit der GDO0 Verbindung gibt. Löte doch mal die Pins direkt an....
D4 und D6 ist für eine zweifarbige Status Led. Muss später mal nachsehen, ob der Sketch auf 1 oder 2 Farbe konfiguriert ist.
Dass das Modul nicht ganz optimal ist war mir klar, wollte es aber anhand des preises darauf ankommen lassen was reduzierte reichweite genau bedeutet. das layout habe ich von hier genommen:
https://github.com/matthewbednarski/arduino-projects/blob/master/hardware/cc1101-rf1100se.md (https://github.com/matthewbednarski/arduino-projects/blob/master/hardware/cc1101-rf1100se.md)
reicht es wenn ich erstmal den gdo0 löte und den rest so belasse?
das mit den leds brauchst du nicht unbedingt nachzusehen, dachte nur es zu sagen für den fall das es dir weiterhilft.
gebe dann nochmal nach dem löten bescheid....
Was nutzt du auf der Arduino Seite? UNO, Mini pro?
5volt, 3,3 Volt?
ich verwende einen mini pro v2 mit 3,3V. Allerdings kein orginal, der hier müsste es gewesen sein:
http://www.ebay.de/itm/Enhancement-V2-Pro-Mini-8MHz-3-3V-5V-adjustable-MEGA328P-Arduino-Compatible-/221668558468?hash=item339c79c684 (http://www.ebay.de/itm/Enhancement-V2-Pro-Mini-8MHz-3-3V-5V-adjustable-MEGA328P-Arduino-Compatible-/221668558468?hash=item339c79c684)
Die sind prima, die nutze ich auch. Versuch mal löten, dann können wir Wackelverbindungen ausschließen.
Ich habe mir gerade noch mal das Log angeschaut, ich glaube Du hast den GDO0 an PD1 angeschlossen....
also ich habe jetzt die verbindung gdo0 gelötet, aber nur diese, leider ohne veränderung.
pd2 habe ich eigentlich nicht verwechselt, ausser ich sehe da was falsch.
pd2 ist mit 2 auf dem arduino beschriftet und pd1 mit tx und die beiden sind auch nicht direkt nebeneinander.
ich glaube ich habe noch einen arduino, vielleicht sollte ich den mal ausprobieren. aber der rest funktioniert ja auch, also bringt es vermutlich nicht viel.
ich habe hier den bootloader mal neu gebrannt. gibt es hier einstellungen die ich falsch gemacht haben könnte, so dass der interrupt nicht funktioniert?
so jetzt habe ich den anderen arduino ausgegraben und bestückt -> leider unverändert.
den gelöteten gdo0 habe ich ziemlich kurz gehalten, aber könnten 30cm flachbandkabel zwischen arduino und cc1101 zuviel sein?
ich werde morgen das ganze mal direkt zusammen löten und mit möglichst kurzen wegen, wenn das nichts bringt muß es ja wohl das funkmodul sein.
ich habe das jetzt doch noch heute ausprobiert. die verbindungen zum cc1101 sind jetzt alle gelötet und 5cm lang.
leider muss ich mich wiederholen, es funktioniert so auch nicht.
hier ist nochmal das aktuelle log, vielleicht hat sich ja zwischenzeitlich etwas geändert
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
PowerM‹•é 0
initRly: 1
....
CC.
12.................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
switchRly: 1, 200
<- 0E77
<- 0E 01 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (5507)
<- 1A74
<- 1A 02 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (6812)
switchRly: 1, 0
<- 0E75
<- 0E 03 80 10 58 23 FF 00 00 00 06 01 00 00 00 (31520)
switchRly: 1, 200
<- 0E72
<- 0E 04 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (35049)
switchRly: 1, 0
<- 0E73
<- 0E 05 80 10 58 23 FF 00 00 00 06 01 00 00 00 (37644)
<- 1A70
<- 1A 06 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (39617)
switchRly: 1, 200
<- 0E71
<- 0E 07 80 10 58 23 FF 00 00 00 06 01 C8 00 00 (288502)
<- 1A7E
<- 1A 08 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (292702)
<- 1A7F
<- 1A 09 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (308969)
grüsse
markus
so langsam gehen mir die ideen aus. die spi kommunikation zum modul läuft, das sieht man an den punkten...
CC.
12.................3 - ready
die punkte werden in der init vom modul gesetzt, während ich per loop den status vom cc1101 abfrage.
was komisch ist, es wird laut deinen logs nichts empfangen. das kann jetzt an der signalisierung vom cc1101 liegen, oder eben am funkmodul.
die 5cm leitungslänge sind ok...
ich werde am wochenende mal ein wenig testen, vielleicht kann ich ja ein wenig mehr prüfungen einbauen.
ich gehe davon aus, dass du die richtige hardware in der arduino shell gewählt hast - mini pro 8mhz, 3.3v?
hallo horst,
ja die hardware habe ich so gewählt.
naja im schlimmsten fall muss ich mir dann andere funk module besorgen und kann meine 4 in die tonne treten. wenn du möchtest und wenn es dir was bringt und wenn du interesse hast würde ich dir eines davon schenken und per briefpost zukommen lassen. aber nur wenn es nicht nur für mich ist. wenn du z.b. selbst interesse daran hast weil es ziemlich günstig ist oder so.
heute abend werde ich noch einen test machen. vielleicht ist es ja so das nicht nur die hardware der platine auf die 433mhz optimiert ist, sondern auch die antenne. da gibts im netz bestimmt anleitungen wie man aus einem draht eine antenne für 868mhz baut.
was meinst du, ist es einen versuch wert?
grüsse
markus
ich nutze diese funkmodule:
http://de.aliexpress.com/item/25pcs-lot-CC1101-868MHz-wireless-module-1-2k-500-kbps-data-rate-Free-shipping/1104691912.html
an der antenne kanns eigentlich nicht liegen, 434mhz ist die hälfte von 868mhz - die antennen sind normalerweise lambda/4, in deinem fall lambda/8. aber testen kannst du es allemal. löte den sma runter und ein kurzes stück draht ran, ich glaube 8cm oder so...
das angebot, das modul zu schicken ist sehr nett, aber muss nicht sein. 434mhz will ich nicht nutzen, weil ja nicht HM kompatibel :-)
hi horst,
ich hab mir jetzt welche aus der bucht bestellt.
http://www.ebay.de/itm/301728510301?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/301728510301?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
die sehen genauso aus wie deine, nur in einer kleineren menge und zum selben preis.
vielleicht baue ich die 433er module mal um auf 868. machbar müsste es sein. im moment habe ich aber keine lust dazu.
vielen dank auch noch für deine unterstützung!!
viele grüsse
markus
umbauen lohnt sich nicht wirklich, da kosten allein die smd bauteile mehr als das modul :-)
hast du nicht noch einen max-fensterkontakt oder irgend ein anderes hm/max device. die funkmodule gehen auch prima, kannst ja wieder zurück bauen, wenn die aus der bucht da sind ....
stimmt, das habe ich auch gerade rausgefunden. die module habe ich mir mal auf, vielleicht baue ich mir nen cul für intertechno steckdosen...
naja ich hätte noch so einen fenster drehgriff kontakt von hm. vielleicht nehme ich den auseinander wenn ich es nicht mehr abwarten kann ;)
Danke erstmal für die Antworten. Es hat ein bisschen gedauert, bis ich wieder dazugekommen bin Tests zu machen. Die Verkableung ist inzwischen korrekt (GD00 war an Pin3/Int1 und nicht Pin2).
Zitat von: trilu am 29 September 2015, 16:31:04
Die Lib hat zwei Ableitungen von der CPU Frequenz - Timer und SPI. Die musst Du anpassen und dann sollte es auch mit 16 MHz klappen.
Du schreibst, dass es zwei Stellen gibt, wo man das Timing an 16 MhZ anpassen muss, kannst Du da etwas mehr Hinweise geben (geht es um den Prescaler?) Hast Du vielleicht ein angepasstes Beispiel / .h-File?
Zitat von: trilu am 29 September 2015, 16:31:04
Poste doch mal ein Log des Pairing Versuch.
Gerne:
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 60 60 60, MAID: 00 00 00
<- 0E 00 80 10 60 60 60 00 00 00 06 01 00 00 00 (1033)
switchRly: 1, 200
<- 0E 01 80 10 60 60 60 00 00 00 06 01 C8 00 00 (18376)
switchRly: 1, 0
<- 0E 02 80 10 60 60 60 00 00 00 06 01 00 00 00 (19538)
switchRly: 1, 200
<- 0E 03 80 10 60 60 60 00 00 00 06 01 C8 00 00 (30630)
switchRly: 1, 0
<- 0E 04 80 10 60 60 60 00 00 00 06 01 00 00 00 (33844)
switchRly: 1, 200
<- 0E 05 80 10 60 60 60 00 00 00 06 01 C8 00 00 (35796)
switchRly: 1, 0
<- 0E 06 80 10 60 60 60 00 00 00 06 01 00 00 00 (36959)
switchRly: 1, 200
<- 0E 07 80 10 60 60 60 00 00 00 06 01 C8 00 00 (38744)
<- 1A 08 80 00 60 60 60 00 00 00 10 00 6C 58 4D 53 37 32 33 34 35 36 37 00 41 01 00 (63939)
switchRly: 1, 0
<- 0E 09 80 10 60 60 60 00 00 00 06 01 00 00 00 (79477)
<- 1A 0A 80 00 60 60 60 00 00 00 10 00 6C 58 4D 53 37 32 33 34 35 36 37 00 41 01 00 (84190)
b> 14 C2 84 5E 37 CF 02 00 00 00 80 00 50 00 00 00 00 00 08 F3 01 (94484)
b> 0F D0 86 10 22 A1 25 00 00 00 0A A8 E1 0E 0D 1F (105947)
b> 0C 9C 86 70 23 0F CC 00 00 00 00 E8 37 (135698)
l> 0E 9C 82 02 23 15 3E 23 0F CC 01 01 00 00 27 (155765)
b> 14 C3 84 5E 37 CF 02 00 00 00 80 00 50 00 00 00 00 00 08 F8 01 (215823)
switchRly: 1, 200
<- 0E 0B 80 10 60 60 60 00 00 00 06 01 C8 00 5A (303391)
switchRly: 1, 0
<- 0E 0C 80 10 60 60 60 00 00 00 06 01 00 00 5A (304742)
switchRly: 1, 200
<- 0E 0D 80 10 60 60 60 00 00 00 06 01 C8 00 5A (305901)
switchRly: 1, 0
<- 0E 0E 80 10 60 60 60 00 00 00 06 01 00 00 5A (309651)
switchRly: 1, 200
<- 0E 0F 80 10 60 60 60 00 00 00 06 01 C8 00 5A (311051)
switchRly: 1, 0
<- 0E 10 80 10 60 60 60 00 00 00 06 01 00 00 5A (312457)
<- 1A 11 80 00 60 60 60 00 00 00 10 00 6C 58 4D 53 37 32 33 34 35 36 37 00 41 01 00 (316919)
l> 0B 9D A2 58 23 0F CC 23 15 3E 00 00 (321326)
b> 14 C4 84 5E 37 CF 02 00 00 00 80 00 50 00 00 00 00 00 08 F8 02 (386496)
b> 0F D2 86 10 22 A1 25 00 00 00 0A A8 E0 0E 17 1F (395470)
b> 0F 62 86 10 2E A7 10 00 00 00 0A A8 E2 0E 07 00 (449957)
l> 0B 9E A2 58 23 0F CC 23 15 3E 00 00 (472818)
l> 0E 9E 82 02 23 15 3E 23 0F CC 01 01 00 00 27 (472952)
l> 0E 9F 82 02 23 15 3E 23 0F CC 01 01 00 00 27 (609993)
b> 0F 63 86 10 2E A7 10 00 00 00 0A A8 E2 0E 07 00 (628354)
b> 14 C6 84 5E 37 CF 02 00 00 00 80 00 50 00 00 00 00 00 08 FE FD (684986)
b> 0F D4 86 10 22 A1 25 00 00 00 0A A8 E1 0E 17 1F (691472)
b> 0F 64 86 10 2E A7 10 00 00 00 0A A8 E3 0E 07 00 (792300)
b> 14 C7 84 5E 37 CF 02 00 00 00 80 00 50 00 00 00 00 00 08 FC FA (812554)
...
OK, ich habe verstanden, dass "<-" vom Modul gesendet wird. Wenn ich richtig vermute heisst "l>" und "b>" dass etwas empfangen wird?
Im Fhem erscheint allerdings nichts und der pairingstatus wird auch nicht zurückgesetzt.
Jauchz, heute gehts plötzlich.
Was habe ich gemacht, ich habe im Code nachgeschaut, dass es über den configbutton einen Reset gibt (Zweimal hintereinander lang drücken). Dabei wird auch in der internen Config einiges zurückgesetzt. Danach funktionierte das Pairing problemlos:
Jetzt kann ich die eigentliche Aufgabe starten :D
Fazit:
- Die Verdrahtung ist wichtig, wer hätte das gedacht :D
- Ein Reset nach vergeblichen Versuchen wirkt wunder
- 16Mhz macht keine Anpassungen in der Lib nötig
Danke für die Unterstützung (und natürlich die ganze Library)
Johannes
Hallo Zusammen,
ich habe in den letzten Tage und Wochen die Asksin-Lib um die AES-Fähigkeit erweitert.
Dabei gab es auch einen "kleinen" Umbau, damit die Codegröße im Rahmen bleibt.
Das Ganze ist sicher noch nicht stabil, sollte aber funktionieren.
Damit das Ganze dann Einzug in den Master nehmen kann währ es schön, wenn der Eine oder Andere das Ganze mit testen würde.
Das Ganze ist in der DevAES-Branch zu finden.
das derzeit einzige funktionierende Beispiel ist in "HM-LC-Bl1-FM_AES". Die anderen Examples müssen noch nachgezogen werden.
Viele Grüße
Dirk
hi horst,
wollte dir nur eine rückmeldung geben dass heute die 868mhz module angekommen sind. hab gleich mal den pcb sketch drauf geladen und siehe da, alles funtkioniert auf anhieb gleich so wie es soll. mit anlernen oder sonst irgendwas absolut null probleme :-)
vielleicht darf ich noch eine frage stellen zu dem thema eigene sensoren?
klingt vielleicht doof aber ich bin nicht so fit im programmieren, habe aber grundkenntnisse und möchte es lernen. ist deine arbeit schon so weit dass man mit eigenen geräten anfangen kann oder ist das vorerst noch was für absolute vollprofis? ich möchte mir mittels ultraschallsensor den füllstand einer zysterne und die aussentemperatur übermitteln.
ich möchte dir nicht zuviel deiner wertvollen zeit klauen, darum erwarte ich auch bestimmt kein komplettes walktrouth oder so was. bin aber für jeden tipp dankbar. finde ich hier in dem thread infos wie ich vorgehen muss oder kannst du mir nen tipp geben wie ich am besten anfange?
viele grüsse
markus
Hallo Marcus,
Zitat von: daschauher am 27 Oktober 2015, 19:40:28
vielleicht darf ich noch eine frage stellen zu dem thema eigene sensoren?
klingt vielleicht doof aber ich bin nicht so fit im programmieren, habe aber grundkenntnisse und möchte es lernen. ist deine arbeit schon so weit dass man mit eigenen geräten anfangen kann oder ist das vorerst noch was für absolute vollprofis?
Aktuell fehlen noch ein paar Sachen bzw. funktionieren noch nicht wieder nachdem wir ein bisschen was umstrukturiert haben.
Daher braucht es im Moment noch etwas Erfahrung vor allem auch mit dem Protokoll.
Zitatich möchte mir mittels ultraschallsensor den füllstand einer zysterne und die aussentemperatur übermitteln.
Dann könnte das was für sich sein:
http://forum.fhem.de/index.php/topic,42850.0.html
Das basiert zwar noch auf der alten Lib, funktioniert aber soweit.
Vor allem der Sensorteil läuft stabil.
Eine Migration auf die neue Lib wird aber noch etwas daurern.
Viele Grüße
Dirk
Hallo Dirk,
Danke für die Antwort.
ZitatDann könnte das was für sich sein:
http://forum.fhem.de/index.php/topic,42850.0.html
Das basiert zwar noch auf der alten Lib, funktioniert aber soweit.
Vor allem der Sensorteil läuft stabil.
Ja, das sieht ja ganz vielversprechend aus :)
Ich gieße zwar nicht mehr so viel, d.h. wirklich interessant wird es dann ab nächsten frühjahr, aber was man hat das hat man.....vermutlich melde ich mich dann mal in diesem anderem beitrag ;)
viele grüße
markus
Hallo,
ich experimentiere gerade mit dem Beispiel: "HM_LC_SW1_BA_PCB" und versuche damit den entsprechenden Aktor mit 4 Kanälen aufzubauen (HM_LC_SW4_BA_PCB).
Folgendes habe ich in der "register.h" gemacht:
Model ID 2 byte */ 0x00,0x6c, -> gegen -> Model ID 2 byte */ 0x00,0xab, ersetzt
die Model ID fand ich in der "hm device list.txt"
Mit dieser Änderung bekommen ich schon den richtigen 4-K. Aktor in der CCU2 angezeigt, jedoch nur mit einem Kanal.
Daraufhin noch einige Änderungen, die jedoch an der Stelle nichts gebraucht haben (nach jedem Versuch habe ich das Gerät abgelernt und neu angelernt):
cmSwitch cmSwitch[1]; -> cmSwitch cmSwitch[4]; // create instances of channel module
/* Device Info 3 byte */ 0x41,0x04,0x00, // describes device, not completely clear yet. includes amount of channels
-> ursprünglich 0x41, 0x01, 0x000 (vermute mal in der 0x01 steckt die Anzahl der Schaltkanäle
hier muss sicher noch etwas erweitert werden, nur woher bekomme ich die Info wie das beim 4-fach Schalter aussieht:
//- channel device list table --------------------------------------------------------------------------------------------
EE::s_cnlTbl cnlTbl[] = {
// cnl, lst, sIdx, sLen, pAddr, hidden
{ 0, 0, 0x00, 6, 0x000f, 0, },
{ 1, 1, 0x00, 0, 0x0000, 0, },
{ 1, 3, 0x06, 22, 0x0015, 0, },
}; // 21 byte
und hier:
// register user modules
cmSwitch[0].regInHM(1, 3, &hm); // register user module
cmSwitch[0].config(&initRly, &switchRly); // configure user module
Grüße,
Jochen
Hi Jochen,
Du bist schon auf dem richtigen Weg.
Über die Model ID wird innerhalb der CCU das richtige XML File gezogen.
Über ein Byte in der Device Info steuert die CCU bei manchen Geräten die Anzahl der Kanäle.
# 23:0 0.4, means first four bit of byte 23 reflecting the amount of channels.
Der Channel Table ist das zentrale Element für die Lib, hier werden die Verweise auf Kanäle und Listen gesteuert. Für einen Vierfach Aktor sieht der Channel Table etwa so aus:
EE::s_cnlTbl cnlTbl[] = {
// cnl, lst, sIdx, sLen, pAddr, hidden
{ 0, 0, 0x00, 6, 0x0020, 0, },
{ 1, 1, 0x06, 1, 0x0026, 0, },
{ 1, 3, 0x07, 22, 0x0027, 0, },
{ 2, 1, 0x06, 1, 0x00ab, 0, },
{ 2, 3, 0x07, 22, 0x00ac, 0, },
{ 3, 1, 0x06, 1, 0x0130, 0, },
{ 3, 3, 0x07, 22, 0x0131, 0, },
{ 4, 1, 0x06, 1, 0x01b5, 0, },
{ 4, 3, 0x07, 22, 0x01b6, 0, },
}; // 63 byte
Die nötigen Register für den Aktor würden so aus sehen
const uint8_t cnlAddr[] PROGMEM = {
// channel: 0, list: 0
0x02,0x0a,0x0b,0x0c,0x12,0x18,
// channel: 1, list: 1
0x08,
// channel: 1, list: 3
0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,
}; // 29 byte
Dazu braucht man natürlich noch einen Speicherbereich für die Peer der 4 Kanäle reflektiert
EE::s_peerTbl peerTbl[] = {
// cnl, pMax, pAddr;
{ 1, 6, 0x023a, },
{ 2, 6, 0x0252, },
{ 3, 6, 0x026a, },
{ 4, 6, 0x0282, },
}; // 16 byte
Und zu guter Letzt muss man der Lib sagen, wieviele Kanäle das Device insgesamt hat und wo diese Infos zu finden sind
/*
* Device definition table
* Parameter: amount of user channel(s), amount of lists,
* pointer to device identification string and pointer to the channel table
*/
EE::s_devDef devDef = {
4, 9, devIdnt, cnlAddr,
}; // 6 byte
/*
* module registrar
* size table to register and access channel modules
*/
RG::s_modTable modTbl[4];
So sollte es klappen...
Konfiguriert werden die Kanäle dann wie folgt
/**
* @brief First time and regular start functions
*/
void everyTimeStart(void) {
/*
* Place here everything which should be done on each start or reset of the device.
* Typical use case are loading default values or user class configurations.
*/
// init the homematic framework
hm.confButton.config(2, CONFIG_KEY_PCIE, CONFIG_KEY_INT); // configure the config button, mode, pci byte and pci bit
hm.ld.init(2, &hm); // set the led
hm.ld.set(welcome); // show something
hm.bt.set(30, 3600000); // set battery check, internal, 2.7 reference, measurement each hour
hm.pw.setMode(0); // set power management mode
// register user modules
cmSwitch[3].regInHM(1, 3, &hm); // register user module
cmSwitch[3].config(&initRly, &switchRly); // configure user module
cmSwitch[1].regInHM(2, 3, &hm); // register user module
cmSwitch[1].config(&initRly, &switchRly); // configure user module
cmSwitch[2].regInHM(3, 3, &hm); // register user module
cmSwitch[2].config(&initRly, &switchRly); // configure user module
cmSwitch[0].regInHM(4, 3, &hm); // register user module
cmSwitch[0].config(&initRly, &switchRly); // configure user module
}
Wie Du siehst, jeder der Switch Module verzweigt in die selben Funktionen zur Initialisierung der Pins oder zum Ausführen der Schaltfunktionen.
In die Init und Schaltfunktion wird eine Kanalkennung übergeben...
cmSwitch cmSwitch[4]; // create instances of channel module
extern void initRly(uint8_t channel); // declare function to jump in
extern void switchRly(uint8_t channel, uint8_t status); // declare function to jump in
Viele Grüße
Horst
Hi,
ich habe einen Arduino 328p und einen CC1101 RF1100SE und exakt das gleiche Problem wie "daschauher". Ich habe zwei Tage gebraucht um soweit zu kommen.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
....
CC.
12...................................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1938)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (7670)
Auf der FHEM Seite habe ich denselben CC1101 und einen Arduino Nano als NanoCul. Diesen habe ich auf 868MHZ eingestellt.
Hat mir jemand einen Tipp?
Lieben Dank
Hallo MBHG,
ich habe mir neue bestellt welche für 868mhz ausgelegt sind. Dann hat es auf Anhieb geklappt.
Viele Grüße
Hi Daschauher,
Was bei mir mit dem Uno auch nicht geht sind die klassischen Beispiele aus der rcswitch library. Ich vermute mal, dass diese version des uno mit diesem speziellen cc1101 nicht will, obwohl der nano mit dem cc1101 kann.
Vielleicht bau ich mal nen level shifter dazwischen bis der andere cc1101 kommt.
Lieben dank
Mb
Hallo,
update: nach viel viel hin und herprobieren, hab ich nochmal die newasksin library geladen und manuell
1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00
gesendet. Und siehe da ich empfange ihn in dem logfile von fhem:
2015.11.15 18:27:13 4: CUL_Parse: CUL_0 A 1A 01 8000 5823FF 000000 10006C584D533132333435363700410100D4 -96
2015.11.15 18:27:13 2: CUL_HM Unknown device HM_5823FF is now defined
2015.11.15 18:27:13 2: autocreate: define HM_5823FF CUL_HM 5823FF
Momentan kommt im ersten Augenblick noch nichts zurück auf das Modul, aber dann eine Nachricht im Nachgang
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1938)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (7953)
15 BE 81 14 34 3C 3C FE D5 F7 43 0F 54 04 B2 40 CD 02 28 BC 18 1A
l> 15 C8 1B 49 C4 2C 24 E6 0F 46 90 10 BF 34 52 CE D1 AB F6 B8 80 01 (282278)
Wenn ich in fhem das angelegte Device einen on und off Befehl sende, kommt er in der Regel an, es wird aber kein ACK zurückgesandt.
Gruss
Hallo zusammen,
kann jemand mit wiki Schreibzugriff die Tabelle unten ins wiki übernehmen?
Dann muss ich beim nächsten mal nicht durch alle Seiten dieses threads gehen :)
Schönen Dank auch für die coole library.
Gruss Raimund
Anschluss RF1101SE-V3.1 an arduino nano
CC1101 Pin -> Arduino nano
1 VCC -> 17
2 -
3 SI -> 14
4 SCLK -> 16
5 S0 -> 15
6 GDO0
7 CSN -> 13
8 GDO0 -> 5
9 GND -> 4
10 GND
Hi trilu,
die Modifikationen zu HM-LC-Sw4-PCB 4 funktionieren. Anbei der Screenshot aus FHEM.... Genug für heute, jetzt muss ich nur noch schauen warum das ACK nicht kommt und dann Ausgänge schalten.
Danke!
MB
Hi,
irgendwie funktioniert es nicht mehr ganz. Ich kann den HM_LC_SW4_BA_PBC durch Pin8 auf GND zwar veranlassen mit fhem zu pairen, aber die vier Schalter werden nicht mehr angelegt:
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMoäY',RinitRly: 1
initRly: 2
initRly: 3
initRly: 4
....
CC.
12...................................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: F1 1C 00
<- 0E75
<- 0E 03 A0 10 58 23 FF F1 1C 00 06 04 00 00 00 (1938)
<- 0E75
<- 0E 03 A0 10 58 23 FF F1 1C 00 06 04 00 00 00 (2239)
<- 0E75
<- 0E 03 A0 10 58 23 FF F1 1C 00 06 04 00 00 00 (2540)
timed out (2840)
<- 1A72
<- 1A 04 A0 00 58 23 FF F1 1C 00 10 00 AB 58 4D 53 31 32 33 34 35 36 37 00 41 04 00 (105649)
<- 1A72
<- 1A 04 A0 00 58 23 FF F1 1C 00 10 00 AB 58 4D 53 31 32 33 34 35 36 37 00 41 04 00 (105950)
<- 1A72
<- 1A 04 A0 00 58 23 FF F1 1C 00 10 00 AB 58 4D 53 31 32 33 34 35 36 37 00 41 04 00 (106251)
timed out (106546)
10 73 FF DA 47 23 FF 83 7C A7 83 5B 5B 04 BA 40 CD
u> 10 05 B0 01 F1 00 00 58 23 FF 00 04 6C 33 5A D6 7D (156339)
10 70 FC D9 44 20 FC 80 7F A4 80 58 34 10 EC C8 B0
u> 10 06 B0 01 F1 00 00 58 23 FF 00 04 00 00 00 00 00 (220998)
10 70 FC D9 44 20 FC 80 7F A4 80 80 58 34 10 EC C8
u> 10 06 B0 01 F1 00 00 58 23 FF 00 DC 04 00 00 00 78 (226319)
10 71 FD D8 45 21 FD 81 7E A5 81 59 35 11 ED C9 B0
u> 10 07 B0 01 F1 00 00 58 23 FF 00 04 00 00 00 00 00 (635842)
10 71 FD D8 D8 45 21 FD 81 7E A5 81 59 35 11 ED C9
l> 10 07 B0 01 6C F1 00 00 58 23 FF 00 04 00 00 00 79 (641696)
Und von FHEM:
2015.11.18 11:28:23 4: CUL_Parse: CUL_0 A 1A 04 A000 5823FF F11C00 1000AB584D533132333435363700410400CC -100
2015.11.18 11:28:23 2: CUL_HM Unknown device HM_5823FF is now defined
2015.11.18 11:28:23 2: autocreate: define HM_5823FF CUL_HM 5823FF
2015.11.18 11:28:23 4: CUL_Parse: CUL_0 A 1A 04 A000 5823FF F11C00 1000AB584D533132333435363700410400CD -99.5
2015.11.18 11:29:08 3: CUL_HM set HM_5823FF getConfig
2015.11.18 11:29:08 4: CUL_send: CUL_0As 10 05 B001 F10000 5823FF 00040000000000
2015.11.18 11:29:14 4: CUL_send: CUL_0As 10 05 B001 F10000 5823FF 00040000000000
2015.11.18 11:30:19 3: CUL_HM set HM_5823FF getConfig
2015.11.18 11:30:19 4: CUL_send: CUL_0As 10 06 B001 F10000 5823FF 00040000000000
2015.11.18 11:30:25 4: CUL_send: CUL_0As 10 06 B001 F10000 5823FF 00040000000000
2015.11.18 11:37:19 3: CUL_HM set HM_5823FF getConfig
2015.11.18 11:37:19 4: CUL_send: CUL_0As 10 07 B001 F10000 5823FF 00040000000000
2015.11.18 11:37:24 3: CUL_HM set HM_5823FF getConfig
2015.11.18 11:37:25 4: CUL_send: CUL_0As 10 07 B001 F10000 5823FF 00040000000000
Daneben ist mir fhem zwischendurch mal abgestürzt. Beim pairen lief fhem in einer Endlosschleife und hat 25x in der Sec folgendes Signal versandt
2015.11.18 11:07:13 4: CUL_send: CUL_0As 10 01 B001 F10000 5823FF 00050000000000
2015.11.18 11:07:13 4: CUL_send: CUL_0As 10 01 B001 F10000 5823FF 00050000000000
2015.11.18 11:07:13 4: CUL_send: CUL_0As 10 01 B001 F10000 5823FF 00050000000000
2015.11.18 11:07:13 4: CUL_send: CUL_0As 10 01 B001 F10000 5823FF 00050000000000
2015.11.18 11:07:13 4: CUL_send: CUL_0As 10 01 B001 F10000 5823FF 00050000000000
Gruss
Hi Leute,
ich versuche nun schon seit Tagen die Asksin Library zum laufen zu bringen, aber fhem empfängt einfach nichts. Die serielle Ausgabe des Arduinos sieht dabei so aus wenn ich einmal länger den config Taster betätige:
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (20113)
Als Hardware verwende ich einen Arduino pro Mini 3.3v 8MHz zusammen mit einem CC1101 Funkmodul von ebay: http://www.ebay.de/itm/400995834179.
Lade ich einen Beispielsketch aus der original Panstamp library, kann ich mit einem identischen System senden und auch empfangen, also gehe ich davon aus, dass die Verkabelung korrekt ist.
Woran könnte mein Problem liegen?
Vielen Dank im Voraus für jegliche Hilfe,
Mathea
Guten Abend.
Kann evtl. nochmal einer genau erklären was ich bei dem
StatusLed.h:18:20: fatal error: Serial.h: No such file or directory
Fehler machen muss?
Habe OSX mit Arduino 1.6.6
Die Libs aus der NewAsksin sind im libraries Ordner der IDE eingefügt. "-master" ist entfernt.
Er meckert den Pfad
/Users/Username/Documents/Arduino/libraries/AskSin/utility/StatusLed.h:18:20: fatal error: Serial.h: No such file or directory an.
Die Datei ist aber vorhanden und die Gross und Kleinschreibung stimmt auch so.
Komme nicht weiter....
Gute Nacht, Chris
Hallo Leute,
ich wollte auch mit dem Erstellen von eigenen Sensoren anfangen.
Vor längerem hab ich ein paar Arduino nano Clone gekauft, für den Batteriebetrieb ungeignet aber für die ersten test ausreichen.
Dazu habe ich noch eine defekte Homematic Schaltsteckdose, wo ich den Transceiver klauen wollte.
Der Bausatz hat nie funtkioniert, habe von ELV einen ersatz bekommen, denke mal der Transceiver wird noch funktionieren.
Was mir jetzt nicht klar wird ist, wie ich Anfangen soll?
Das wiki scheint mir auch veraltet zu sein.
Mit Arduino hab ich schon hin und wieder hantiert, ist aber ein wenig länger her.
Ich würde gerne mit einem Sensor anfangen um den Briefkasten zu erfassen.
Musste also zwei Read Kontakte auslesen.
Kann mir bitte jemand sagen wo ich anfangen soll?
Gruß Robert
Zitat von: webturtle am 05 Dezember 2015, 23:21:07
Guten Abend.
Kann evtl. nochmal einer genau erklären was ich bei dem
StatusLed.h:18:20: fatal error: Serial.h: No such file or directory
Fehler machen muss?
Habe OSX mit Arduino 1.6.6
Die Libs aus der NewAsksin sind im libraries Ordner der IDE eingefügt. "-master" ist entfernt.
Er meckert den Pfad
/Users/Username/Documents/Arduino/libraries/AskSin/utility/StatusLed.h:18:20: fatal error: Serial.h: No such file or directory an.
Die Datei ist aber vorhanden und die Gross und Kleinschreibung stimmt auch so.
Komme nicht weiter....
Gute Nacht, Chris
Ich bin zurück zur Arduino IDE Version 1.6.5 gegangen, da ich auch Probleme mit 1.6.6 hatte (allerdings andere Meldungen)
Johannes
@trilu: Ich habe mal ein wenig mit verschiedenen devices rumgespielt, dabei auch einen dimmer erzeugt.
Grundsätzlich geht das ja auch, allerdings gibt es ein Problem mit der duration. Von FHEM wird eine duration FF FF geliefert (vermutlich um anzuzeigen, dass der Status unendlich beliben soll). In Newasksin führt das aber dazu, dass zuerst auf den neuen Wert gefahren wird und dann wieder auf 0. Wenn ich testweise im Falle FFFF den Wert von duraTime in cmDimmer::trigger11 auf 0 setze funktioniert es wie erwartet.
Weitere Frage: Ich habe auch mal versucht ein Remote-Display mit Buttons --> HM-PB-4Dis-WM zu erzeugen. Hat das schonmal jemand versucht? Ich bekomme dann interessanterweise 20 Schalter (nicht 4 wie erwartet...) und es ist mir auch nicht ganz klar, wo die Texte landen. Aber da bleibe ich mal dran.
Hallo Leute,
ich bin hier auf das Forum gestoßen, weil ich per Arduino meine HM Aktoren ansprechen und steuern möchte. Ich wühle mich schon seit Tagen und Wochen durch diese unzähligen Beiträge. Ich dachte einfach mal ich starte das mal so wi es ist und wurschlte mich durch.
In dem Projekt werden libaries included die es gar nicht gibt, das verstehe ich schon mal nicht..kann das sein dass das alles sehr mächtig geworden ist mit der Zeit ?
Mein Ziel ist es per Funk Schlater an und auzuschalten und einen Thermostat anzusteuern.. wenn ich hier auf dem Wege des Holzes sein sollte, kann mir jemand ruhig einen Denkstoß mitteilen ;-)
Ziel ist das ohne HM CCU. lg
Zitat von: frank am 17 Mai 2015, 09:54:35
hallo trilu,
ich versuche gerade der alternativen firmware für den sw1pbu-fm das sensor_event beizubringen. dazu habe ich mir deine umsetzung in der newasksin-library (trigger41) kopiert und angepasst.
Hallo!
Ich bin die Tage auf die gleiche Idee gekommen. Hast du das fertig bekommen?
ZitatHast du das fertig bekommen?
nur trockenübungen, nie geflasht und getestet.
so bin jetzt mal durch alle 65 Seiten Trööt durch und jetzt vollständig verwirrt.
welche Hardware an welchem Funkmodul ? PanStamp, Arduino, rfm12, rfm22, das ding von ELV, CC1101 868 MHz, CC1101 464 oder was auch immer. Das wiki ist wohl nicht mehr aktuell ?
Irgendwie lässt sich die lib aus dem Git nicht richtig kompillieren. etc etc
Trotzdem ne suuuuper Arbeit sich überhaupt mal an sowas ran zu wagen. Nutz nur nicht wirklich viel wenn nicht endlich mal eine Anlaufstelle geschaffen wird wo wenigstens mal ein Grundansatz zu Hart und Software nachzulesen ist.
So jetzt mein erstes Problem:
Wollte erstmal bis ich durchblicke die Lib verstehen und hab deshalb erstmal die Arduino-IDE runtergeladen und die Lib aus dem GIT geholt.
Hab beides Installiert. bei der Lib das "-master" entfernt und in den richtigen ordner gepackt. Funktioniert. Also das erste Sample geladen und versucht zu übersetzen (AskinNew_test) geht aber nicht bricht ab mit der Meldung
Arduino: 1.6.7 (Windows 7), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
Build-Optionen wurden verändert, alles wird neu kompiliert
In file included from C:\Users\kleinerDrache\Documents\Arduino\libraries\NewAskSin\examples\AskinNew_test\AskinNew_test.ino:10:0:
register.h:37: error: uninitialized const member 'EE::s_cnlTbl::vis'
}; // 12 byte
^
register.h:37: error: uninitialized const member 'EE::s_cnlTbl::vis'
exit status 1
uninitialized const member 'EE::s_cnlTbl::vis'
bin trotz Gemecker am Anfang für Hilfe dankbar.
thx Tim
Zitat von: kleinerDrache am 03 Januar 2016, 22:15:23
so bin jetzt mal durch alle 65 Seiten Trööt durch und jetzt vollständig verwirrt.
welche Hardware an welchem Funkmodul ? PanStamp, Arduino, rfm12, rfm22, das ding von ELV, CC1101 868 MHz, CC1101 464 oder was auch immer. Das wiki ist wohl nicht mehr aktuell ?
Irgendwie lässt sich die lib aus dem Git nicht richtig kompillieren. etc etc
Trotzdem ne suuuuper Arbeit sich überhaupt mal an sowas ran zu wagen. Nutz nur nicht wirklich viel wenn nicht endlich mal eine Anlaufstelle geschaffen wird wo wenigstens mal ein Grundansatz zu Hart und Software nachzulesen ist.
So jetzt mein erstes Problem:
Wollte erstmal bis ich durchblicke die Lib verstehen und hab deshalb erstmal die Arduino-IDE runtergeladen und die Lib aus dem GIT geholt.
Hab beides Installiert. bei der Lib das "-master" entfernt und in den richtigen ordner gepackt. Funktioniert. Also das erste Sample geladen und versucht zu übersetzen (AskinNew_test) geht aber nicht bricht ab mit der Meldung
Arduino: 1.6.7 (Windows 7), Board: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
Build-Optionen wurden verändert, alles wird neu kompiliert
In file included from C:\Users\kleinerDrache\Documents\Arduino\libraries\NewAskSin\examples\AskinNew_test\AskinNew_test.ino:10:0:
register.h:37: error: uninitialized const member 'EE::s_cnlTbl::vis'
}; // 12 byte
^
register.h:37: error: uninitialized const member 'EE::s_cnlTbl::vis'
exit status 1
uninitialized const member 'EE::s_cnlTbl::vis'
bin trotz Gemecker am Anfang für Hilfe dankbar.
thx Tim
Da ich mich da gerade auch durchgekämpft habe kann ich vielleicht bei einigen Dingen helfen:
- Die Besipiele bei newasksin enthalten jeweils eine Datei mit dem Status. Bei AskinNew_test steht da (zumindest bei meinem Stand) broken ...
Gehen tut wohl (nur): HM_LC_SW1_BA_PCB
- Weiterer Tipp: Bei der Arduino IDE würde ich momentan die Version 1.6.6 meiden (die 1.6.5 scheint momentan besser geeignet zu sein)
- Als Funkmodul gibt es wohl wirklich mehrere Möglichkeiten. Ich verwende ein CC1101 868Mhz-Modul (Ich wüsste nicht, dass RFM-Module gehen und auf jeden Fall macht es Sinn für HM eine 868-Mhz_modul zu verwenden)
-
OK danke für die Tipps werd ich morgen mal ausprobieren und die Bestellung für ein paar cc's plus arduinos losjagen.
Und die IDE funzt auch nicht in der letzten Version 1.6.7 ?
Gesendet von meinem GT-P5200 mit Tapatalk
Zitat von: kleinerDrache am 03 Januar 2016, 22:40:36
OK danke für die Tipps werd ich morgen mal ausprobieren und die Bestellung für ein paar cc's plus arduinos losjagen.
Und die IDE funzt auch nicht in der letzten Version 1.6.7 ?
Das kann ich nicht sagen, ich bin nach einem Versuch mit 1.6.6 wieder glücklich zurück auf 1.6.5 gegangen und werde erstmal noch etwas abwarten. 1.6.7 kannst Du ausprobieren, wenn aber unerklärliche Fehlermeldungen hochkommen, würde ich auf 1.6.5 gehen.
Hallo,
bin noch ziemlich frisch unterwegs in Sachen HM. Habe ein Boardlayout entwickelt. Das Board wird mit jeweils einem HM-MOD-RE8 und einem HM-MOD-EM8, sowie einem Genuino Micro bestückt.
Habe jetzt dieses Projekt verfolgt. Es wäre sehr Interessant, da ich mir den Sender sowie den Empfänger sparen könnte.
Jetzt zu meiner Frage, wäre es möglich, die Library für einen Sender und Empfänger zeitgleich zu nutzen?
Wäre euch sehr dankbar für ein paar tipps. Habe bisher nur in C# Erfahrungen. Benutze Atmel Studio mit Visual Micro (Arduino IDE).
Grüße,
East
Zitat von: east am 04 Januar 2016, 13:40:27
Hallo,
bin noch ziemlich frisch unterwegs in Sachen HM. Habe ein Boardlayout entwickelt. Das Board wird mit jeweils einem HM-MOD-RE8 und einem HM-MOD-EM8, sowie einem Genuino Micro bestückt.
Habe jetzt dieses Projekt verfolgt. Es wäre sehr Interessant, da ich mir den Sender sowie den Empfänger sparen könnte.
Jetzt zu meiner Frage, wäre es möglich, die Library für einen Sender und Empfänger zeitgleich zu nutzen?
Wäre euch sehr dankbar für ein paar tipps. Habe bisher nur in C# Erfahrungen. Benutze Atmel Studio mit Visual Micro (Arduino IDE).
Grüße,
East
Bin jetzt nicht ganz sicher, was du meinst?
Für hm ist eigentlich immer ein sender und ein empfänger nötig, da hm bidirektional arbeitet und jede sendung rückbestätigt wird.
Wenn du meinst, ob ein transceivermodul sich selbst kommandos senden kann, dann vermute ich ohne jetzt recherchiert zu haben, dass das nicht geht.
Johannes
Nein. Nein. Schon richtig. Ich meine, die sketche die der NewAskin beiliegen sind alle samt als Empfangsmodule ausgelegt. Gibt es die möglichkeit, ein paar (4 Fach) Ausgänge die als Empfänger bspw. HM-SW4 und ein paar andere als Eingänge zum senden zu benutzen. Oder sieht das die Library nicht vor?
Weiter habe ich ein bischen in der Library versucht zu verstehen wie die Channels für die Ausgänge erweitert werden könnten, habe dazu auch die Threads hier versucht nachzuvollziehen. Was ich nicht ganz verstehe, ist das "void switchRly(uint8_t channel, uint8_t status)" in der Register.h deklariert und in der .ino die Funktion geschrieben wird. Allerdings sehe ich nicht wo diese Funktion aufgerufen wird. Vielleicht liegt das daran das ich mich mit Klassen(C++) noch nicht so auskenne. Bisher habe ich in C# nur mit Pointern gearbeitet.
Grüße,
Dennis
Zitat von: east am 05 Januar 2016, 08:55:14
Nein. Nein. Schon richtig. Ich meine, die sketche die der NewAskin beiliegen sind alle samt als Empfangsmodule ausgelegt. Gibt es die möglichkeit, ein paar (4 Fach) Ausgänge die als Empfänger bspw. HM-SW4 und ein paar andere als Eingänge zum senden zu benutzen. Oder sieht das die Library nicht vor?
Weiter habe ich ein bischen in der Library versucht zu verstehen wie die Channels für die Ausgänge erweitert werden könnten, habe dazu auch die Threads hier versucht nachzuvollziehen. Was ich nicht ganz verstehe, ist das "void switchRly(uint8_t channel, uint8_t status)" in der Register.h deklariert und in der .ino die Funktion geschrieben wird. Allerdings sehe ich nicht wo diese Funktion aufgerufen wird. Vielleicht liegt das daran das ich mich mit Klassen(C++) noch nicht so auskenne. Bisher habe ich in C# nur mit Pointern gearbeitet.
Grüße,
Dennis
Ich bin nachwievor nicht sicher, was du mit empfangsmodulen. Die beispiele umfassen einen aktor (dimmer) aber auch einen "sensor" also eine fernbedienung, die einen aktor auslösen kann.
Switchrly wird in der konfiguration des channels als funktionspointer mitgegeben und dann wird nicht die benannte funktion sondern der pointer aufgerufen. Die übergabe passiert in der initialisierung des systems / setups. Du findest in der lib keine benutzung von switchrly das wäre auch falsch, denn beim dimmer wird eine andere funktion aufgerufen und bei mir nochmal eine andere.
Aber ich gebe zu die lib ist etwas unübersichtlich und ich habe bisher nur einen groben überblick.
Achso. Vielen Dank für die Hilfe. Wenn ich das jetzt richtig verstanden habe. Könnte ich einen 4 Kanal Aktor im Programm parallel mit einem Sensor.- Eingang laufen lassen? Ist das Möglich? Das meine ich auch. Sorry für die Erklärung.
Also innerhalb eines Sketches, paralleler Betrieb von 4 Kanal Aktor und Sensoreingänge? Vorausgesetzt die CCU sieht das vor?
Also zeitgleichen Aktor und Sensor- Betrieb des Clones. Dadurch würde ich mir ein Modul sparen. Sonst müsste ich jeweils immer zwei Module bauen, um zu Senden und Empfangen. Mir ist nur wichtig das das innerhalb eines Moduls parallel läuft ( theoretisch Eingänge die zum senden führen und Ausgänge die empfangen wurden. Mit nur einem Modul.)
ps. Ich glaube ich muss mir erstmal einen Überblick im Programm verschaffen.
Vielen Dank im Voraus.
Dennis
@east: Ich bin gerade erst dazugekommen die Module HM-MOD-RE8 etc nachzuschauen, wenn ich das richtig verstehe enthalten die nicht nur einen Sender/Empfänger sondern auch bereits eine komplette HM-Implementierung. Nach meinem Verständnis braucht werden HM-MOD-RE8 noch HM-MOD-EM8 eine Asksin auf einem Arduino. Das Modul enthält bereits alles was durch AskSin dazukommen würde.
Asksin/NewAskSin ist nötig um mit einem "generischen" Send/Empfangsmodul auch HM-Geräte bauen zu können.
Johannes
Ja, richtig. Die eigentliche Frage war ja auch, ob ich die Module mit einem eigens gebautem Modul was mit der Askin läuft ersetzen kann.
Ich möchte einfach nur die beiden Module von HM durch eines mit der Askin ersetzen. :)
Gruß,
Dennis
Zitat von: east am 05 Januar 2016, 15:45:55
Ja, richtig. Die eigentliche Frage war ja auch, ob ich die Module mit einem eigens gebautem Modul was mit der Askin läuft ersetzen kann.
Ich möchte einfach nur die beiden Module von HM durch eines mit der Askin ersetzen. :)
Gruß,
Dennis
Theoretisch würde das gehen, praktisch scheitert das aber möglicherweise an der Grösse des Codes / Speicheranforderung (zumindest wenn wir von Arduino Nano etc mit ATMega328P reden). Ich habe inzwischen zwar aus den Devicebeschreibung (distillregs2) mal einige Registerbeschreibungen generiert und damit auch Code zum Laufen bekommen. Allerdings gibt es auch Fälle bei denen die erzeugten register.h nicht funktioniert ohne dass mir klar ist warum. Also könnte das ein zweites Problem auf dem Weg zu Asksin/Newasksin sein.
Ich kann auch nicht einschätzen wieviel hier noch in Codeänderungen investiert wird.
Johannes
Ahh.. OK.
Das heisst wenn dann zb. einen Micro mit nem Mega32U4 oder so. OK wenn die 868 Module kommen mach mich mal ran ans Werk.
Hoffe doch das es noch weiter geht. Denn damit kann man viel Geld sparen, sollte man so etwas vorhaben. Natürlich würde das auch mit nem Raspberry gehen, aber genau wie die CCU kann das Dingen abstürzen. Bei so nen Askin-Modul würde das auch sehr wahrscheinlich stabiler sein. Denke ich.
OK. Der 32u4 hat ja nur 0.5kb mehr Sram. Das wars. Aber vielleicht ein 644 oder 1284P. Mal schauen.
Vorerst schon mal vielen Dank für die Mühe. Ich werde Euch dann auf den laufenden halten. Wenn ich da einmal durchblicke, werde ich das schon hinbekommen.
Grüße,
Dennis
Zitat von: east am 05 Januar 2016, 17:32:32
Ahh.. OK.
Das heisst wenn dann zb. einen Micro mit nem Mega32U4 oder so. OK wenn die 868 Module kommen mach mich mal ran ans Werk.
Hoffe doch das es noch weiter geht. Denn damit kann man viel Geld sparen, sollte man so etwas vorhaben. Natürlich würde das auch mit nem Raspberry gehen, aber genau wie die CCU kann das Dingen abstürzen. Bei so nen Askin-Modul würde das auch sehr wahrscheinlich stabiler sein. Denke ich.
OK. Der 32u4 hat ja nur 0.5kb mehr Sram. Das wars. Aber vielleicht ein 644 oder 1284P. Mal schauen.
Vorerst schon mal vielen Dank für die Mühe. Ich werde Euch dann auf den laufenden halten. Wenn ich da einmal durchblicke, werde ich das schon hinbekommen.
Grüße,
Dennis
32u4 bringt keine Lösung aber vielleicht andersrum, werden denn wirklich 8 Relaisausgänge und -eingänge an einer Stelle gebraucht, macht es nicht Sinn das aufzuteilen?
Nein Nein. Brauche nicht so viele ein- und ausgänge. Ausgänge vielleicht 4. Eingänge nur 2. Brauche nicht alle Kanäle der 8 des Empfängers oder des Senders.
Mal was anderes. Warum wurde die alte AskSin durch die NewAskSin ersetzt? Die alte ist der neuen in Übersichttlichkeit auf jeden Fall überlegen.
Die Frage müsste an trilu gehen, wie gesagt ich habe mich auch erst eingearbeitet,
Johannes
@kleinerDrache
Nehme nicht die AES lib sondern die normale newAskin https://github.com/trilu2000/NewAskSin
und bleibe bei de 1.6.5 auch die 1.6.7 macht probleme bei verschiedenen Sketches (nicht nur Askin)
dort sollten die unteren 3 Beispiele funktionieren
HM_LC_Bl1_SM
HM_LC_Dim1PWM_CV
HM_LC_SW1_BA_PCB
Anschliessen des Funkmoduls ist richtig beschrieben in der WIKI, was noch fehlt ist z.B.
-Konfigtaster an Digital 8 gegen masse
-Status LED Digital 4 gegen masse
-Schalt Ausgang Digital 3 gegen masse (je nach sketch)
Die Anschlüsse sieht man in der Hardware.h und nach funktion im haupt ino
Hier mal ein Beispiel von mir wo der Digital D3 als standart im sketch und von mir erweitert auf D5
void switchRly(uint8_t channel, uint8_t status) {
// switching the relay, could be done also by digitalWrite(3,HIGH or LOW)
#ifdef SER_DBG
dbg << F("switchRly: ") << channel << ", " << status << "\n";
#endif
// check status and set relay pin accordingly
if (status) { setPinLow(PORTD,5); // Stromversorgung für Tor einschalten
if (hoch ==0) _delay_ms (3000); // Zeitverzögerung nur Einschalten wenn Stromversorgung aus war.
millisAlt = getMillis();
setPinHigh(PORTD,3); // Jetzt sender Schalten zur Bewegung des Tor's mit Verzögerung von 3 sec;
hoch = 1;}
else {setPinLow(PORTD,3);}
}
//- predefined functions --------------------------------------------------------------------------------------------------
Ich hoffe, das Dirk die AES branch noch fixed und über zeit ein Beispiel für jedes Homematic device bekommen um es einfacher zu machen :D
@Trilu und Dirk, danke für die tolle Lib.
danke
Ich nehme die newAskin da die Alte ja nicht weiter entwickelt wird. Die Sketche lassen sich bis auf Lux und Test mit der neuesten IDE compilen. Brauch das ding eh nur für die Askin Lib alles andere auf dem Mega mach ich mit der Atmel IDE.
Trotzdem danke für die Tips und für die geile Lib.
Hi,
ich habe mir zwei Arduino Nanos geholt inkl. zwei echten 868 Funkmodulen. Pin 25 und 26 habe ich verbunden. HM_LC_SW4_BA_PCB auf den einen culf-520-trunk auf den anderen. Nach ein wenig hin und her hat das Pairing geklappt.
Manuelles Schalten der Zustände am HM_LC_SW4_BA_PCB inkl. korrekte Übertragung auf den CUL868 und FHEM klappt tadellos. Allerdings funktioniert die andere Richtung nur selten. Sprich schalten an FHEM resultiert in einen Schaltzustand am HM_LC_SW4_BA_PCB nur selten.
Wenn ich den CUL868 resette, sprich abziehe und wieder anstecke, dann funktioniert der erste Befehl eigentlich immer. Was auch immer funktioniert sind manuelle Schaltzustände an HM_LC_SW4_BA_PCB, die an den CUL868 übertragen werden.
Anbei mein Log von den letzten Aktivitäten
HM_LC_SW4_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMod¥� 0
initRly: 1
initRly: 2
initRly: 3
initRly: 4
....
CC.
12...................................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: F1 28 07
<- 0E77
<- 0E 01 A0 10 58 23 FF F1 28 07 06 04 00 00 00 (1938)
<- 0E75
<- 0E 03 A0 10 58 23 FF F1 28 07 06 02 00 00 00 (2239)
<- 0E75
<- 0E 03 A0 10 58 23 FF F1 28 07 06 02 00 00 00 (2540)
timed out (2840)
<- 0E77
<- 0E 01 A0 10 58 23 FF F1 28 07 06 04 00 00 00 (243710)
<- 0E77
<- 0E 01 A0 10 58 23 FF F1 28 07 06 04 00 00 00 (244011)
<- 0E77
<- 0E 01 A0 10 58 23 FF F1 28 07 06 04 00 00 00 (244312)
timed out (244612)
0B 7F EB C6 53 07 E4 98 57 CC A9 BE
m> 0B 09 B0 01 F1 28 07 58 23 FF 01 0E (309192)
<- 0E7F
<- 0E 09 A0 10 58 23 FF F1 28 07 06 01 00 00 65 (309204)
0B 7C F8 D5 40 34 17 AB A4 7F 59 AE
m> 0B 0A A0 01 F1 28 07 58 23 FF 02 0E (309377)
0A 7F DB B5 60 14 F7 8B 44 DF 80
m> 0A 09 80 02 F1 28 07 58 23 FF 00 (309401)
0B 7C E8 C5 50 04 E7 9B 54 CF A9 BE
m> 0B 0A B0 01 F1 28 07 58 23 FF 02 0E (313359)
<- 0E7C
<- 0E 0A A0 10 58 23 FF F1 28 07 06 02 00 00 64 (313371)
0E 7D F9 C4 51 05 E6 9A 55 CE A8 85 A9 85 A0
m> 0E 0B A0 11 F1 28 07 58 23 FF 02 01 C8 00 00 (313553)
switchRly: 1, 200
0A 7C D8 B6 63 17 F4 88 47 DC 80
m> 0A 0A 80 02 F1 28 07 58 23 FF 00 (313573)
0E 7D E9 D4 41 35 16 AA A5 7E 58 35 D9 B5 B0
m> 0E 0B B0 11 F1 28 07 58 23 FF 02 01 C8 00 00 (315759)
<- 0E7D
<- 0E 0B 80 02 58 23 FF F1 28 07 01 01 C8 00 65 (315771)
0B 78 E4 C1 6C 60 3B 4F 08 1B F4 BE
m> 0B 0E B0 01 F1 28 07 58 23 FF 03 0E (407072)
<- 0E78
<- 0E 0E A0 10 58 23 FF F1 28 07 06 03 00 00 70 (407084)
<- 0E78
<- 0E 0E A0 10 58 23 FF F1 28 07 06 03 00 00 70 (407385)
<- 0E78
<- 0E 0E A0 10 58 23 FF F1 28 07 06 03 00 00 70 (407686)
timed out (407986)
0B 78 E4 C1 6C 60 3B 4F 08 1B F4 BE
m> 0B 0E B0 01 F1 28 07 58 23 FF 03 0E (409757)
<- 0E78
<- 0E 0E A0 10 58 23 FF F1 28 07 06 03 00 00 70 (409769)
<- 0E78
<- 0E 0E A0 10 58 23 FF F1 28 07 06 03 00 00 70 (410070)
<- 0E78
<- 0E 0E A0 10 58 23 FF F1 28 07 06 03 00 00 70 (410371)
timed out (410671)
0B 79 E5 C0 6D 61 3A 4E 09 1A F5 BE
m> 0B 0F B0 01 F1 28 07 58 23 FF 03 0E (484115)
<- 0E79
<- 0E 0F A0 10 58 23 FF F1 28 07 06 03 00 00 6F (484127)
<- 0E79
<- 0E 0F A0 10 58 23 FF F1 28 07 06 03 00 00 6F (484428)
<- 0E79
<- 0E 0F A0 10 58 23 FF F1 28 07 06 03 00 00 6F (484729)
timed out (485029)
switchRly: 1, 0
<- 0E79
<- 0E 0F A0 10 58 23 FF F1 28 07 06 01 00 00 6F (761128)
0A 79 D5 B3 7E 72 49 7D 7A A9 80
m> 0A 0F 80 02 F1 28 07 58 23 FF 00 (761298)
switchRly: 1, 200
<- 0E72
<- 0E 04 A0 10 58 23 FF F1 28 07 06 01 C8 00 69 (761936)
0A 72 CE A8 75 79 52 76 71 B2 80
m> 0A 04 80 02 F1 28 07 58 23 FF 00 (762107)
switchRly: 1, 0
<- 0E73
<- 0E 05 A0 10 58 23 FF F1 28 07 06 01 00 00 69 (762433)
0A 73 CF A9 74 78 53 77 70 B3 80
m> 0A 05 80 02 F1 28 07 58 23 FF 00 (762609)
switchRly: 1, 200
<- 0E70
<- 0E 06 A0 10 58 23 FF F1 28 07 06 01 C8 00 68 (764883)
0A 70 CC AA 77 7B 50 74 73 B0 80
m> 0A 06 80 02 F1 28 07 58 23 FF 00 (765058)
switchRly: 1, 0
<- 0E71
<- 0E 07 A0 10 58 23 FF F1 28 07 06 01 00 00 68 (772068)
0A 71 CD AB 76 7A 51 75 72 B1 80
m> 0A 07 80 02 F1 28 07 58 23 FF 00 (772239)
switchRly: 1, 200
<- 0E7E
<- 0E 08 A0 10 58 23 FF F1 28 07 06 01 C8 00 63 (774590)
0A 7E DA B4 61 15 F6 8A 45 DE 80
m> 0A 08 80 02 F1 28 07 58 23 FF 00 (774761)
0E 7F EB D6 43 37 14 A8 A7 7C 5A 37 13 EF B0
m> 0E 09 B0 11 F1 28 07 58 23 FF 02 01 00 00 00 (784804)
switchRly: 1, 0
<- 0E7F
<- 0E 09 80 02 58 23 FF F1 28 07 01 01 00 00 70 (784817)
switchRly: 1, 200
<- 0E7F
<- 0E 09 A0 10 58 23 FF F1 28 07 06 01 C8 00 70 (792716)
0A 7F DB B5 60 14 F7 8B 44 DF 80
m> 0A 09 80 02 F1 28 07 58 23 FF 00 (792892)
0E 7C E8 D5 40 34 17 AB A4 7F 59 34 10 EC B0
m> 0E 0A B0 11 F1 28 07 58 23 FF 02 01 00 00 00 (796578)
switchRly: 1, 0
<- 0E7C
<- 0E 0A 80 02 58 23 FF F1 28 07 01 01 00 00 6D (796591)
switchRly: 1, 200
<- 0E7C
<- 0E 0A A0 10 58 23 FF F1 28 07 06 01 C8 00 6D (799221)
<- 0E7C
<- 0E 0A A0 10 58 23 FF F1 28 07 06 01 C8 00 6D (799521)
<- 0E7C
<- 0E 0A A0 10 58 23 FF F1 28 07 06 01 C8 00 6D (799822)
timed out (800122)
switchRly: 1, 0
<- 0E7D
<- 0E 0B A0 10 58 23 FF F1 28 07 06 01 00 00 6D (807562)
<- 0E7D
<- 0E 0B A0 10 58 23 FF F1 28 07 06 01 00 00 6D (807862)
<- 0E7D
<- 0E 0B A0 10 58 23 FF F1 28 07 06 01 00 00 6D (808163)
timed out (808463)
switchRly: 1, 200
<- 0E7A
<- 0E 0C A0 10 58 23 FF F1 28 07 06 01 C8 00 6D (888104)
<- 0E7A
<- 0E 0C A0 10 58 23 FF F1 28 07 06 01 C8 00 6D (888404)
<- 0E7A
<- 0E 0C A0 10 58 23 FF F1 28 07 06 01 C8 00 6D (888705)
timed out (889005)
Hat jemand einen Tipp für mich?
Zitat von: MBHG am 24 Januar 2016, 15:28:26
Hi,
ich habe mir zwei Arduino Nanos geholt inkl. zwei echten 868 Funkmodulen. Pin 25 und 26 habe ich verbunden. HM_LC_SW4_BA_PCB auf den einen culf-520-trunk auf den anderen. Nach ein wenig hin und her hat das Pairing geklappt.
Manuelles Schalten der Zustände am HM_LC_SW4_BA_PCB inkl. korrekte Übertragung auf den CUL868 und FHEM klappt tadellos. Allerdings funktioniert die andere Richtung nur selten. Sprich schalten an FHEM resultiert in einen Schaltzustand am HM_LC_SW4_BA_PCB nur selten.
Wenn ich den CUL868 resette, sprich abziehe und wieder anstecke, dann funktioniert der erste Befehl eigentlich immer. Was auch immer funktioniert sind manuelle Schaltzustände an HM_LC_SW4_BA_PCB, die an den CUL868 übertragen werden.
Hat jemand einen Tipp für mich?
Wie hast Du denn den Sketch für den HM_LC_SW4_BA_PCB erzeugt?
Ich habe mich da ja auch nur eingelesen, deshalb kann ihc nur mit meinen begrenzten Erfahrungen helfen...
Aus dem Log seiht es so aus als ob auch das Senden des Status an FHEM von Deinem Device fast immer in einen Timeout läuft.
Ich habe jetzt die Schaltbefehle aus FHEM im Log noch nicht gesehen, so dass ich nicht erkennen kann, warum die nicht ankommen.
Hast Du mal das funktionierende Beispiel HM_LC_SW1_BA_PCB bei Dir mit diesen Funkmodulen zum Laufen bekommen?
Wenn das ebenfalls muckt, dann stimmt vielleicht doch etwas mit den Funkmodulen nicht?
Generell scheint er aber zu Senden und zu Empfangen (Sonst hätte ja auch das Pairing nicht geklappt)
Hi Viegener,
Das sw4 habe ich so erzeugt wie hier in dem Thread beschrieben. Beim Dimmer Beispiel habe ich dasselbe Verhalten. Ich habe die neueste a-culf Version 1.20.
Kurios ist, dass beim Pairen b0meistens der CUL868 abstürzt. Die Leds blinken dann unglaublich schnell und er ist nicht zu erreichen. Funkübertragung ist ordentlich RSSI bei -40.
Beide Arduinos sind neu und lassen sich auch sauber flashen. Beide Funkmodule auch. Das sieht nach einem Softwarefehler aus. Warum sollte immer der erste Befehl klappen und die anderen nicht?
Seltsam. Erinnert mich an
http://forum.fhem.de/index.php/topic,44578.msg364031.html#msg364031 (http://forum.fhem.de/index.php/topic,44578.msg364031.html#msg364031)
Dieselbe Library anderer Arduino, anderer cc1101, fast dasselbe Verhalten. Nur die Logfile Entries werden nicht 10000 fach gemacht.
Gruss
Zitat von: MBHG am 24 Januar 2016, 19:19:47
Hi Viegener,
Das sw4 habe ich so erzeugt wie hier in dem Thread beschrieben. Beim Dimmer Beispiel habe ich dasselbe Verhalten. Ich habe die neueste a-culf Version 1.20.
Kurios ist, dass beim Pairen b0meistens der CUL868 abstürzt. Die Leds blinken dann unglaublich schnell und er ist nicht zu erreichen. Funkübertragung ist ordentlich RSSI bei -40.
Beide Arduinos sind neu und lassen sich auch sauber flashen. Beide Funkmodule auch. Das sieht nach einem Softwarefehler aus. Warum sollte immer der erste Befehl klappen und die anderen nicht?
Seltsam.
Gruss
Das der erste Befehl klappt liegt häufig daran, dass der Homematic Device nicht aktiv auf eingehende Befehle wartet. Bei Sensoren z.B. ist häufig ein Modus vorhanden, dass sie zwar senden wenn etwas passiert aber Kommandos nur entgegennehmen, wenn der Prog-Button gedrückt ist. Die Erklärung wie hier im Forum beschrieben hilft da jetzt nicht wirklich weiter.
Deshalb meine Frage hat es mit dem Example-Sketch funktioniert?
Das der CUL schnell blinkt lässt darauf schliessen, dass der Watchdog (also die Überwachung ob der Arduino hängt) den Arduino neustartet. Bei Arduino-Nanos (aus China ?) führt das häufig dazu, dass diese nicht mehr Starten, das liegt wohl am Bootloader, aber das ist jetzt hier off-topic.
Achso: Der Dimmersketch ist nicht als Working markiert, ich habe ihn zwar bei mir zum Laufen bekommen, aber es gibt verschiedene Einschränkungen.
Hallo Viegener,
vielen Dank. Ich habe mal den SW1 Beispielsketch geladen und gepairt. Beim Pairing hängt sich der CUL868 auf, sprich fängt an zu blinken und bleibt in diesem Status. Kann über FHEM nicht erreicht werden. Beim 2. Pairingversuch hat sich FHEM dann auch aufgehängt musste mit /etc/init.d/fhem stop abgeschossen werden.
Und ganz kurios: setze ich den CUL nicht in Pairingmodus stürzt er mir auch nicht ab. Das Device wird aber angelegt. Das ist wiederholbar.
Hier die Logs mit dem CUL in Pairingmodus:
Log des SW1
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
....
CC.
12...................................3 - ready
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1938)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (241737)
<- 1A77
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (397559)
10 77 E3 BE 6B 6F 4C 70 6F B4 90 69 45 21 FD D9 B0
x> 10 01 B0 01 F1 28 07 58 23 FF 00 05 00 00 00 00 00 (473517)
<- 0A77
<- 0A 01 80 02 58 23 FF F1 28 07 00 (473526)
10 77 E3 BE 6B 6F 4C 70 6F B4 90 69 45 21 FD D9 B0
x> 10 01 B0 01 F1 28 07 58 23 FF 00 05 00 00 00 00 00 (475153)
<- 0A77
<- 0A 01 80 02 58 23 FF F1 28 07 00 (475162)
10 77 E3 BE 6B 6F 4C 70 6F B4 90 69 45 21 FD D9 B0
x> 10 01 B0 01 F1 28 07 58 23 FF 00 05 00 00 00 00 00 (475469)
<- 0A77
<- 0A 01 80 02 58 23 FF F1 28 07 00 (475478)
List von HM_5823FF
Internals:
DEF 5823FF
IODev CUL_1
NAME HM_5823FF
NR 98
NTFY_ORDER 50-HM_5823FF
STATE ???
TYPE CUL_HM
Readings:
2016-01-25 19:15:22 D-firmware 1.0
2016-01-25 19:15:22 D-serialNr XMS1234567
2016-01-25 19:15:22 R-pairCentral set_0xF12807
Helper:
HM_CMDNR 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +5823FF,00,00,00
prefIO
rxt 0
vccu
p:
5823FF
00
00
00
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev CUL_1
autoReadReg 4_reqStatus
expert 2_full
room CUL_HM
Dazu fällt mir leider erstmal auch nichts ein.
Interessant wäre es ob der CUL868 denn mit Original-Homematic-Devices funktioniert (auch im Pairing)?
Johannes
Hi,
gibt oder wird es ein Beispiel für den HM-LC-Sw1PBU-FM geben. Ich würde gerne die alternative Firmware austauschen. Mir geht es in erster Linie um AES, aber auch darum selbst das Verhalten ändern zu können. Z.B. möchte ich auf die Strommessung verzichten.
Gruss Frieder
@Johannes,
danke. Original HM Aktoren habe ich leider nicht, aber folgendes herausgefunden:
1. wenn ich den nanoCUL mit 9600 Baud setze, funktioniert das Pairing deutlich besser
2. ich komme sogar soweit, dass ich bei SW4 die einzelnen Schalter schalten kann, wobei irgendwann der nanoCUL insofern aussetzt, dass er keine Kommandos mehr sendet
3. bei 38400 Baud passiert Punkt 2 viel schneller
4. Punkt 2 läßt sich durch abziehen des nanoCUL und wieder anstecken beheben, im Falle von 38400 Baud nur für 2 - 3 Befehle, im Fall 9600 auch schon mal für 10 Befehle
5. vor dem r-paircentral bekomme ich das set_ nicht weg
switchRly: 4, 200
<- 0E5F
<- 0E 29 80 02 58 23 FF F1 28 07 01 04 C8 00 71 (570688)
0E 5A 86 73 BE B2 89 3D 3A E9 C7 A2 B6 92 B0
m> 0E 2C B0 11 F1 28 07 58 23 FF 02 01 C8 00 00 (669482)
switchRly: 1, 200
<- 0E5A
<- 0E 2C 80 02 58 23 FF F1 28 07 01 01 C8 00 6B (669496)
0E 5B 87 72 BF B3 88 3C 3B E8 C6 A0 B4 90 B0
m> 0E 2D B0 11 F1 28 07 58 23 FF 02 02 C8 00 00 (671884)
switchRly: 2, 200
<- 0E5B
<- 0E 2D 80 02 58 23 FF F1 28 07 01 02 C8 00 6A (671898)
0E 58 84 71 BC B0 8B 3F 38 EB C5 A2 B6 92 B0
m> 0E 2E B0 11 F1 28 07 58 23 FF 02 03 C8 00 00 (674315)
switchRly: 3, 200
<- 0E58
<- 0E 2E 80 02 58 23 FF F1 28 07 01 03 C8 00 6A (674329)
0E 59 85 70 BD B1 8A 3E 39 EA C4 A3 7F 5B B0
m> 0E 2F B0 11 F1 28 07 58 23 FF 02 03 00 00 00 (676266)
switchRly: 3, 0
<- 0E59
<- 0E 2F 80 02 58 23 FF F1 28 07 01 03 00 00 6A (676279)
0E 46 92 7F AA AE 8D 31 2E F5 D3 AD 89 65 B0
m> 0E 30 B0 11 F1 28 07 58 23 FF 02 02 00 00 00 (677851)
switchRly: 2, 0
<- 0E46
<- 0E 30 80 02 58 23 FF F1 28 07 01 02 00 00 6A (677864)
0E 47 93 7E AB AF 8C 30 2F F4 D2 AF 8B 67 B0
m> 0E 31 B0 11 F1 28 07 58 23 FF 02 01 00 00 00 (680037)
switchRly: 1, 0
<- 0E47
<- 0E 31 80 02 58 23 FF F1 28 07 01 01 00 00 6A (680050)
0E 44 90 7D A8 AC 8F 33 2C F7 D1 A9 85 61 B0
m> 0E 32 B0 11 F1 28 07 58 23 FF 02 04 00 00 00 (682313)
switchRly: 4, 0
<- 0E44
<- 0E 32 80 02 58 23 FF F1 28 07 01 04 00 00 6B (682326)
0E 45 91 7C A9 AD 8E 32 2D F6 D0 A8 4C 28 B0
m> 0E 33 B0 11 F1 28 07 58 23 FF 02 04 C8 00 00 (684121)
switchRly: 4, 200
<- 0E45
<- 0E 33 80 02 58 23 FF F1 28 07 01 04 C8 00 6A (684135)
Gruss Marc
@Marc: Ich denke all das was Du beschreibst klingt danach, dass es nicht (unbedingt) ein Softwareproblem ist. Vielleicht ist doch etwas bei Deinen Komponenten / Hardware defekt. Wenn die Arduinos aussetzen, würde ich mal versuchen, einen davon durch ein anderes Modell aus einer anderen Quelle zu erstzen. Ebenso das Funkmodul, wenn der Arduino nicht das Problem ist. Vielleicht gibt es auch ein Problem mit der Stromversorgung?
Wie gesagt alles eigentlich nur Spekulation, aber wenn es sowohl Probleme beim nanoCUL wie beim Asksin-Device gibt, dann würde ich die Teil einzeln versuchen auszutauschen, um das problem einzugrenzen/Teile auszuschliessen
Johannes
@Johannes
danke für Deinen Input. Systematisches Vorgehen ist immer gut, niemals mehr als eine Komponente ändern.
Ich bin an dem Thema seit Mitte November dran, mit 8 wöchiger Auszeit wg. Lieferdauer der Komponenten, alles in allem bestimmmt 100 Stunden. Ich hatte schon verschiedene Arduinos / CC1101 im Einsatz, unter anderem einen UNO und einen CC1101 (868/433) und aktuell einen Nano mit einem echten CC1101 868. Alle Komponenten haben eigentlich eines gemeinsam: beim Pairing stürzt der CUL ab, in einem Fall sogar FHEM
http://forum.fhem.de/index.php/topic,44578.msg364031.html#msg364031 (http://forum.fhem.de/index.php/topic,44578.msg364031.html#msg364031)
Als Software habe ich a-culfw wie culfw gestestet. Als Hardware habe ich einen Linux Recher und auf der Asksin / SW4 Seite einen Windows Rechner.
Ich muss mich nochmal daransetzen, wenn ich wieder Zeit habe....
Gruss Marc
@Marc: Ich verstehe den Frust, wenn man Stunden und Tage investiert und keinen Schritt einer Lösung näherkommt!
Wenn Du bei einem der Usertreffen in KA/FRA bist, könnte man mal versuchen Komponenten auszutauschen oder sogar lokal Tests mit anderen Komponenten zu machen.
@Johannes,
danke. Super Idee mit dem Usertreffen.
Hatte gestern ein wenig Zeit. Habe nochmals alle Verbindungen nachgelötet und alles geprüft. Das Verhalten des nanoCULs auf FHEM Seite ist eigentlich ziemlich simpel:
- Beim Pairen hängt sich der nanoCUL auf, sprich, schnelles Blinken der LED. Es hilft nur ausstecken und wieder einstecken. Es waren wohl noch ein paar Befehle in der Queue, da er nach dem Einstecken den Pairingversuch weiter fortgesetzt hat
- SW4 hat die Masterid akzeptiert und reagiert auch auf Schaltbefehle. Diese werden auch bestätigt und vom nanoCUL verarbeitet. Manchmal hängt sich der nanoCUL nach dem Schalten (!) aber auf (schnelles Blinken der LED), die Bestätigung kann er nicht mehr verarbeiten.
Bin fast versucht einen neuen Bootloader drauf zu setzen, behandelt aber aus meiner Sicht nur ein Symptom.
Gruss
Das schnelle Blinken spricht für watchdog oder brownout
Also neuer Bootloader löst vermutlich wirklich nicht das Problem, denn dann würde er vermutlich nur nach dem Reset wieder hochkommen...
Weisst Du zufällig wie die Fuses am Arduino für Unterspannung gesetzt sind?
Kann es sein, dass die Spannungsversorgung ein Problem macht (oder hatten wir das schon behandelt)?
Johannes
Hallo zusammen,
aus Zeitgründen hab ich mich die letzte Zeit etwas zurück gehalten.
Ich werde aber auch in Karlsruhe sein. Ggf. können wie uns dann etwas austauschen.
Viele Grüße
Dirk
Hi Johannes,
danke. Hatte in den letzten Tagen einiges zu tun. Spannungsversorgung vermutlich nicht, das hatten wir schon, ein anderer CUL 433 läuft an demselben USB Port seit Monaten ohne Probleme. Melde mich in 1 1/2 Wochen.
Gruss
Marc
Hallo,
beim Lesen des Threads ist mir die Frage nach der Verwendung eines analogen Eingangs aufgefallen, für die ich keine Antwort gefunden habe. Mich würde interessieren, ob jemand eine Lösung gefunden, bzw. etwas entwickelt hat, womit ein oder mehrere analoge Eingänge abgefragt werden können. Ich habe noch ein paar Panstamps ohne Aufgabe, die ich gerne im Gartenhaus zur Spannungsüberwachung des Solarpanels und des daran angeschlossenen Akkus verwenden würde. Auch habe ich daran gedacht, einen modifizierten HM-WDS30-OT2-SM Differenz-Temperatur-Sensor zu verwenden, aber die nicht lineare Kennlinie der Temperatursensoren machen die Umsetzung schwierig. Leider blicke ich nicht genug bei der Asksin lib durch um eine eigene Idee zu kreieren.
Grüße
Borney
Bei dem Beispiel zum HM_LC_SW4 einige Seiten vorher gab es noch ein Problem:
>>> /* Device Info 3 byte */ 0x41,0x04,0x00, // describes device, not completely clear yet. includes amount of channels
>>> -> ursprünglich 0x41, 0x01, 0x000 (vermute mal in der 0x01 steckt die Anzahl der Schaltkanäle
Richtigerweise muss es heisen:
/* Device Info 3 byte */ 0x44,0x01,0x00
Damit funktionieren nun alle 4 Schaltkanäle bei mir auf der CCU2
Hast jemand schon versucht, einen Bewegungsmelder mit der Asksin/NewAsksin zu realisieren? ::)
@Johannes,
ich hab mich mal wieder mit meinem SW4 und den NanoCUL 868 beschäftigt. Ich vermute einen (Hardware?) Fehler beim Senden von Befehlen des NanoCUL. Frage: wenn ich zB ein "on" an den SW4 per NanoCUL sende und der SW4 abgeschaltet ist, so daß er es nicht bestätigt, wie lange / wie oft wird dann der Befehl gesendet? Bei mir zeigt die LED mehrere Minuten lang an, dass Daten gesendet werden. Normal? Sollte das nicht in ein paar Sekunden geschehen sein?
Danke
ZitatDas der CUL schnell blinkt lässt darauf schliessen, dass der Watchdog (also die Überwachung ob der Arduino hängt) den Arduino neustartet. Bei Arduino-Nanos (aus China ?) führt das häufig dazu, dass diese nicht mehr Starten, das liegt wohl am Bootloader, aber das ist jetzt hier off-topic.
Optiboot ist nun erfolgreich drauf, er läuft stabil und stürzt nucht mehr ab.Daten werden tw immer noch nicht übermittel, ob es am Sender oder empfänger liegt bekomme ich auch noch raus.
@Johannes,
mit dem neuen Bootloader konnte ich den Pairingversuch komplett mitloggen, da der CUL auch nicht mehr abstürzt. Ich sehe folgendes im Event Log:
2016-04-02 09:03:23 CUL_HM HM_5823FF D-firmware: 1.0
2016-04-02 09:03:23 CUL_HM HM_5823FF D-serialNr: XMS1234567
2016-04-02 09:03:23 CUL_HM HM_5823FF CMDs_pending
2016-04-02 09:03:52 CUL CUL_1 UNKNOWNCODE ? (�Rs1001B001F128075823FF00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:03:53 CUL CUL_1 UNKNOWNCODE ? (050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:03:54 CUL CUL_1 UNKNOWNCODE ? (00050000000000 is unknown) Use one of B C
2016-04-02 09:03:58 CUL CUL_1 UNKNOWNCODE ? (���������Rs1001B001F128075823FF00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:03:59 CUL CUL_1 UNKNOWNCODE ? (00000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:06 CUL CUL_1 UNKNOWNCODE ? (�������Rs1001B001F128075823FF00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:12 CUL CUL_1 UNKNOWNCODE ? (01B001F128075823FF00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:24 CUL CUL_1 UNKNOWNCODE ? (��2�050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:24 CUL CUL_1 UNKNOWNCODE ? (00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:52 CUL CUL_1 UNKNOWNCODE ? (5823FF00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:52 CUL CUL_1 UNKNOWNCODE ? (75823FF00050000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
2016-04-02 09:04:52 CUL CUL_1 UNKNOWNCODE ? (50000000000 is unknown) Use one of B C F i A G M K U Y R T V W X e f L l t x
Mir sieht das so aus, als ob FHEM an den CUL ein Befehl sendet, den er nicht versteht. Deswegen kann der SW4 auch nichts empfangen.
Gruss
Hallo,
Zitat von: borney am 29 Februar 2016, 08:23:51
beim Lesen des Threads ist mir die Frage nach der Verwendung eines analogen Eingangs aufgefallen, für die ich keine Antwort gefunden habe. Mich würde interessieren, ob jemand eine Lösung gefunden, bzw. etwas entwickelt hat, womit ein oder mehrere analoge Eingänge abgefragt werden können.
Die Batteriespannung wird in der Lib über einen Analogeingang ausgelesen.
Zitataber die nicht lineare Kennlinie der Temperatursensoren machen die Umsetzung schwierig.
Inwiefern? Wie sieht die Kennlinie aus?
@MBHG, @Johannes
Weil wir grade beim Bootloader sind:
Walls ihr den AskSin-Bootloader mit der Lib einsetzen wollt, kann es sein dass der Sketch nach dem Bootloader beim Initialisieren des CC1101 hängen bleibt.
Dann einfach am Begin vom Setup der Codes folgendes einfügen:
EIMSK = 0; // disable external interrupts
ADCSRA = 0; // ADC off
power_all_disable(); // and everything else
DDRB = DDRC = DDRD = 0x00; // everything as input
PORTB = PORTC = PORTD = 0x00; // pullup's off
Da wird wohl beim Verlassen der des Bootloaders die Hardware nicht richtig initialisiert. Und dann bleibt der Sketch bei der SPI-Kommunikation hängen.
Gruß
Dirk
Zitat von: MBHG am 02 April 2016, 09:13:07
@Johannes,
mit dem neuen Bootloader konnte ich den Pairingversuch komplett mitloggen, da der CUL auch nicht mehr abstürzt. Ich sehe folgendes im Event Log:
Mir sieht das so aus, als ob FHEM an den CUL ein Befehl sendet, den er nicht versteht. Deswegen kann der SW4 auch nichts empfangen.
Da ist etwas in der Verbindung zwischen CUL und FHEM falsch. Die Steuerzeichen gehören da nicht hin und es sieht auch so aus als ob verstümmelt wird.
Ich kenne mich jetzt bei CUL_HM nicht aus, aber meines Wissens müssten die Kommandos doch eher mit As anstatt mit Rs beginnen (A für Asksin)?
Hallo,
habe ein Problem mit meiner Schaltung. Habe einen Arduino Mini Pro 3,3V 8Mhz und ein CC1101 868Mhz modul auf einer testplatine. Das Modul ist das angepriesene mit dem 2mm Raster. Sollte also Erfahrungsgemäß funzen. Habe auch die letzte unveränderte Version von Trilu (NewAsksin) HM_LC_SW1 auf den Arduino mit 1.6.5 kompiliert. Auch ohne Fehler. Weiter konnte ich den Anlernprozess durchführen. Allerdings habe ich versucht eine Direktverbindung zu einem HM-PB-2-FM (Wechselschalter) aufzubauen. Ohne Erfolg.
HAt jemand eine Idee.
Achso, habe schon mehrfach die Schaltung kontr. alles richtig angeschlossen. Auch habe ich einen neuen CC1101 benutzt, ebenfalls ohne erfolg.
Nachtrag: Allerdings konnte ich gerade im seriellen Monitor von Arduino 1.6.5 sehen, das trotz gescheiterter anmeldung, jedesmal beim drücken des Tasters ein paar mehr hyroglüphen zu sehen sind. Komisch ist das ich nur ASCII Zeichen sehe.
Habe jetzt die Baudrate auf 57600 gestellt. Jetzt sehe ich etwas......
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
b> 0D 00 84 10 33 6F 8B 00 00 00 06 00 00 00 (25949)
<- 1A 01 80 00 58 23 FF 00 00 00 10 00 6C 58 4D 53 31 32 33 34 35 36 37 00 41 01 00 (34377)
b> 1A 01 84 00 33 6F 8B 00 00 00 10 00 BF 4C 45 51 31 33 33 32 31 36 32 40 02 00 00 (37966) //hier aktiviere ich den Anlernprozess des Arduinos
b> 1A 02 84 00 33 6F 8B 00 00 00 10 00 BF 4C 45 51 31 33 33 32 31 36 32 40 02 01 02 (40886) //hier aktiviere ich das Anlernen des HM-Tasters
...Weiter scheint nix zu passieren.
Habe mal den Schaltplan angehängt...
Wäre echt super, wenn mir jemand helfen kann. Oder wird das Projekt bald eingestampft?
Hallo east,
wenn der Anlernvorgang (Annahme Du meinst Pairing mit FHEM) funktioniert hat, dann ist eigentlich sicher anzunehmen, dass die Verdrahtung soweit in Ordnung ist, da für den Anlernvorgang sowohl Senden als auch Empfangen benötigt wird.
Also erste Frage bist Du sicher, dass der Anlernvorgang funktioniert hat? Kannst Du aus FHEM heraus schalten?
Mit Anmeldung vermute ich ist ein direktes Peering zwischen Deinem Device und dem Schalter gemeint?
Wie führst Du denn die Anmeldung/Peering aus?
Also ich habe FHEM bis jetzt noch nicht ausgetestet (noch nicht gepairt). Das einzige was ich getestet habe und auch bracuhe, ist ein direktes Peering mit einem Wandtaster HM-PB-2-FM. Also ich setze den Arduino in den anlernprozess mit 3 sekunden langem drücken des Buttons, bis die rote und grüne LED an D4 und D6 langsam blinken.
Dann versetze ich den Wandtaster in den Anlernprozess. Dies tue ich durch kurzes drücken der Programmtaste. Die Blinkt dann Grün. Nun Taste ich einmal rauf oder Runter, jenachdem welchen Tastenhub ich benötige. Dann blinkt sie orange. Irgendwann gehen die LEDs am Arduino aus und die LED am Wandtaster leuchtet kurz Rot auf und erlischt.
Im Monitor kann man sehen, das während des Suchens nichts passiert.
Es kommt mir so vor, das der CC1101 nur empfängt und nicht sendet. Das sehe ich am Monitor. Da ich trotz fehlgeschlagener Prozedur durch einen Tastenhub einiges an Hex-Code am Monitor erscheint. Aber trotzdem juck es dem Arduino nicht und schaltet auch den Ausgang nicht.
Trotz etlicher kontrolle der Verbindungen glaube ich aber das es am CC1101 liegt. Habe schon einen neuen eingebaut mit gleichem Ergebnis.
Man sieht auch bei euren Auszügen des Seriellen Monitors, das da der CC1101 getestet wird, ob der Ready ist. Allerdings fehlt das bei mir.
Schon mal vielen Dank für die Hilfe.
Achso, habe dieses Modul hier gekauft.
http://www.ebay.de/itm/5PCS-CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115-New-/141876633160?hash=item2108819e48:g:EGoAAOSwo0JWIheC
Gruss,
Dennis
Sorry, dann ist mir unklar, was Du meinst, dass der Anlernvorgang funktioniert, ode rmeinst Du damit nur, dass Du den knopf drückst und dann die Leds rot und grün blinken???
Also wenn kein Pairing oder Peering geht, ist es schwerer festzustellen, was nicht funktioniert.
Ich würde immer erstmal versuchen das Modul mit fhem zu verwenden, da dann leichter einsehbar ist, ob etwas ankommt oder der Device überhaupt empfangen wird. Dann auch mit fhem pairen, da bei Erfolg mit Sicherheit senden und empfangen geht (oder vielleicht erkennbar ist, ob überhaupt etwas empfangen wird).
Wenn die Senderichtung nicht geht, ist das am ehesten über einen Empfänger wie FHEM zu erkennen, da man dort protokollieren kann, ob der Device empfangen wird (und was gesendet wird) oder nicht. Alternativ fällt mir ein, einen zweiten ASKSIN-Device zu bauen und dort zu sehen, ob etwas empfangen wird.
Die Hex-Daten aus dem Sende/Empfangsprotokoll kann ich nicht so einfach erklären, ich suche mir auch immer nur zusammen, was da drin steht, wenn ich eine spezielle Nachricht verstehen will.
Wenn die Initialisierung des cc1101-Moduls nicht läuft, dann müsstest Du da mehr Debug-Code einbauen und schauen, ob Fehlermeldungen kommen. Bei mir war das bisher nicht nötig.
Ne der Anlernvorgang funzt ja eben nicht. Ich meine nur der Prozess startet, mehr nicht.
OK, schonmal vielen Dank. Habe allerdings schon versucht, den CC1101-Debug einzuschalten, mit #define CC_DBG. Allerdings ohne erfolg.
Das dingen zeigt keinerlei Verbindung zum CC1101.
Achso, mal ne frage nebenbei.
Wie kann ich eigentlich mit Arduino 1.6.5, eine Header-Datei zb. CC1101.h editieren. Mir werden nur Register.h und hardware.h angezeigt.
Geht das überhaupt?
Zitat von: Spezialtrick am 21 März 2016, 22:20:29
Hast jemand schon versucht, einen Bewegungsmelder mit der Asksin/NewAsksin zu realisieren? ::)
Das hätte mich auch interessiert...
Hallo Zusammen,
irgendwie bekomme ich keine Benachrichtigungen mehr, wenn hier im Thread was geposted wrd.
Direktes peeren habe ich nie getestet mit der Lib, mein Weg war immer
Pairen mit Zentrale
Device auf Funktion testen
Peeren über die Zentrale (egal ob FHEM oder HM Config Soft)
Register einstellen (meist mit Config Soft)
Device combi testen
Viele Grüße
Horst
Hallo zusammen
hat schon jemand das Modul HM-MOD-RPI-PCB am Arduino angeschlossen und kann man das HM-MOD-RPI-PCB auch mit der Library ansprechen ?
LG
Stefan
Zitat von: Stefan M. am 25 April 2016, 11:34:25
hat schon jemand das Modul HM-MOD-RPI-PCB am Arduino angeschlossen und kann man das HM-MOD-RPI-PCB auch mit der Library ansprechen ?
Hi Stefan,
das wird nicht klappen, Kern der Lib ist ja das HM Protokoll nachzubilden. das Modul HM-MOD-RPI-PCB hat das Protokoll ja im Bauch und wird seriell angebunden.
Viele Grüße
Horst
Vielen Dank für die Antwort trilu,
habe eine Verbindung mit Raspberrymatic (CCU2) versucht. Leider findet er den Arduino nicht egal was ich mache.
Wäre denn eine direkte Verbindung mit der Asksin Libary theoretisch möglich? Was müsste man dafür ändern?
Kurios ist nur, das der Arduino innerhalb des seriellen Monitors kein Ready vom CC1101 anzeigt. Was er eigentlich machen müsste. Oder?
So habe es endlich geschafft.
1. Verbunden mit CCU2 (Rasperrymatic)
2. Direktverbindung mit Hilfe der Zentrale zu einem Wandtaster erfolgreich durchgeführt.
3. Direktverbindung funzt jetzt auch ohne Zentrale!!!!!
Der eigentliche Fehler war, das der Anlernprozess sehr zäh ist. Sprich das Anlernen konnte nur nach mehrmaligen Versuchen hergestellt werden.
Das mit dem CC1101-Check im seriellen Monitor ist trotzdem nicht zu sehen. Warum werde ich noch herausfinden. Das hatte mich auf eine falsche Ferte gelockt. Komischerweise konnte ich allerdings den CC_DBG auch nicht erfolgreich einschalten.....
Aber mein Vorhaben funktioniert.
Vielen Dank an Trilu für die LIB.
Werde jetzt erstmal auf dieser Basis experimentieren und weiter meine Erkenntnisse hier niederschreiben.
Endlich ein Erfolg..... Siehe oben ;D
So bin jetzt etwas am Basteln. Hätte eine Frage bzgl. der "initRly-Funktion".
Wie habt ihr das mit dem aufruf der Channels gelöst, um 3 weitere Kanäle zu programmieren?
Habe eine if-abfrage der variablen "channel" programmiert, um die Kanäle den Ausgängen zu zuordnen.
Aber irgendwie bleibt der Arduino hängen, so das der Button nicht funzt.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
initRly: 2
initRly: 3
initRly: 4
....
CC.
12.................3 - ready
SN.
RV.
HMID: 60 25 FF, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 60 25 FF 00 00 00 06 01 00 00 00 (1139)
und hier die Abfrage ....
void initRly(uint8_t channel) {
// setting the relay pin as output, could be done also by pinMode(3, OUTPUT)
#ifdef SER_DBG
dbg << F("initRly: ") << channel << "\n";
#endif
if (channel = 1){
pinOutput(DDRD,3); // init the relay pins
setPinLow(PORTD,3); // set relay pin to ground
}
if (channel = 2){
pinOutput(DDRD,5); // init the relay pins
setPinLow(PORTD,5); // set relay pin to ground
}
if (channel = 3){
pinOutput(DDRD,7); // init the relay pins
setPinLow(PORTD,7); // set relay pin to ground
}
if (channel = 4){
pinOutput(DDRB,1); // init the relay pins
setPinLow(PORTB,1); // set relay pin to ground
}
Hallo zusammen
hab ich evtl. überlesen. Geht die Library auch auf dem Uno oder Leonardo und hat jemand eine Anschalte Bild der TRX868 Module.
LG
Stefan
So, Dank Jochen222 habe ich den HM_LC_SW4 ans laufen bekommen. Vielen Dank nochmal für die Hilfe.
Mit der If- Anweisung in der Zuordnung der Ausgänge war schon richtig. Das einzige was ich übersah, war die Kanaldeklaration für HM (const uint8_t devIdnt[] PROGMEM = 0x41,0x01,0x00, ) hatte anstelle der 0x01 eine 0x00 drinne. Daher hatte der Arduino die Zuordnungen nicht gesetzt.
Vielen Dank @ Jochen222.
Habe jetzt allerdings eine neue Frage. In den Examples sind alle samt nur Aktoren zu finden bzw. Cmswitch, Cmblind, CmDimmer. Allerdings würde ich gerne eine Funktion erstellen, um eine Art Wandsender zu realisieren. Wie stelle ich dies ohne eine Funktion zu haben an?
Kann mir da einer unter die Arme greifen?
Hallo,
mal so am Rande - könnte man nicht eine Seite machen, auf der die lauffähigen Sketche der Allgemeinheit zur Verfügung gestellt werden ? Dann können die weniger geübten (wie ich 😉) sich vielleicht auch mal eigene Geräte bauen. Oder gibt es das schon ?
Gruß Christoph
Zitat von: east am 02 Mai 2016, 12:26:41
Habe jetzt allerdings eine neue Frage. In den Examples sind alle samt nur Aktoren zu finden bzw. Cmswitch, Cmblind, CmDimmer. Allerdings würde ich gerne eine Funktion erstellen, um eine Art Wandsender zu realisieren. Wie stelle ich dies ohne eine Funktion zu haben an?
Was meinst Du mit Wandsender? Einen Sensor?
Einen Schalter müßtest Du ja mit cmSwitch realisieren können.
Einen Sensor mit der NewAskSin zu bauen - geht, ist aber noch ein Stück Arbeit, da manche Funktionen hierfür noch unfertig sind.
Ich habe mir selber einen TH-Sensor gebaut (mit der NewAskSin) - der läuft jetzt stabil gepeert mit einem RT-DN (nach einigen Anfangsproblemen). Jetzt kommen noch ein paar Einstellmöglichkeiten hinzu...
Martin
Hallo Linef,
nein meine keinen Sensor. Sondern möchte das Gegenstück zu einem Aktor. Also möchte einen Schalter der vom Arduino verarbeitet wird und dann einem entfernten Aktor damit schalten. Nicht mehr und nicht weniger. Bei den HM-Modulen nennt sich der Aktor Empfänger und der Wandtaster zb. Sender. Und ich meine jetzt nicht das der CC1101 beides als TRansceiver beherrscht. Sondern lediglich die Funktion als solches.
Also Aktoren haben wir zu genüge (CmBlind,CmDimmer und CmSwitch). Aber sehe nirgends eine Funktion die einen Taster am Arduino einen entfernten Aktor schalten lässt. Oder ich hab es nur noch nicht gecheckt. Das ist ja auch möglich.
Zitat von: ranseyer am 24 April 2016, 18:47:36
Das hätte mich auch interessiert...
Liegt als "Projektplan hier" dauert wohl aber noch etwas.
Zitat von: Stefan M. am 01 Mai 2016, 14:52:26
hab ich evtl. überlesen. Geht die Library auch auf dem Uno oder Leonardo und hat jemand eine Anschalte Bild der TRX868 Module.
Das sollte gehen. Ggf. braucht es noch ein paar Anpassungen an den Pin- / Registerzuordnungen.
Hier gibt es eine Anschlusssbelegung:
http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library
Zitat von: Linef am 02 Mai 2016, 20:55:56
Ich habe mir selber einen TH-Sensor gebaut (mit der NewAskSin) - der läuft jetzt stabil gepeert mit einem RT-DN (nach einigen Anfangsproblemen).
An was lag es denn im Endeffekt? Oder hast du jetzt doch einen 32 kHz angeschlossen?
Zitat von: east am 03 Mai 2016, 01:35:51
Also möchte einen Schalter der vom Arduino verarbeitet wird und dann einem entfernten Aktor damit schalten.
Hier ist die FW für meinen 1-6-Fach Taster:
https://forum.fhem.de/index.php/topic,19657.0.html und
https://github.com/kc-GitHub/1-6Fach-Taster
Ist zwar noch auf Basis der alten Lib, aber vielleicht hilft die das schon mal.
Ein Upgrade auf die neue Lib steht aber such an. Vor allem auch wegen AES.
Viele Grüße
Dirk
Hallo
ich hätte noch ein paar kleine Patches zur NewAskSin Library beizusteuern. Wie ist dann da das Vorgehen ?
Zitat von: papa am 03 Mai 2016, 08:55:28
ich hätte noch ein paar kleine Patches zur NewAskSin Library beizusteuern. Wie ist dann da das Vorgehen ?
Entweder direkt per Github einen Pullrequest stellen oder zur Not auch ein Patchfile hier reinstellen.
Viele Grüße
Dirk
Hallo Dirk,
Zitat von: Dirk am 03 Mai 2016, 07:48:01
An was lag es denn im Endeffekt? Oder hast du jetzt doch einen 32 kHz angeschlossen?
Im Endeffekt war es der sehr ungenaue Watchdog-Timer des Atmel. Ich mußte hier die Werte um 7,5% anheben.
Durch diese Ungenauigkeit lag der Sendeversuch ca. 10-15 Sek. hinter dem Soll. Und wenn der RT nur 10 Sekunden "hört", dann klappt das eben nicht.
Meine Patche für die NewAskSin, die mittlerweile angefallen sind, liegen hier im "fixes"-Branch - aber ein Pull-Request steht ja eh schon länger offen...
https://github.com/LineF/NewAskSin.git
Viele Grüße,
Martin
Dann würde ich erstmal warten, bis Martins Änderungen drin sind, damit hier keine unnötiges Chaos entsteht. Zumindest der Fix für CONFIG_WRITE_INDEX ist bei Martin auch schon drin.
Hab ich gestern in DevAES gemerged.
Ok - dann gehe ich auch erst mal auf den DevAES
Zitat von: Linef am 02 Mai 2016, 20:55:56
Was meinst Du mit Wandsender? Einen Sensor?
Einen Schalter müßtest Du ja mit cmSwitch realisieren können.
Einen Sensor mit der NewAskSin zu bauen - geht, ist aber noch ein Stück Arbeit, da manche Funktionen hierfür noch unfertig sind.
Ich habe mir selber einen TH-Sensor gebaut (mit der NewAskSin) - der läuft jetzt stabil gepeert mit einem RT-DN (nach einigen Anfangsproblemen). Jetzt kommen noch ein paar Einstellmöglichkeiten hinzu...
Martin
Hallo Linef,
TH = Temperature Humidity sensor? Welchen Sensor verwendest du, DHT11/22 oder SHT10? Hast du einen Sketch den du teilen könntest?
Danke dir!
Zitat von: kadettilac89 am 05 Mai 2016, 21:03:08
TH = Temperature Humidity sensor? Welchen Sensor verwendest du, DHT11/22 oder SHT10? Hast du einen Sketch den du teilen könntest?
Hallo kadettilac89,
Als Sensor verwende ich den DHT22 (AM2302) und einen DS18B20 (habe nur aus Interesse beide drauf gebaut - um zu sehen, wie verschieden sie messen). Alternativ kann aber auch ein SHT10 drauf gebaut werden - war mir aber zu teuer (und scheint auch schwer zu beschaffen).
Als SW verwende ich derzeit die NewAskSin, die ich hierzu teilweise noch anpassen musste (und auch noch dran bin).
Das Auslesen der Sensoren erfolgt asynchron - die Messung ist damit unabhängig vom "Senden".
Die Quellen stehen unter https://github.com/LineF/NewAskSin.git im Branch dev zur Verfügung. Das Hauptmodul des Sensors (mit Schaltplan - ist aber ziemlich identisch zum Universalsensor) liegt unter https://github.com/LineF/HM-Sensor.git, ebenfalls im Branch dev.
Ein Sketch ist es nicht, da ich mit dem Atmel Studio entwickle, aber sollte in der Arduino IDE (nach Rename von main.cpp) auch übersetzbar sein.
Viele Grüße,
Martin
@kadettilac89,
du kannst dir den Quellcode vom Universalsensor anschauen. Da hättest du dann einen lauffähigen Sketch. Allerdings noch mit der alten AskSin-Lib. Die Portierung auf die neu Lib steht noch aus.
https://github.com/kc-GitHub/Wettersensor
Als Sensor kommt dort aktuell ein SHT1x zum Einsatz.
Gruß
Dirk
Zitat von: Linef am 06 Mai 2016, 01:13:26
Als Sensor verwende ich den DHT22 (AM2302) und einen DS18B20 (habe nur aus Interesse beide drauf gebaut - um zu sehen, wie verschieden sie messen).
Hört sich gut an, ich habe DHT22 rumliegen. Liefern die beiden Sensoren unterschiedliche Temperaturen?
Zitat von: Linef am 06 Mai 2016, 01:13:26
Die Quellen stehen unter https://github.com/LineF/NewAskSin.git im Branch dev zur Verfügung. Das Hauptmodul des Sensors (mit Schaltplan - ist aber ziemlich identisch zum Universalsensor) liegt unter https://github.com/LineF/HM-Sensor.git, ebenfalls im Branch dev.
Wenn ich das richtig sehe muss der DHT22 nur an Pin10 (je nach config) angeschlossen werden. Spannung mal außen vor. Was bedeutet das Symbol im Schaltplan SJ1 das an VCC vom DHT an 3v und D9 verzweigt? Ist der Pullup-Widerstand zwischen VCC und Data nicht mehr nötig?
Zitat von: Linef am 06 Mai 2016, 01:13:26
Ein Sketch ist es nicht, da ich mit dem Atmel Studio entwickle, aber sollte in der Arduino IDE (nach Rename von main.cpp) auch übersetzbar sein.
Nachdem ich noch hmkey.h aus einem anderen exaple kopiert habe wird schon mal kein fehlendes include angemeckert. Aber das hab ich nicht mehr näher angeschaut. Ggf. kann ich mich auch mal mit Atmel Studio beschäftigen.
Du hast deine Schaltung anscheinend als Platine umgesetzt. Sollte der Code auf jedem Arduino laufen, oder kennst du Einschränkungen? Nur 16 mhz? Nur 5v Version? Nur atmega328?
Danke für die DAteien. Werde mich näher damit befassen wenn mein CC1101 da ist. Wenn das alles funktioniert könnte man für unter 10 Euro einen HM-HT sensor bauen.
Zitat von: Dirk am 06 Mai 2016, 10:21:32
du kannst dir den Quellcode vom Universalsensor anschauen. Da hättest du dann einen lauffähigen Sketch. Allerdings noch mit der alten AskSin-Lib. Die Portierung auf die neu Lib steht noch aus.
https://github.com/kc-GitHub/Wettersensor
DAnke, über die Source bin ich schon gestolpert.
Ich hab mir das schon mal angesehen, aber ich bekomme Asksin1 nicht kompiliert ... wenn ich den Universalsensor prüfe bekomme ich folgende Fehler ... s. u. . Weißt du zufällig welche Version der IDE verwendet werden kann? 1.6.5, 1.6.8 funktioniert nicht. Oder liegt es am eingestellten Board. Habe Nano und Pro versucht. Wenn ich es richtig lese fehlen Defines für z. B. SERIAL_DBG_PHEX_MODE_LF. Ich denke es fehlt ein include. Aber per Textsuche in Files habe ich keine Datei gefunden die "SERIAL_DBG_PHEX_MODE_LF" enthält.
--- Zeile 48, este Meldung: Serial << F("Device type from Bootloader: "); pHex(&devParam[1], 2, SERIAL_DBG_PHEX_MODE_LF);
Arduino: 1.6.5 (Windows 8.1), Platine: "Arduino Pro or Pro Mini, ATmega328 (3.3V, 8 MHz)"
Build-Optionen wurden verändert, alles wird neu gebaut
WetterSensor.ino: In function 'void setup()':
WetterSensor:48: error: 'SERIAL_DBG_PHEX_MODE_LF' was not declared in this scope
WetterSensor.ino: In function 'void cmdReset(uint8_t*, uint8_t)':
WetterSensor:115: error: 'SERIAL_DBG_PHEX_MODE_LF' was not declared in this scope
WetterSensor.ino: In function 'void cmdConfigChanged(uint8_t*, uint8_t)':
WetterSensor:133: error: 'class HM' has no member named 'setLedMode'
WetterSensor:133: error: 'LED_MODE_EVERYTIME' was not declared in this scope
WetterSensor:133: error: 'LED_MODE_CONFIG' was not declared in this scope
WetterSensor:137: error: 'POWER_MODE_BURST' was not declared in this scope
WetterSensor:137: error: 'POWER_MODE_SLEEP_WDT' was not declared in this scope
WetterSensor:150: error: 'class Sensors_SHT10_BMP085_TSL2561' has no member named 'setAltitude'
WetterSensor:153: error: 'SERIAL_DBG_PHEX_MODE_LEN' was not declared in this scope
WetterSensor:153: error: 'SERIAL_DBG_PHEX_MODE_LF' was not declared in this scope
WetterSensor.ino: In function 'void cmdStatusRequest(uint8_t*, uint8_t)':
WetterSensor:163: error: 'SERIAL_DBG_PHEX_MODE_LF' was not declared in this scope
WetterSensor.ino: In function 'void HM_Remote_Event(uint8_t*, uint8_t)':
WetterSensor:168: error: 'SERIAL_DBG_PHEX_MODE_LF' was not declared in this scope
'SERIAL_DBG_PHEX_MODE_LF' was not declared in this scope
Zitat von: kadettilac89 am 06 Mai 2016, 11:32:09
Hört sich gut an, ich habe DHT22 rumliegen. Liefern die beiden Sensoren unterschiedliche Temperaturen?
Leicht unterschiedlich. Differenz zwischen 0.1°C und 0.4°C - wobei der DHT immer höher liegt (auch bereits mit anderen Sensoren getestet - auch da war der DHT höher als der DS18B20).
Zitat von: kadettilac89
Wenn ich das richtig sehe muss der DHT22 nur an Pin10 (je nach config) angeschlossen werden. Spannung mal außen vor. Was bedeutet das Symbol im Schaltplan SJ1 das an VCC vom DHT an 3v und D9 verzweigt? Ist der Pullup-Widerstand zwischen VCC und Data nicht mehr nötig?
Laut Datenblatt ist kein Pull-up nötig. Könnte aber mit internem Pull-up vom Atmel realisiert werden.
SJ1 ist ein Lötjumper. Damit kann man die Sensoren optional über einen Atmel-Pin mit Spannung versorgen.
Da der DHT erst ab 3,3V spezifiziert ist, die Schaltung mit 3,3V läuft, aber durch den Atmel noch ein bestimmter Spannungsverlust für die geschaltete Spannungsversorgung hinzu kommt, drum hatte ich die Versorgung wählbar gemacht. Funktioniert aber mit Spannung über Atmel geschaltet. Damit brauchen die Sensoren nur bei der Messung Strom.
Zitat von: kadettilac89
Du hast deine Schaltung anscheinend als Platine umgesetzt. Sollte der Code auf jedem Arduino laufen, oder kennst du Einschränkungen? Nur 16 mhz? Nur 5v Version? Nur atmega328?
Die AS-Lib hat Unterscheidungen bzgl. verschiedener Prozessortypen drin.
Auch HAL.h, HAL.cpp und HAL_extern.h haben prozessorspezifische Register drin. Ich bin mir ziemlich sicher, daß der Code nur auf ein paar Prozessortypen läuft.
Viele Grüße,
Martin
Danke Martin, hast du Langzeiterfahrung mit dem Sensor bezüglich Batteriekonsum? Lässt du mit 2 AA-Batterien laufen?
Nein, keine Langzeiterfahrung. Der Sensor kommt jetzt erst allmählich zum Laufen.
Ich hatte lange Zeit Probleme mit der Synchronisation beim Peering mit einem RT-DN.
Läuft immer mal wieder ein paar Tage mit zwei alten AA-Akkus. Einen von denen hatte er schon mal bis auf 0V leergesaugt. Da waren nur noch die 1.2V des anderen Akkus da - und die Schaltung lief noch. Aber der Akku dann endgültig hinüber ::)
Zitat von: kadettilac89 am 06 Mai 2016, 11:32:09
Ich hab mir das schon mal angesehen, aber ich bekomme Asksin1 nicht kompiliert ... wenn ich den Universalsensor prüfe bekomme ich folgende Fehler ... s. u. . Weißt du zufällig welche Version der IDE verwendet werden kann?
Ich habe hier Eclipse mit der Ardunio-Erweiterung am Start. Hab hier noch eine "alte" Arduino-IDE liegen 1.6. Damit kompilierte es.
ZitatWenn ich es richtig lese fehlen Defines für z. B. SERIAL_DBG_PHEX_MODE_LF. Ich denke es fehlt ein include. Aber per Textsuche in Files habe ich keine Datei gefunden die "SERIAL_DBG_PHEX_MODE_LF" enthält.
SERIAL_DBG_PHEX_MODE_LF wird in "AskSin/utility/Serial.h". Das wiederum wird unter anderem von AskSinMain.h eingebunden.
Schau mal ob in "AskSinMain.h"
#define AS_DBG
einkommentiert ist
Zitat von: kadettilac89 am 07 Mai 2016, 16:32:04
hast du Langzeiterfahrung mit dem Sensor bezüglich Batteriekonsum? Lässt du mit 2 AA-Batterien laufen?
Ich kann hier nur für den "Universalsensor" und die dazugehörige Sensorbestückung sprechen.
Mit 2 AAA-Zellen lag die Laufzeit bei bisher > 8 Monaten. Da die Kapazität von AA-Zellen mindestens doppelt so groß ist, gehe ich hier von einer mindestens doppelt so langen Laufzeit aus. Alle Sensoren mit AA-Zellen laufen bei mir aber noch.
Gruß
Dirk
Zitat von: Dirk am 09 Mai 2016, 10:04:34
Ich habe hier Eclipse mit der Ardunio-Erweiterung am Start. Hab hier noch eine "alte" Arduino-IDE liegen 1.6. Damit kompilierte es.
SERIAL_DBG_PHEX_MODE_LF wird in "AskSin/utility/Serial.h". Das wiederum wird unter anderem von AskSinMain.h eingebunden.
Schau mal ob in "AskSinMain.h"
#define AS_DBG
einkommentiert ist
Ich kann hier nur für den "Universalsensor" und die dazugehörige Sensorbestückung sprechen.
Mit 2 AAA-Zellen lag die Laufzeit bei bisher > 8 Monaten. Da die Kapazität von AA-Zellen mindestens doppelt so groß ist, gehe ich hier von einer mindestens doppelt so langen Laufzeit aus. Alle Sensoren mit AA-Zellen laufen bei mir aber noch.
Gruß
Dirk
Danke
8 Monate hört sich gut an.
Ich habe es mit einer 1.6.5 und 1.6.8 IDE versucht ... Asksin von Github master, AS_DBG war aktiv. Werde mich damit näher befassen wenn die Teile da sind. Vielleicht liegt es daran, dass ich die IDE nur als Zip verwende. Scheinbar vergisst die sporadisch wo die Libs zu suchen sind.
Zitat von: Dirk am 09 Mai 2016, 10:04:34
SERIAL_DBG_PHEX_MODE_LF wird in "AskSin/utility/Serial.h". Das wiederum wird unter anderem von AskSinMain.h eingebunden.
Schau mal ob in "AskSinMain.h"
#define AS_DBG
einkommentiert ist
Ich hab gefunden warum es zu den Fehlern kam. Auf Github gibt es die Source für den Wettersensor den du gepostet hast. Da beim downloaden der Askin-Ordner leer war, habe ich mir Asksin von trilu2000 runtergeladen. Hier gibt es die von mir geposteten defines aber nicht (z.B. SERIAL_DBG_PHEX_MODE_LF). Im Wettersensor-Github gibt es aber einen Link auf einen Asksin-fork von kc. Hier sind die nötigen definces enthalten. Kaum sind die richtigen (neueren) Dateien enthalten kann ich die Firmware baun. Jetzt muss ich nur noch den SHT11 gegen den DHT22 austauschen und es sollte laufen.
Zitat von: kadettilac89 am 09 Mai 2016, 13:04:12
8 Monate hört sich gut an.
Aber wie gesagt mit AAA-Zellen. Mit AA, also R6 dann deutlich länger.
Zitat von: kadettilac89 am 09 Mai 2016, 20:42:52
Da beim downloaden der Askin-Ordner leer war, habe ich mir Asksin von trilu2000 runtergeladen. Hier gibt es die von mir geposteten defines aber nicht (z.B. SERIAL_DBG_PHEX_MODE_LF). Im Wettersensor-Github gibt es aber einen Link auf einen Asksin-fork von kc.
Ja, stimmt, das ist ein Subrepo auf einen Fork der alte AskSin-Lib. Diese musst du auch unbedingt verwenden. Da hatte ich noch einiges gefixt und optimiert.
Gruß
Dirk
Hallo,
ich habe ein Problem mit dem devAES Branch. Der Switch schaltet nicht mehr ordentlich an. Es sieht so aus, als würde irgendwas mit der Kommunikation schief gehen. Das Relais geht zwar an, aber der Status wird nicht korrekt zurück gemeldet.
m> 0E 1D A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (67754)
<- 0E 1D 80 02 0A 03 01 63 90 87 01 01 00 00 52 (67760)
switchRly: 1, 200
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (68055)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 52 (68061)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 52 (68070)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (68255)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (68260)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (68270)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (68454)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (68460)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (68470)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (72101)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 52 (72107)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 52 (72116)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (72301)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (72306)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (72316)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (72500)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (72506)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (72516)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (76319)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (76324)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (76334)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (76518)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (76524)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (76534)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (76718)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (76724)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (76734)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (82134)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 52 (82140)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 52 (82150)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (82334)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 51 (82340)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 51 (82349)
m> 0E 1E A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (82533)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 00 00 52 (82539)
<- 0E 1E 80 02 0A 03 01 63 90 87 01 01 C8 00 52 (82549)
Ausschalten geht komischerweise.
m> 0E 20 A0 11 63 90 87 0A 03 01 02 01 00 00 00 (197297)
<- 0E 20 80 02 0A 03 01 63 90 87 01 01 00 00 4F (197303)
switchRly: 1, 0
Beim peeren (dual) mit einem Taster wird der Aus-Schalter auch nicht richtig angelegt. Es werden hier auch die Settings für "An" in die Liste gespeichert.
Hallo papa,
eigentlich sieht das Log ok aus.
m> 0E 1D A0 11 63 90 87 0A 03 01 02 01 C8 00 00 (67754)
Das ist SET
und das
<- 0E 1D 80 02 0A 03 01 63 90 87 01 01 00 00 52 (67760)
ACK_STATUS
Bekommt der Master das Ack denn mit?
Ich schau mir den Codem mal nach dem Wochenende an.
Viele Grüße
Dirk
Hallo Dirk,
ja - aber wie es aussieht mit dem noch alten Status 00. Das kriegt FHEM und schickt wieder das SET mit C8. Es wird scheinbar ein falscher (zu früher) Status gesendet. Ich hatte da einfach mal den waitTimer gesetzt, dann ging es für AN aber nicht mehr für AUS. Es muss sich irgendwas im Messagehandling geändert haben, was hier komische Seiteneffekte hat. Vielleicht muss auch einfach nur der Switch-Code angepasst werden, erst den Status zu senden, wenn auch das SET komplett ausgeführt ist.
Hallo Dirk,
hattest Du schon Zeit da mal draufzusehen ?
Zitat von: Linef am 06 Mai 2016, 01:13:26
Als SW verwende ich derzeit die NewAskSin, die ich hierzu teilweise noch anpassen musste (und auch noch dran bin).
Das Auslesen der Sensoren erfolgt asynchron - die Messung ist damit unabhängig vom "Senden".
Die Quellen stehen unter https://github.com/LineF/NewAskSin.git im Branch dev zur Verfügung. Das Hauptmodul des Sensors (mit Schaltplan - ist aber ziemlich identisch zum Universalsensor) liegt unter https://github.com/LineF/HM-Sensor.git, ebenfalls im Branch dev.
Hallo Martin,
ich habe versucht das Projekt in atmelStudio zu bauen. Leider bekomme ich Fehler. Ich habe auf Github deine Anleitung gesehen. Danach habe ich auch gearbeitet. Ich hänge meine Screenshots und Fehler als Word an. Könntest du mal schaun ob du einen Fehler in meinem Vorgehen siehst?
Oder kannst du mir deinen kompletten Ordner komprimieren und irgendwo hochladen? Incl. Projektdatei *.atsln? Ich könnte dann selber prüfen wo es Unterschiede gibt. Ich brächte auch die Lib-Ordner die bei dir über Sym-Link eingebunden sind aber wo anders liegen.
Ich habe die Files aus Github heute runtergeladen, kann es sein, dass Files aktuell von dir bearbeitet wurden und noch unvollständig sind?
Danke!
Hast du den dev-Branch benutzt? Ich musste bei mir auch noch pcint.* löschen, dann geht es.
Gesendet mobil
Zitat von: Tom71 am 21 Mai 2016, 22:45:26
Hast du den dev-Branch benutzt? Ich musste bei mir auch noch pcint.* löschen, dann geht es.
Ich habe dev und branch versucht. Ich gehe davon aus dass dev funktionieren sollte. Bei mir kommen beim Build Fehler. Das komplette Log hab ich angehängt.
Da ist eine Menge Text, ich sehe diese Meldungen und hier scheint irgend etwas nicht zu passen. Die Datei ist im Ordner sonst würde der Include-Befehl schon abbrechen.
... ca. Zeile 1000 --
D:\Users\user\Documents\Atmel Studio\7.0\_libs\newasksin\HAL.h(43,18): warning: 'wdtSleep_TIME' defined but not used [-Wunused-variable]
static uint16_t wdtSleep_TIME;
^
make: *** No rule to make target 'onewire.o', needed by 'HM33.elf'. Stop.
make: *** Waiting for unfinished jobs....
... ganz unten dann
Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "HM33.cppproj" -- FAILED.
Done building project "HM33.cppproj" -- FAILED.
Irgend eine Idee? Hast du nur die Dateien kopiert, oder musstest du noch andere Files kopieren oder editieren?
Zitat von: kadettilac89 am 22 Mai 2016, 08:23:20
Ich habe dev und branch versucht. Ich gehe davon aus dass dev funktionieren sollte. Bei mir kommen beim Build Fehler. Das komplette Log hab ich angehängt.
Da ist eine Menge Text, ich sehe diese Meldungen und hier scheint irgend etwas nicht zu passen. Die Datei ist im Ordner sonst würde der Include-Befehl schon abbrechen.
Update, ich habe Atmel Studio in einer VM installiert. Selbe Files, selbe Struktur aber es kompiliert. Sehe keinen Unterschied aber es kompiliert. Werde in der VM-Ware weiterarbeiten.
Hallo zusammen
hat jemand ein lauffähiges Testprogramm für AsksinNew und Homematic ?
Alle die ich bis jetzt versucht habe haben nicht funktioniert.
Wie kann ich die Funktion des Funkmodules prüfen ? (Funkmodul aus HomeMatic HM-LC-Sw1-Ba-PCB). Gibt es eine Schritt für Schritt Anleitung für die Kommunikation mit FHEM (HM).
Wiki kenn ich schon.
http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library
LG
Stefan
Zitat von: Stefan M. am 29 Mai 2016, 14:22:30
Hallo zusammen
hat jemand ein lauffähiges Testprogramm für AsksinNew und Homematic ?
Alle die ich bis jetzt versucht habe haben nicht funktioniert.
Wie kann ich die Funktion des Funkmodules prüfen ? (Funkmodul aus HomeMatic HM-LC-Sw1-Ba-PCB). Gibt es eine Schritt für Schritt Anleitung für die Kommunikation mit FHEM (HM).
Wiki kenn ich schon.
http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library
LG
Stefan
Was bedeutet "haben nicht funktioniert"? Fehler beim Kompilieren, beim Aufspielen? Pairing nicht möglich? Stelle die Logs des seriellen Monitors rein. Bevor du nach Anleitungen fragst wäre es erstmal sinnvoll zu schreiben was DU schon alles gemacht hast und was das Ergebnis war. Außerdem ist es hilfreich zu wissen welche Hardware, welche Software du auf Sender- und Empfängerseite zu hast.
Schritt für Schritt Anleitung? Um selber Module zu schreiben? Word Dokument ist im Github von AskSinNew enthalten mit Methoden, logischem Ablauf, Schichtenmodell ...
Hallo zusammen
Sorry für die kurze Frage.
Hardware:
Arduino Pro mini 3,3 V (China)
Funkmodul aus HomeMatic HM-LC-Sw1-Ba-PCB
Arduino IDE 1.6.9
Homematic HMLan an FHEM
Sketch aug05a
Zitat
sketch_aug05a:19: error: variable 'cmdTab' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
Asksinnew_test
Serielle Ausgabe
AsksinNew Test
AskSin-Lib V 0.2.2
Keine Einträge im FHEM Logfile gefunden
Wie funktioniert das Pairing im Testsketch?
Anleitung:
Wie teste ich die Kommunikation zu FHEM(HM) ?
Was muss alles in den Sketch rein damit die Kommunikation funktioniert ?
Beispiel in dem die Kommunikation in beide Richtungen kurz erklärt wird.
Taster und LED am Arduino
Messwert an FHEM senden.
Kommando von FHEM zu Arduino senden.
LG
Stefan
Zitat von: Stefan M. am 29 Mai 2016, 15:49:03
Hallo zusammen
Sorry für die kurze Frage.
Hardware:
Arduino Pro mini 3,3 V (China)
Funkmodul aus HomeMatic HM-LC-Sw1-Ba-PCB
Serielle Ausgabe
AsksinNew Test
AskSin-Lib V 0.2.2
Ich habe bei mir schnell mal den HM-LC-Sketch auf einen pro mini geladen an dem ein cc1101 angeschlossen ist. Funktioniert fehlerfrei. Ausgabe ...
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.4
wdt_cal: 267
EE.
crc, flash: 36695, eeprom: 36695
initRly: 1
SN.
RV.
HMID: 01 02 06, MAID: 00 00 00
<- 0E 00 80 10 01 02 06 00 00 00 06 01 00 00 00 (2107)
Deine Ausgabe ist leer, das bedeutet dass die Kommunikation mit dem Funkmodul nicht fuktioniert ... Prüfe die Anschlüsse und vergleiche mit dem Pinout des Pro mini, ist anders als z. B. Uno oder Nano.
Wenn du beim Kompilieren Fehler erhältst kann es auch an der Arduino IDE Version liegen. Ich habe 1.6.8 ... du *.9. Als damals das Update auf *.8 kam hatten auch manche Probleme obwohl die Sketche mit der Version *.5 funktioniert hatten. Ist unwahrscheiinlich, bei mir funktioniert das Beispiel HM-LC-Sw1-Ba-PCB.
Unabhängig davon ... allgemein:
Vorgehen allgemein ..
- Sketch laden
- entsprechende Module in den Fhem-Ordner (*.pm)
- Fhem autocreate on ... für den Fall dass es aus ist
- Fhem Cul/HMLan in Painring modus ... "set <devicename> hmPairForSec 600"
- Arduino Pro in Pairing modus setzen ... Taster drücken oder was deine Hardware vorsieht
--> Device sollte in Fhem auftauchen
Beiträge die dir helfen könnten ...
https://forum.fhem.de/index.php/topic,14140.msg339849.html#msg339849 (https://forum.fhem.de/index.php/topic,14140.msg339849.html#msg339849)
https://forum.fhem.de/index.php/topic,14140.msg346932.html#msg346932 (https://forum.fhem.de/index.php/topic,14140.msg346932.html#msg346932)
Bevor deine Console keine Meldung ähnlich "<- 0E 00 80 10 01 02 06 00 00 00 06 01 00 00 00 (2107)" ausgibt brauchst dir FHem gar nicht ansehen. Sobald diese Meldung angezeigt wird sollte im Fhem-Log irgend was wie "CUL_HM message unknow ... help me" erscheinen.
Sobald du das Beispiel oben erfolgreich laden und in Fhem pairen kannst, kannst dir Gedanken über eigene Module machen. Hilfe zu seiner Zeit. Wenn du sagst was du basteln willst kann dir ggf. jemand ein Beispiel im Sketchordner vorschlagen das du erweitern kannst.
Hallo kadettilac89
Danke erst mal für die schnelle Antwort.
Wie es aussieht habe ich die LibVersion V 0.2.2. Ich werde die erst mal updaten und dann Schritt für Schritt weiter machen.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
Die Anschaltung sollte ja passen oder ?
http://www.fhemwiki.de/wiki/Datei:2013-11-13_-_Fritzing-Screenshot_-_breit_-_CutUSM_800x600_85P.jpeg
LG
Stefan
Zitat von: Stefan M. am 29 Mai 2016, 16:39:29
Hallo kadettilac89
Danke erst mal für die schnelle Antwort.
Wie es aussieht habe ich die LibVersion V 0.2.2. Ich werde die erst mal updaten und dann Schritt für Schritt weiter machen.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
Die Anschaltung sollte ja passen oder ?
http://www.fhemwiki.de/wiki/Datei:2013-11-13_-_Fritzing-Screenshot_-_breit_-_CutUSM_800x600_85P.jpeg
LG
Stefan
Ich hab nur kompiliert. Ich weiß nicht wo ich die runtergeladen habe. ABer die Links sollten in diesem Thread zu finden sein. Ob die Pins richtig ist kann ich dir nicht sagen. Ich verwende ein CC1101-Modul da ich das auch in meinen Cul verwende und die laufen zuverlässig.
Der Hersteller ist nicht verpflichtet die internen Module immer mit selbem Pin-Out zu versehen. Aber für den Anfang kannst ja mal davon ausgehen.
Hi
hab die aktuelle NewAskSin-master aus dem GitHub eingespielt (vorher alle alten NewAskSin gelöscht)
Ergebnis schaut ein klein wenig anders aus aber die Version hat sich nicht geändert.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
Angeschlossen ist das FunkModul nach Plan.
Muss ich im Sketch angeben welches Funk Modul ich verwende ?
Kannst Du mir auf die schnelle sagen an welchen Pin der Taster bzw. Relay(LED) gehört.
LG
Stefan
Hallo zusammen
Diese Ausgabe hab ich nun schon mal am arduino.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
b> 14 E4 84 5E 3E 58 DE 00 00 00 89 F6 15 00 00 00 00 00 08 FF FC (5037)
b> 0F D4 86 10 21 CE B3 00 00 00 0A 60 DD 0D 00 00 (7857)
b> 14 00 84 5E 41 F9 CD 00 00 00 86 9D 55 00 00 03 00 00 09 0C FC (24740)
b> 14 48 84 5E 3E 58 A1 00 00 00 87 87 8B 00 1A C7 01 3D 09 0C FC (30457)
b> 0F 00 86 10 22 E4 79 00 00 00 0A 60 BD 0E 00 00 (37867)
b> 0F 09 86 10 21 CE C3 00 00 00 0A 60 D6 0D 00 00 (65135)
b> 0F 87 86 10 21 CE A2 00 00 00 0A 60 EB 0E 00 00 (66751)
b> 14 4E 84 5E 2A 34 74 00 00 00 C3 CF 7D 00 01 47 00 17 09 0E 01 (70049)
b> 0F F2 86 5E 3D FD 80 00 00 00 69 A2 1C 01 87 68 (90793)
Pins für Taster und LED hab ich auch rausgefunden ist das richtig?
LED rot D4 Pin4 gegen GND
Taster B0 Pin8 (Frage gegen GND oder VCC ?)
Led grün wo soll die hin im Sketch ist es auch D4
#define LED_RED_DDR DDRD // define led port and remaining pin
#define LED_RED_PORT PORTD
#define LED_RED_PIN PORTD4
#define LED_GRN_DDR DDRD
#define LED_GRN_PORT PORTD
#define LED_GRN_PIN PORTD4
#define LED_ACTIVE_LOW 0 // leds connected to GND = 0, VCC = 1
//- configuration key ----------------------------------------------------------------------------------------
#define CONFIG_KEY_DDR DDRB // define config key port and remaining pin
#define CONFIG_KEY_PORT PORTB
#define CONFIG_KEY_PIN PORTB0
#define CONFIG_KEY_PCICR PCICR // interrupt register
#define CONFIG_KEY_PCIE PCIE0 // pin change interrupt port bit
#define CONFIG_KEY_PCMSK PCMSK0 // interrupt mask
#define CONFIG_KEY_INT PCINT0 // pin interrupt
Die rote LED hat auch schon geblinkt.
LG
Stefan
Zitat von: Stefan M. am 29 Mai 2016, 17:50:06
Hallo zusammen
Diese Ausgabe hab ich nun schon mal am arduino.
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.2
AS.
PowerMode: 0
initRly: 1
SN.
RV.
HMID: 58 23 FF, MAID: 00 00 00
<- 0E 00 80 10 58 23 FF 00 00 00 06 01 00 00 00 (1939)
b> 14 E4 84 5E 3E 58 DE 00 00 00 89 F6 15 00 00 00 00 00 08 FF FC (5037)
b> 0F D4 86 10 21 CE B3 00 00 00 0A 60 DD 0D 00 00 (7857)
b> 14 00 84 5E 41 F9 CD 00 00 00 86 9D 55 00 00 03 00 00 09 0C FC (24740)
b> 14 48 84 5E 3E 58 A1 00 00 00 87 87 8B 00 1A C7 01 3D 09 0C FC (30457)
b> 0F 00 86 10 22 E4 79 00 00 00 0A 60 BD 0E 00 00 (37867)
b> 0F 09 86 10 21 CE C3 00 00 00 0A 60 D6 0D 00 00 (65135)
b> 0F 87 86 10 21 CE A2 00 00 00 0A 60 EB 0E 00 00 (66751)
b> 14 4E 84 5E 2A 34 74 00 00 00 C3 CF 7D 00 01 47 00 17 09 0E 01 (70049)
b> 0F F2 86 5E 3D FD 80 00 00 00 69 A2 1C 01 87 68 (90793)
Pins für Taster und LED hab ich auch rausgefunden ist das richtig?
LED rot D4 Pin4 gegen GND
Taster B0 Pin8 (Frage gegen GND oder VCC ?)
Led grün wo soll die hin im Sketch ist es auch D4
#define LED_RED_DDR DDRD // define led port and remaining pin
#define LED_RED_PORT PORTD
#define LED_RED_PIN PORTD4
#define LED_GRN_DDR DDRD
#define LED_GRN_PORT PORTD
#define LED_GRN_PIN PORTD4
#define LED_ACTIVE_LOW 0 // leds connected to GND = 0, VCC = 1
//- configuration key ----------------------------------------------------------------------------------------
#define CONFIG_KEY_DDR DDRB // define config key port and remaining pin
#define CONFIG_KEY_PORT PORTB
#define CONFIG_KEY_PIN PORTB0
#define CONFIG_KEY_PCICR PCICR // interrupt register
#define CONFIG_KEY_PCIE PCIE0 // pin change interrupt port bit
#define CONFIG_KEY_PCMSK PCMSK0 // interrupt mask
#define CONFIG_KEY_INT PCINT0 // pin interrupt
Die rote LED hat auch schon geblinkt.
LG
Stefan
Meldungen sagen dass Pairingversuch gesendet wird. Damit solltest du in Fhem schon pairen können.
Pin D8 Taster gegen GND.
Was du gepostet hast sind Led an D4 ... beide, wenn du hier den Pin änderst kannst auch getrennt ansteuern. ... schau ein paar Seiten weiter vor, da wurde mir ein Link auf Github zu einem Temperatursensor gepostet. Aus dem Sourcecode kannst du die LED übernehmen. IN Github ist auch ein Schaltplan enthalten.
Hallo zusammen
es funktioniert schon fast.
Die Taste an Pin 8 kann nun schon in FHEM den Status schalten, aber weder die grüne noch die rote LED am Modul zeigt den Status an.
#define LED_RED_DDR DDRD // define led port and remaining pin
#define LED_RED_PORT PORTD
#define LED_RED_PIN PORTD4
#define LED_GRN_DDR DDRD
#define LED_GRN_PORT PORTD
#define LED_GRN_PIN PORTD5
Im seriellen Monitor schaut es soweit ich es beurteilen kann aber gut aus.
Zitat
switchRly: 1, 0
<- 0E 10 A0 10 58 23 FF 1E A2 24 06 01 00 00 50 (2135767)
m> 0A 10 80 02 1E A2 24 58 23 FF 00 (2135907)
b> 14 3D 84 5E 41 F9 CD 00 00 00 86 9D 56 00 00 03 00 00 09 12 FD (2140623)
b> 0F 3D 86 10 22 E4 79 00 00 00 0A 60 BB 0E 00 00 (2143165)
switchRly: 1, 200
<- 0E 11 A0 10 58 23 FF 1E A2 24 06 01 C8 00 5E (2143352)
m> 0A 11 80 02 1E A2 24 58 23 FF 00 (2143493)
m> 0E 12 B0 11 1E A2 24 58 23 FF 02 01 00 00 00 (2147599)
switchRly: 1, 0
<- 0E 12 80 02 58 23 FF 1E A2 24 01 01 00 00 53 (2147608)
m> 0E 13 B0 11 1E A2 24 58 23 FF 02 01 C8 00 00 (2150622)
switchRly: 1, 200
<- 0E 13 80 02 58 23 FF 1E A2 24 01 01 C8 00 52 (2150632)
b> 14 22 84 5E 3E 58 DE 00 00 00 89 F6 15 00 00 00 00 00 09 0A FF (2152922)
l> 14 47 A4 5F 2A 34 74 1E A2 24 C3 D0 FD 00 1C EF 01 DF 09 0C FF (2156243)
l> 0A 47 80 02 1E A2 24 2A 34 74 00 (2156358)
LG
Stefan
Zitat von: Stefan M. am 29 Mai 2016, 20:22:23
Hallo zusammen
es funktioniert schon fast.
Die Taste an Pin 8 kann nun schon in FHEM den Status schalten, aber weder die grüne noch die rote LED am Modul zeigt den Status an.
Was erwartetst du? Dass eine LED On/Off ist wenn du in Fhem schaltest?
void switchRly(uint8_t channel, uint8_t status) {
// switching the relay, could be done also by digitalWrite(3,HIGH or LOW)
#ifdef SER_DBG
dbg << F("switchRly: ") << channel << ", " << status << "\n";
#endif
if (status) setPinHigh(PORTD,3); // check status and set relay pin accordingly
else setPinLow(PORTD,3);
}
Das ist der Code der ausgeführt wird. Du siehst dass PORTD3 auf High geschaltet wird. Prüfe mit einem Multimeter ob hier Spannung anliegt wenn ON ist. Wenn ja kannst zum Testne hier eine LED anstecken mit Widerstand. Dann siehst den Status. Die Led in der Definition sollten nur leuchten wenn Signal gesendet wird oder Pairing aktiv ist. Wenn du zusätzlich zum Pin3 eine LED leuchten lassen willst kannst du den Code aus dem "Blink" Beispiel in den Code ergänzen den ich oben schon gepostet hab.
HM funktioniert soweit, jetzt musst du ein Beispiel anpassen das am besten zu deinen Anforderungen passt. Um das zu machen musst du dich etwas in den Sourcecode einlesen. Die wichtigsten Funktionen sind in der *.ino selbst als auch in hardware.h und register.h.
Hallo kadettilac89
danke für die Hilfe, jetzt hab ich meinen Denkfehler gefunden.
Pin 4 und 5 zeigen den Kommunikationsstatus an und Pin 3 ist der Schaltpin.
Jetzt hab ich es verstanden ich war auf Pin 4 und 5 fixiert.
LG
Stefan
Hallo zusammen
hat jemand für das TRX868 Funk-Modul ein Fritzing Bauteil ?
Ich wollte mir nun den Schaltplan mit Fritzing zeichnen aber finde kein passendes Bauteil für das Funkmodul.
LG
Stefan
Hallo zusammen
ich habe nun die .dev Version geladen.
Muss ich bei den sketch
HM_LC_SW1_BA_PCB
etwas mit dem HM_DEVICE_AES_KEY beachten.
#define HM_DEVICE_AES_KEY 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10
Kompilieren und Upload geht, aber die Kommunikation geht nicht so richtig vom Device zu Fhem geht, aber die Richtung zum Device geht nicht.
Zitat
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.4
wdt_cal: 274
EE.
crc, flash: 36695, eeprom: 36695
initRly: 1
SN.
RV.
HMID: 01 02 06, MAID: 00 00 00
LG
Stefan
Zitat von: Stefan M. am 31 Mai 2016, 20:16:09
Hallo zusammen
ich habe nun die .dev Version geladen.
Muss ich bei den sketch
HM_LC_SW1_BA_PCB
etwas mit dem HM_DEVICE_AES_KEY beachten.
ich hab bei meinem test nur kompiliert und hochgeladen ohne irgend etwas zu ändern, es wurde aber dann eine message gesendet. Mehr hab ich nicht getestet, aber es sah gut aus und ich denke es würde auch funktionieren.
Du hattest schon Meldungen gesendet bzw. empfangen also hat die Hardware funktioniert. Wenn du die ältere Version nochmal falsht ... wird dann wieder gesendet? Wie hast du die Hardware aufgebaut? Breadboard, ist evtl. ein Kabel raus? Prüfe mal die Verbindungen ...
Hi
Ich habe festgestellt das der HMLan in Overload geht.
Aufgebaut auf Breadboard. Verbindungen sollten passen. Da ja in Richtung FHEM alles funktioniert nur in Richtung Arduino stimmt was nicht.
Ich sehe glaube ich keine Nachrichten in Richtung Arduino ankommen.
Zitat
switchRly: 1, 0
<- 0E 08 80 10 01 02 06 00 00 00 06 01 00 00 00 (268800)
switchRly: 1, 200
<- 0E 09 80 10 01 02 06 00 00 00 06 01 C8 00 00 (2916646)
switchRly: 1, 0
<- 0E 0A 80 10 01 02 06 00 00 00 06 01 00 00 00 (2919409)
switchRly: 1, 200
<- 0E 0B 80 10 01 02 06 00 00 00 06 01 C8 00 00 (4173916)
switchRly: 1, 0
<- 0E 0C 80 10 01 02 06 00 00 00 06 01 00 00 00 (4176280)
<- 1A 0D 84 00 01 02 06 00 00 00 10 00 6C 48 42 73 77 69 74 63 68 30 31 00 41 01 00 (4343734)
switchRly: 1, 200
<- 0E 0E 84 10 01 02 06 00 00 00 06 01 C8 00 00 (4354491)
switchRly: 1, 0
<- 0E 0F 84 10 01 02 06 00 00 00 06 01 00 00 00 (4364735)
<- 1A 10 84 00 01 02 06 00 00 00 10 00 6C 48 42 73 77 69 74 63 68 30 31 00 41 01 00 (4370323)
LG
Stefan
Hallo zusammen
gibt es den Sketch HM_LC_SW1_BA_PCB (im .dev) auch ohne AES oder wie kann ich AES im Sketch deaktivieren.
LG
Stefan
Hallo nochmal
Der Sketch aus dem -Master funktioniert einwandfrei. Habe nun wieder die -Master Version laufen . :-(
LG
Stefan
Ich habe leider ein Problem beim Flashen des Asksin Bootloaders. Ich verwende nachfolgenden Befehl für das Flashen:
avrdude -p m328p -P usb -c usbasp -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:i
Und erhalte diese Ausgabe:
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xD0"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD0:
avrdude: load data hfuse data from input file 0xD0:
avrdude: input file 0xD0 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0x06"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x06:
avrdude: load data efuse data from input file 0x06:
avrdude: input file 0x06 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0x2F"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x2F:
avrdude: load data lock data from input file 0x2F:
avrdude: input file 0x2F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex"
avrdude: writing flash (32768 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 32768 bytes of flash written
avrdude: verifying flash memory against Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: load data flash data from input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:
avrdude: input file Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex contains 32768 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7243
0x60 != 0xe0
avrdude: verification error; content mismatch
avrdude: safemode: Fuses OK (H:06, E:D0, L:E2)
avrdude done. Thank you.
Andere Bootloader bringen das selbe Ergebnis. Ist der Pro Mini hin? :-[
Probier mal mit reduzierter Geschwindigkeit.
Zitat
Manche AVR kannst du nur dann flashen, wenn die
Programmiergeschwindigkeit runtergesetzt wurde. Das liegt daran, dass
die Programmiergeschwindigkeit deutlich kleiner sein muss als der
jeweils intern eingestellte CPU-Takt des AVR (ich glaub maximal 1/4).
Manche ältere USBasp haben dazu einen Jumper (nicht alle), neuere machen
das über die Option "-B".
Habe ich von hier https://www.mikrocontroller.net/topic/284884 (https://www.mikrocontroller.net/topic/284884)
Oder direkt an nen USB-Port anschießen. Meiner kann nicht oder nur schlecht mit USB-Hubs.
Der Fehler bleibt leider erhalten. Ich konnte nun den normalen Arduino Bootloader flashen (mit dem Fehler) und kann den Pro Mini auch über die Arduino IDE flashen. Der Blink Sketch lässt sich erfolgreich aufspielen, allerdings blinkt die LED nicht, obwohl das Programm durch läuft. :-[
Zitat von: Linef am 06 Mai 2016, 01:13:26
Hallo kadettilac89,
Die Quellen stehen unter https://github.com/LineF/NewAskSin.git im Branch dev zur Verfügung. Das Hauptmodul des Sensors (mit Schaltplan - ist aber ziemlich identisch zum Universalsensor) liegt unter https://github.com/LineF/HM-Sensor.git, ebenfalls im Branch dev.
Ein Sketch ist es nicht, da ich mit dem Atmel Studio entwickle, aber sollte in der Arduino IDE (nach Rename von main.cpp) auch übersetzbar sein.
Zitat von: Dirk am 09 Mai 2016, 20:54:46
Aber wie gesagt mit AAA-Zellen. Mit AA, also R6 dann deutlich länger.
Ja, stimmt, das ist ein Subrepo auf einen Fork der alte AskSin-Lib. Diese musst du auch unbedingt verwenden. Da hatte ich noch einiges gefixt und optimiert.
Gruß
Dirk
Zitat von: Tom71 am 21 Mai 2016, 22:45:26
Hast du den dev-Branch benutzt? Ich musste bei mir auch noch pcint.* löschen, dann geht es.
Hallo ihr Helfer,
ich habe mit eurer Hilfe den Temp-Sensor zum Laufen gekriegt, läuft jetzt seit knapp 2 Wochen. Vielen dank für die Hilfe!
LineF, ich habe den Sourcecode etwas angepasst und ein Define eingefügt um zwischen bei der Temperaturmessung zwischen DHT22 und DS18B20 wählen zu können. Keine große Anpassung. Wenn du willst kannst es ja in das Original einfügen da es keine Auswirkung auf die Funktion hat.
Jetzt muss ich nur noch hinbekommen, dass der Batterielevel auch in meinem DB-log auftaucht. Da ist irgendwo anders ein Problem da das Reading aktuallisiert wird.
Zitat von: kadettilac89 am 03 Juni 2016, 23:30:37
ich habe mit eurer Hilfe den Temp-Sensor zum Laufen gekriegt, läuft jetzt seit knapp 2 Wochen. Vielen dank für die Hilfe!
LineF, ich habe den Sourcecode etwas angepasst und ein Define eingefügt um zwischen bei der Temperaturmessung zwischen DHT22 und DS18B20 wählen zu können. Keine große Anpassung. Wenn du willst kannst es ja in das Original einfügen da es keine Auswirkung auf die Funktion hat.
Jetzt muss ich nur noch hinbekommen, dass der Batterielevel auch in meinem DB-log auftaucht. Da ist irgendwo anders ein Problem da das Reading aktuallisiert wird.
Schön zu hören, daß es bei Dir jetzt auch läuft. Ich bin grad dran, den Stromverbrauch zu testen - der scheint mir etwas hoch. Auch auf einem zweiten Nachbau, auf dem aber noch kein Sender und keine Sensoren sind. Muß mal noch mit dem Oszi den Stromverbrauch messen - Multimeter ist zu ungenau.
Ansonsten ist der Code aber noch nicht fertig - Die Register funktionieren noch nicht und ich möchte auch noch eine Kalibrierungsmöglichkeit pro Peer dazubauen.
Aber erst mal werden ja die Messwerte gesendet :)
Martin
Zitat von: Linef am 04 Juni 2016, 00:36:51
Schön zu hören, daß es bei Dir jetzt auch läuft. Ich bin grad dran, den Stromverbrauch zu testen - der scheint mir etwas hoch. Auch auf einem zweiten Nachbau, auf dem aber noch kein Sender und keine Sensoren sind. Muß mal noch mit dem Oszi den Stromverbrauch messen - Multimeter ist zu ungenau.
Ansonsten ist der Code aber noch nicht fertig - Die Register funktionieren noch nicht und ich möchte auch noch eine Kalibrierungsmöglichkeit pro Peer dazubauen.
Stromverbrauch ist für mich kein großes Problem, ich hab 2 18650 Akkus dran, die sollten das wettmachen. Habe zusätzlich den Powermode auf POWER_MODE_WAKEUP_8000MS gesetzt. Ob es was bringt weiß ich nicht, aber es läuft.
Werde aber trotzdem dein Github-dev beobachten und neuere Versionen testen.
@kadettilac89
Hallo,
der HM-Sensor -Sketch bricht bei mir mit DS18B20 ab:
HM-Sensor-DS:140: error: 'mStartOn' was not declared in this scope
state = mStartOn;
----
#ifdef DS18B20
state = mStartOn;
Muss in das enum noch mStartOn rein?
enum mState {mInit, mWait, mPwrOn, mStartDS,mStartOn};
Der Sketch von linef funktioniert bei mir gut. Die Werte vom DS18B20 kommen in FHEM an. Ich habe nur immer noch Probleme mit der seriellen Ausgabe. Folgendes mache ich:
- Kompilieren mit Arduino IDE für "Arduino Pro or Pro Min, 3.3V, 8Mhz)
- Umwandeln der hex-> eq3
- Flashen per OTA
Dann kommt auf der Console:
AskSin OTA Bootloader V0.7.0
Start App ˜,¿§¿£ÍÞ¿¬�¿ Þ�ãÓ£ÑÞ]œÑ
Die Kompiler-Params sind:
avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10609 -DARDUINO_AVR_PRO -DARDUINO_ARCH_AVR "-IC:arduino" "-IC:eightanaloginputs" "HM-Sensor-DS.ino.cpp" -o "nul"
Wie flashed ihr? Benutzt ihr einen Arduino? Ich benutze den Innensensor von Dirk. Das ist ein Atmega328P mit internen Oszillator.
Gruss Thomas
Zitat von: Tom71 am 04 Juni 2016, 10:51:41
@kadettilac89
Hallo,
der HM-Sensor -Sketch bricht bei mir mit DS18B20 ab:
HM-Sensor-DS:140: error: 'mStartOn' was not declared in this scope
state = mStartOn;
----
#ifdef DS18B20
state = mStartOn;
teste mal die Version, ich hab meine Änderungen in die neueste Version von githut eingearbeitet. copy paste error ..
wenns damit auch nicht geht muss ich mir das nochmal ansehen...
Zitat von: Tom71 am 04 Juni 2016, 10:51:41
@kadettilac89
HM-Sensor-DS:140: error: 'mStartOn' was not declared in this scope
state = mStartOn;
----
#ifdef DS18B20
state = mStartOn;
Muss in das enum noch mStartOn rein?
...
In dem Sketch von kadettilac89 stimmt an der Stelle noch mehr nicht. Z.B. muß auch nach dem Start der Temperaturmessung ca. 700ms gewartet werden, bis die Messung ausgelesen werden kann. Das erfolgt auch nicht mehr.
Zitat von: Tom71
Ich habe nur immer noch Probleme mit der seriellen Ausgabe. Folgendes mache ich:
...
Dann kommt auf der Console:
AskSin OTA Bootloader V0.7.0
Start App ˜,¿§¿£ÍÞ¿¬�¿ Þ�ãÓ£ÑÞ]œÑ
Schau mal, ob bei Dir im Main-Programm noch das Register OSCCAL gesetzt wird. Der Wert dort gilt nur für meinen spezifischen Controller. Bei meinem zweiten Nachbau musste hier schon wieder ein anderer Wert rein. Da kamen auch so seltsame Zeichen...
Am besten, du kommentierst das Setzen des Registers aus, dann nimmt der Atmel seinen Werksstandard (der bei jedem Exemplar ander ist) und läuft einigermaßen genau mit 8 MHz:
// Attention: your controller my have other factory calibration !!
// If you are unsure about the internal RC-frequency of your chip then comment out setting OSCCAL -
// use factory default instead!
// my chip: 1kHz - 8A=994Hz, 8B=998,4Hz, 8C=1001,6Hz, 8E=1010Hz
// frequency measured with help of millis-ISR (toggling LED port and measuring frequency on it)
uint8_t clk_corr=0x8B;
//OSCCAL = clk_corr;
Das Setzen des Registers bringt nur dann was, wenn man die Frequenz genau ausmisst. Dann kann man noch wenige Prozent Genauigkeit rausholen. Ist man ein paar Prozent über 8 MHz, dann funktioniert die serielle Übertragung nicht mehr, und es kommen solche seltsamen Zeichen...
Martin
Hallo zusammen,
vielleicht kann mir jemand helfen. Ich habe folgendes Problem:
Bei Verwendung von newAsksin-master habe ich Daten empfangen und senden können, allerdings ist mir das Pairing nicht gelungen. Ich habe einen Systemkey in der original CCU2 hinterlegt, also dachte ich mir verwende ich die newAksin-dev Branch da diese ja scheinbar AES unterstützt.
Bei der dev Branch ist es nun so das ich keine Daten empfange. Für mich kann das eigentlich nur ein GD0 sein, also Pins überprüft ich finde es ist aber alles in Ordnung:
Log:
HM_LC_Dim1PWM_CV
AskSin-Lib V 0.2.4
wdt_cal: 264
EE.
crc, flash: 27882, eeprom: 27882
initDim: 1
initDim: 2
initDim: 3
SN.
RV.
HMID: 11 02 07, MAID: 00 00 00
<- 0E 00 80 10 11 02 07 00 00 00 06 01 00 00 00 (2291)
Ich verwende ein Ardurino Uno und ein cc1101 für 868MHz.
GD0 an Pin2/PD2
#define CC_CS PIN_B2 // chip select
// #define CC_GDO0 PIN_B2
#define CC_GDO0 PIN_D2 // GDO0 pin, identify data received on falling edge
#define CC_MISO PIN_B4 // SPI port MISO
#define CC_MOSI PIN_B3 // SPI port MOSI
#define CC_SCLK PIN_B5 // SPI port Clock
Gruß und Dank,
Stephan
Hallo Martin,
OSCCAL auskommentieren hat es gebracht. Und ich hatte schon soviel anderes probiert. Danke
Gruß Thomas
Gesendet mobil
Zitat von: StephanAc am 05 Juni 2016, 16:35:30
Bei Verwendung von newAsksin-master habe ich Daten empfangen und senden können, allerdings ist mir das Pairing nicht gelungen. Ich habe einen Systemkey in der original CCU2 hinterlegt, also dachte ich mir verwende ich die newAksin-dev Branch da diese ja scheinbar AES unterstützt.
Probier mal den DevAES Branch. Das ist der derzeit aktuellste Branch und hat AES Support.
Martin
Zitat von: Linef am 05 Juni 2016, 23:24:48
Probier mal den DevAES Branch. Das ist der derzeit aktuellste Branch und hat AES Support.
Martin
Super danke !!! Gepaired Du hast mir echt Debugging-Zeit erspart. Nun kanns weitergehen.
Gruß und Dank,
Stephan
Hallo zusammen
ich hab nun diesen CC1101 bekommen. Der sollte doch funktionieren oder ?
http://www.ebay.de/itm/868-Mhz-Funk-Modul-CC1101-FHEM-Selbstbau-CUL-Wireless-Transceiver-Arduino-F01P-/172116131449?hash=item2812ebbe79
Muss ich im Sketch (HM_LC_SW1_BA_PCB) was anpassen ?
Der Anschluss sollte auch passen.
Zitat
Farbe Beschreibung TRX868 schmal TRX868 breit CC1101 Arduino Pro Mini
rot VCC 3,3 V 1 8 1 (VCC) 3,3 V
schwarz GND 2 7 2 (GND) GND
weiß SPI MOSI 3 1 3 (SI) 11
violett SPI SCK 4 2 4 (SCLK) 13
grün SPI MISO 5 3 5 (SO GDO1) 12
6 4 6 (GDO2) 3
gelb GDO0 7 5 7 (GDO0) 2
blau SPI CS 8 6 8 (CSn) 10
Irgendwie werden aber keine Daten Empfangen.
Serielles Output folgt noch
UPDATE 00:00 : Nochmal die Belegung geprüft Fehler gefunden jetzt funktioniert es.
Jetzt muss ich nur noch mit der Adressierung im Sketch klar kommen im Moment reagieren beide Modul auf Befehle aus FHEM.
Welche Adressen muss ich im Sketch anpassen damit ich unterschiedliche Devices bekomme?
LG
Stefan
Zitat von: Stefan M. am 10 Juni 2016, 23:42:56
Jetzt muss ich nur noch mit der Adressierung im Sketch klar kommen im Moment reagieren beide Modul auf Befehle aus FHEM.
Welche Adressen muss ich im Sketch anpassen damit ich unterschiedliche Devices bekomme?
In register.h hast du HMID udn Serial number, beide werden zum Pairen verwendet. Ändere mal die Werte damit hast du dann zwei unterschiedliche Devices. HMID z.B. 0x01, 0x02, 0x07 und Serial halt letzte Stelle 2.
const uint8_t HMSerialData[] PROGMEM = {
/* HMID */ 0x01, 0x02, 0x06,
/* Serial number */ 'H', 'B', 's', 'w', 'i', 't', 'c', 'h', '0', '1', // HBswitch01
/* Default-Key */ HM_DEVICE_AES_KEY,
/* Key-Index */ HM_DEVICE_AES_KEY_INDEX,
Hallo kadettilac89
Danke für die Info.
uint16_t EEMEM eMagicByte;
uint8_t EEMEM eHMID[3] = {0x58,0x23,0xfe,};
uint8_t EEMEM eHMSR[10] = {'X','M','S','1','2','3','4','5','6','8',};
uint8_t EEMEM eHMKEY[16] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,};
// if HMID and Serial are not set, then eeprom ones will be used
uint8_t HMID[3] = {0x58,0x23,0xfe,};
uint8_t HMSR[10] = {'X','M','S','1','2','3','4','5','6','8',}; // XMS1234567
uint8_t HMKEY[16] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,};
mein Fehler war ich hatte die beiden Werte HMSR und HMKey angepasst und nicht HMID und HMSER.
Jetzt funktioniert es.
LG
Stefan
Zitat von: Stefan M. am 11 Juni 2016, 09:10:07
mein Fehler war ich hatte die beiden Werte HMSR und HMKey angepasst und nicht HMID und HMSER.
Jetzt funktioniert es.
LG
Stefan
Kleinigkeiten können so viel bewirken 8)
Hallo zusammen
ich hab gleich noch eine Frage im Zusammenhang mit einem Funkmodul.
Ich hab noch ein TRX868-TFK-SL (schmale Bauform).
Ich habe es aus einem defekten (Wasserschaden) HM-Regensensor ausgebaut.
Kennt jemand eine Möglichkeit zu prüfen ob das Modul überhaupt noch funktionsfähig ist.
Ich habe es schon ersatzweise für das (breite) Modul angeschlossen, da hat sich aber gar nichts getan.
LG
Stefan
Zitat von: Stefan M. am 11 Juni 2016, 18:04:59
Kennt jemand eine Möglichkeit zu prüfen ob das Modul überhaupt noch funktionsfähig ist.
Ich habe es schon ersatzweise für das (breite) Modul angeschlossen, da hat sich aber gar nichts getan.
Ich denke, ums komplette Anschließen kommst Du nicht rum, da der Chip auf dem Modul erst programmiert werden muß, damit er sendet.
Und alleine dafür werden fast alle Anschlußleitungen benötigt.
Gruss,
Martin
Hi
ich hab das Modul schon komplett (alle Pins) an die funktionierende Schaltung (Sketch HM_LC_SW1_BA_PCB) mit dem breiten Modul angeschlossen.
LG
Stefan
Wenn Du alles richtig angeschlossen hast, sollte es funktionieren. Laut Wiki sind breites und schmales Modul unterschiedlich belegt - aber ich denke, das hast Du beachtet.
Gruss,
Martin
Zitat von: Stefan M. am 11 Juni 2016, 18:04:59
Ich hab noch ein TRX868-TFK-SL (schmale Bauform).
Ich habe es aus einem defekten (Wasserschaden) HM-Regensensor ausgebaut.
Kennt jemand eine Möglichkeit zu prüfen ob das Modul überhaupt noch funktionsfähig ist.
Selbst wenn das Modul noch funktionsfähig ist, wird es nicht funktionieren . Auf diesem Modul ist kein CC1101.
Das wusste ich auch noch nicht, daß es da verschiedene Versionen gibt - man lernt nie aus.
Ich dachte, alle hätten einen CC1101 verbaut.
Hätte ich auch schon unter https://forum.fhem.de/index.php/topic,38404.msg310073.html#msg310073 finden können...
Martin
Hallo zusammen
findet sich evtl. jemand der das Wiki aktualisieren kann. Ich habe leider keine schreibrechte.
http://www.fhemwiki.de/wiki/HomeMatic_Asksin_Library
- Welche Module funktionieren welche nicht.
- Anschluss Bilder der Module (CC11001)
- Anschluss an Arduino UNO über Pegelwandler
- NewAskSin Infos
LG
Stefan
Ich kriege leider bisher die Asksin library leider nicht ans laufen.
Ich verwende Arduino IDE 1.6.6 und die aktuellste Version der NewAsksin library.
Ich habe zum Test einfach das HM_LC_SW1_BA_PCB programmiert. Der Controller hängt sich an der Stelle auf an der
hm.init(); // init the asksin framework
sei(); // enable interrupts
aufgerufen wird. Jedoch NUR, wenn der Slave Select Pin des CC1101 Moduls auf Digital 10 verbunden wird.
Meine Vermutung hier ist, dass es daran liegt, dass ich den Atmega32U4 (Arduino Pro Micro Board[von sparkfun]) verwende.
Ich habe den auf dem Board als Digital 10 markierten Pin 30 [PORTB6] verwendet. Danach zum testen den Pin 8 [PORTB0] der als standard slave select markiert ist.
In beiden fällen hängt der Controller beim Init fest.
Das Programm läuft nur durch, sofern der SS auf GND gezogen wird oder einfach nicht angeschlossen ist.
Daher meine Frage:
Hat jemand das ganze mit einem 32U4 Controller zum laufen gebracht?
Und lässt es sich in HomeMatic einbinden? Ich teste es aktuell auf einem HomeMatic Server auf einem Raspberry PI installiert der das PI Funkmodul von ELV angeschlossen hat. Muss man das Funkmodul noch irgendwie initialisieren?
Ich hab endlich herausgefunden, dass in Hardware.h die Pin definition festgelegt ist ( auch für den 32U4 ). Diese stimmt natürlich zu 0 mit meiner ein, ich werde versuchen sie anzupassen und euch dann berichten wie es gelaufen ist da z.B. die Interrupt Pins ja auch mit Registereinträgen behaftet sind
Ich habe zwar keine Pro-Micro, aber...
auf dieser Zeichnung ist SS links oben:
https://www.arduino.cc/en/uploads/Main/ArduinoMicro_Pinout3.png
Micky
Zitat von: micky0867 am 27 Juni 2016, 13:52:35
Ich habe zwar keine Pro-Micro, aber...
auf dieser Zeichnung ist SS links oben:
https://www.arduino.cc/en/uploads/Main/ArduinoMicro_Pinout3.png
Micky
Ich verwende das Arduino Pro Micro von Sparkfun, hat also eine starke Abweichung von den Kontakten her zum geniuno micro.
https://www.sparkfun.com/products/12587
Ist aber auch irrelevant, ich habe wie gesagt die Library gefunden die die Pinbelegung enthält und entsprechend meine Verdrahtung angepasst da doch starke unterschiede waren.
Das Funkmodul kommuniziert mit meiner Homematic Zentrale auf dem Raspberry PI. Es gibt also tatsächlich einen Datenaustausch der jedoch unterbrochen wird.
Im Anhang findet Ihr einen Screenshot des Serial Monitors. Am Anfang stellt der Blaue dar, was beim booten des Controllers geschiet. Danach habe ich bei abgeschalteter Homematic Zentrale einen Pairing Versuch (oder wie sich das bei Homematic nennt) gestartet auf den natürlich keine Antwort kommt, nur um zu zeigen wie es aussieht.
Unten ist dann der Versuch bei eingeschalteter Zentrale im "Geräte Anlernmodus"
Hatte evtl einer von euch schon mal diesen Timed out Fehler oder einfach ein paar Tipps?
Korrektur:
Alles läuft, ich hatte das Gerät bereits unbewusst angelernt und die Meldung nicht gesehen
Mal andere Frage: kann jemand evtl. die alte AskSin wieder zum Laufen bringen. Ich brauche dringend einen mehrfachen Taster und kriege die alte Lib nicht kompiliert. Dabei habe ich schon alle fehlende Libs eingbunden (BMP085, Sensirion, Wire, twi usw.)
Oder weiß jemand, ob es im Netzt andere funktionierende Beispiele auf AskSin Basis gibt?
Danke
Im Wettersensor-Projekt (hier: https://github.com/kc-GitHub/Wettersensor und hier: https://forum.fhem.de/index.php/topic,20620.0.html) wird die alte AskSin-Lib eingesetzt.
Allerdings nicht die originale, sondern die angepaßte von kc-github.
Gruss,
Martin
Zitat von: Linef am 28 Juni 2016, 14:24:00
Im Wettersensor-Projekt (hier: https://github.com/kc-GitHub/Wettersensor und hier: https://forum.fhem.de/index.php/topic,20620.0.html) wird die alte AskSin-Lib eingesetzt.
Allerdings nicht die originale, sondern die angepaßte von kc-github.
Gruss,
Martin
Hat einer von euch den aktuellen Stand der kc-GitHub library getestet? Ich wollte das 6 Tastenswitch ausprobieren und habe den Asksin Ordner in den library ordner platziert daraufhin hat sich der compiler gemeldet, dass die HM6TastenSwitch.h noch nicht integriert ist. Daraufhin habe ich die genannte Header ebenfalls in den AskSin Library Ordner platziert woraufhin der Compiler nun tonnenweise Fehler ausspuckt
Alle Fehler sind hier auffindbar http://pastebin.com/tQuFGdzt
Als wäre das Beispiel für einen alten Zustand der library und jetzt hätte sich alles von der Syntax her geändert
Zitat von: Linef am 04 Juni 2016, 00:36:51
Schön zu hören, daß es bei Dir jetzt auch läuft. Ich bin grad dran, den Stromverbrauch zu testen - der scheint mir etwas hoch. Auch auf einem zweiten Nachbau, auf dem aber noch kein Sender und keine Sensoren sind. Muß mal noch mit dem Oszi den Stromverbrauch messen - Multimeter ist zu ungenau.
Ansonsten ist der Code aber noch nicht fertig - Die Register funktionieren noch nicht und ich möchte auch noch eine Kalibrierungsmöglichkeit pro Peer dazubauen.
Hi Linef,
falls es dich interessiert ... ich habe den Sensor mit 2 18650 Akkus laufen. Seit 04.06. ist die Spannung von 4.2 auf 3.95 Volt gefallen. Wenn ich mir die Entladekurve von 18650 ansehe ist das ganz grob 5% der Kapzität. Hochgerechnet auf einen 18650 Akku ergäbe das eine Laufzeit von ca. 1 Jahr. Ich habe 2 davon dran hängen weil ich genügend rumliegen hab.
Ich habe nur einen DHT22 dran.
Hallo,
ich habe mir einen Wassermelder (HM-SEC-WDS) zusammen getüdelt.
Im Moment basiert die SW auf der Asksin library.
Eigentlich wollte ich auf die NewAsksin umstellen, aber mir fehlt eine Vorlage für einen Sensor, als Beispiele finde ich nur Aktoren und der Custom_Lux scheint gar nicht zu funktionieren.
Hat hier jemand einen entsprechenden Beispielcode, von dem ich abkupfern könnte?
Micky
Hallo Micky,
ich habe mir die NewAskSin so weit hergerichtet, daß ich Temperatur- und Feuchtewerte von meinen Sensoren übermittelt bekomme. Ist noch nicht ganz fertig, aber läuft weitestgehend.
Den Code findest Du derzeit hier: https://github.com/LineF/HM-Sensor.git, Branch "dev".
Martin
Hallo Martin,
danke dir.
Es kompiliert schonmal, jetzt muss ich "nur" noch die richtigen Stellen für meinen WDS ausfindig machen.
LG
Micky
Zitat von: micky0867 am 05 Juli 2016, 21:16:38
Hallo Martin,
danke dir.
Es kompiliert schonmal, jetzt muss ich "nur" noch die richtigen Stellen für meinen WDS ausfindig machen.
LG
Micky
Hallo Micky, ich hätte höchstes Interesse an beiden Codes die du geschrieben hast um den Wassersensor WDS zu emulieren. Sowohl für die alte als auch für die neue Asksin library da ich grade das gleiche vorhabe.
Ich versuche aktuell die HM_LC_SW1_BA_PCB umzuschreiben... erfolglos wie man an meiner Nachricht merkt.
Hier auf jeden Fall die XML File aus der Homematic CCU die den HM_SEC_WDS1/2 beschreibt http://codebeautify.org/xmlviewer/cbbe3f0e
Wie gesagt, ich würde mich äußerst freuen, wenn du schonmal den Code für die alte Asksin hochladen könntest.
Gruß Martin H.
Hat jemand eine Ahnung vom Sicherheitsschlüssel?
Ich habe mal im HM-LC-SW1-BA-PCB Beispiel der Newasksin Library in der register.h in Zeile 30 die "Model ID" auf "/* Model ID 2 byte */ 0x00,0x45," geändert um einen HM-SEC-WDS zu emulieren. In meiner Homematic Zentrale wird das Gerät daraufhin erkannt, deklariert und hinzugefügt. Funktion ist natürlich noch nicht gegeben da die falschen Befehle gesendet werden, aber es wird schonmal erkannt.
Ich möchte das ganze jedoch in meine Qivicon einfügen die sich über den Sicherheitsschlüssel beschwert.
Fehlermeldung:
"Das von Ihnen ausgewählte Gerät nutzt eine für das QIVICON System unbekannten Sicherheitsschlüssel!
Bitte wenden Sie sich an den Verkäufer des Gerätes, um den Sicherheitsschlüssel zurückzusetzen und das Gerät mit Ihrer QIVICON Home Base nutzen zu können. Für weitere Informationen klicken Sie bitte auf hilfe."
Weiß jemand was dort eingetragen werden müsste? Ich vermute dass der Sicherheitsschlüssel in der register.h in Zeile 24 "uint8_t HMKEY[16] =" eingefügt werden muss.
Zitat von: Apicalis am 06 Juli 2016, 14:07:40
Hallo Micky, ich hätte höchstes Interesse an beiden Codes die du geschrieben hast um den Wassersensor WDS zu emulieren.
Hallo Martin,
das ist aber quick&dirty.
Ich habe die LEDs weggelassen und die Batterieübewachung dürfte auch nicht tun.
Egal, ich hab's mal hochgeladen:
https://github.com/micky0867/HM_SEC_WDS_AskSin
...und dabei gleich noch was über git gelernt ;-)
Ich habe auch Fotos gemacht, muss mal schauen, ob man die hier oder besser auf Github hochlädt.
Jetzt ist erstmal Fussball angesagt 8)
Micky
Zitat von: Linef am 28 Juni 2016, 14:24:00
Im Wettersensor-Projekt (hier: https://github.com/kc-GitHub/Wettersensor und hier: https://forum.fhem.de/index.php/topic,20620.0.html) wird die alte AskSin-Lib eingesetzt.
Allerdings nicht die originale, sondern die angepaßte von kc-github.
Hier dort ich ein paar Bugfixes und Optimierungen eingebaut.
Zitat von: Apicalis am 30 Juni 2016, 09:40:29
Hat einer von euch den aktuellen Stand der kc-GitHub library getestet? Ich wollte das 6 Tastenswitch ausprobieren und habe den Asksin Ordner in den library ordner platziert daraufhin hat sich der compiler gemeldet, dass die HM6TastenSwitch.h noch nicht integriert ist. Daraufhin habe ich die genannte Header ebenfalls in den AskSin Library Ordner
Woher stammt die "HM6TastenSwitch.h"? aus der New-Asksin? Das dürfte so einfach nicht funktionieren.
Wenn du einen 6-Fach-Taster bauen willst, kannst du dir auch mal diesen Code ansehen und ggf. modifizieren.
https://github.com/kc-GitHub/1-6Fach-Taster
Hier gibts auch einen Tread dazu:
https://forum.fhem.de/index.php/topic,19657.msg132656.html
Den Code wollte ich später auch mal noch auf newAsksin+AES migrieren.
Zitat von: Apicalis am 07 Juli 2016, 14:04:45
Hat jemand eine Ahnung vom Sicherheitsschlüssel?
In hmkey.h kommt dein 16 Byte langer HM-Key rein. Optimalerweise der Default-Key.
Schau mal in "10_CUL_HM.pm" und suche du dort nach "default key"
Alternativ kannst du dort auch direkt den md5-Hash deines Schlüssels eintragen. Dann muss HM_DEVICE_AES_KEY_INDEX aber auch mindestens 02 sein.
HM_DEVICE_AES_KEY_INDEX ist der "Schlüsselzähler mal 2". Bei jedem Schlüsseltausch in der Zentrale wird der eins hochgezählt. HM_DEVICE_AES_KEY_INDEX muss dann aber den Schlüsselindex mal 2 enthalten.
Ein funktionierendes Device mit AES-Fähigkeit habe ich hier:
https://github.com/kc-GitHub/MotorControl
Der zugehörtige Tread ist hier:
https://forum.fhem.de/index.php/topic,51766.msg435421.html
Viele Grüße
Dirk
Zitat von: micky0867 am 07 Juli 2016, 18:20:36
Hallo Martin,
das ist aber quick&dirty.
Ich habe die LEDs weggelassen und die Batterieübewachung dürfte auch nicht tun.
Egal, ich hab's mal hochgeladen:
https://github.com/micky0867/HM_SEC_WDS_AskSin
...und dabei gleich noch was über git gelernt ;-)
Ich habe auch Fotos gemacht, muss mal schauen, ob man die hier oder besser auf Github hochlädt.
Jetzt ist erstmal Fussball angesagt 8)
Micky
Welche Arduino IDE Version verwendest du? Auf der 1.6.6 kompiliert es bei mir nicht aufgrund von diversen Syntax fehlern die scheinbar mit der neuen Version zusammen hängen
Mein Fehler, habe nicht realisiert, dass die alte Asksin library ausschließlich den Atmega328p kann. Auf dem Atmega32U4 lässt es sich so nicht kompilieren. Ich hoffe ich kriege das ganze umgeschrieben und würde dir dann die geänderte Version zukommen lassen Micky damit du deinen GitHub eintrag erweitern kannst.
Hallo zusammen,
ich bin durch Zufall auf die Möglichkeiten gestoßen einen selbst programmierten Arduino mini batteriebetieben zu einem Strom/Gas Zähler aufzubauen.
Beide VerbrauchsZähler sind im Keller - stellt sich das Problem der Übertragung der Werte zur Zentrale die einen CUL mit HM Protokll fährt.
Bennemacs Lösung panstamps zu nehmen habe ich gesehen - scheint gut zu funktioniern.
Ich will praktisch die gleiche Lösung bauen, nur möchte ich die Daten per HM Protokoll übertragen, wenn ich es schaffe mit der ja offensichtlich funktionierenden Schnittstelle asksin, möglichst in der neueren Version - sie scheint mir aufgräumter zu sein.
Mir schwebt vor folgendes umzusetzen:
Der Arduino schläft die meiste Zeit so vor sich hin, wird vielleicht alle 8 Sekunden geweckt und schaut, ob es was zu tun gibt(aufgelaufene Zählerstände nach 15 Minuten als HM-Paket versenden) - parallel horcht der Arduino auf zwei Leitungen, ob sich ein Ereignis am Stromzähler oder am Gaszähler einstellt, wenn ja, dann kurz zählen und wieder hinlegen.
Eventuell noch ein Taster oder PIR, der den Datensammler für x Minute in einen Bereitschaftsmodus wechselt, damit er für die Zentrale ansprechbar wird: sleepmode nicht 8 Sekunden, sondern sleepMode 250ms.
Die Entwicklungsumgebung läuft und ich kann Programme mit NewAskSim übersetzen.
C++ ist nicht so das Problem - löten schon eher, einen nanoCul zu löten hat geklappt.
Es bleibt noch die oben beschriebene Funktionalität in das Protokoll von NewAskSim einzuhängen. Ohne NewAskSim könnte ich fast alles bei Bennemannc oder StefanStrobel abkupfern.
Ich habe bisher verstanden, dass ich etwas bauen muss , dass wie cmBlind, cmDimmer, cmSwitch eingehängt werden muss, oder liege ich falsch.
Das meiste was ich an Beispielen gefunden habe bezog sich immer auf Sensoren.
Wie baue ich aber ein Gerät wie einen cmImpulsCounter oder einen cmButton(Umstellung von 8s auf 250ms) - ConfButton scheint mir nicht so für meine Zwecke zu funktionieren, aber vielleicht habe ich es auch nur falsch verstanden.
Wie nutze ich die Interrupts um kurz auf Impulse vom Strom-/Gaszähler.
Wie und in welcher Klasse versende ich am besten die DatenPakete. Jedesmal die Klasse AS in NewAskSin mit einer neuen send_* Routine zu erweitern, halte ich für nicht so eine gute Idee. Im neuen Klassensystem habe ich noch gar kein Beispiel gefunden(Vielleicht gut versteckt). Gibt es keine allgemeine Funktion der man die zu sendenden Daten einfach übergeben kann.
Kann mir jemand mit Beispielen und Tipps wie man es lösen muss helfen.
Hat niemand Tipps - gute Dokumentation?
ich denke, dass du die fw von dirk nehmen könntest, die für den wasserzähler benutzt wird. https://forum.fhem.de/index.php/topic,47676.0.html (https://forum.fhem.de/index.php/topic,47676.0.html)
ich habe es gerade mal überflogen. hat er wohl noch nicht veröffentlich.
ansonsten nimmst du erst einmal die vom universalsensor und änderst selber.
Danke - das Projekt hatte ich noch nicht gesehen.
Scheint grundsätzlich das zu sein was ich auch möchte nur eben für Strom/Gas - Wasser ist nicht so interessant.
Den UniversalSensor würde ich nicht so gern als Grundlage nutzen. Er basiert noch auf AskSin alt.
Die neue Lib ist wesentlich aufgeräumter und durchdachter. Dirk hat seine Motorsteuerung daruf aufgebaut:
https://github.com/kc-GitHub/MotorControl (https://github.com/kc-GitHub/MotorControl)
Ich habe die Sourcen schon untersucht - habe einiges verstanden, allerdings sind mir noch einige Fragen offen.
Ich würde zum Beispiel gern die rote LED des Stromzählers und den Readkontakt des Gaszählers per Interrupt abfragen. Dann müßte man den Arduino nicht alle 250 ms aufwecken, sondern man könnte die Zeit auf 8s ausweiten.
Die Interrupts sind allerdings in der Software NewAskSin wg. der configTaste schon belegt, so dass ich keine eigene ISR angeben kann.
Dirk hat das scheinbar für MotorControl in NewAskSin umgebaut.
Es gibt ein #define mit der Bedeutung "EIGENER_ISR_1" .
Kann mir jemand die Bedeutung der Methoden trigger11 trigger40 trigger41 erklären.
Es scheint so zu sein, dass in den Methoden vorgfertigte HM-Nachrichen gefüllt werden. Sehe ich das richtig? Ist man in der Erstellung der Nachrichten völlig frei? die Variablen haben manchmal kryptische Namen so dass es schwer zu verstehen ist, was allgemeingültig für cmModule ist bzw. was speziell für MotorControl gemacht wurde.
Zitat von: Linef am 06 Mai 2016, 01:13:26
Die Quellen stehen unter https://github.com/LineF/NewAskSin.git im Branch dev zur Verfügung. Das Hauptmodul des Sensors (mit Schaltplan - ist aber ziemlich identisch zum Universalsensor) liegt unter https://github.com/LineF/HM-Sensor.git, ebenfalls im Branch dev.
Ein Sketch ist es nicht, da ich mit dem Atmel Studio entwickle, aber sollte in der Arduino IDE (nach Rename von main.cpp) auch übersetzbar sein.
Viele Grüße,
Martin
Hi LineF,
du hast den Sensor in GitHub mit Schaltplan. Hast du dir auch Platinen gemacht? Hast du Eagle Files die ich verwenden dürfte? Ich möchte mir ggf. Platinen bestellen und müsste dann nicht alles neu erstellen.
Hallo kadettilac89,
ich habe jetzt noch die Eagle-Files und ein paar Fotos von meinem Sensor ins git-repo hochgeladen.
Wenn die Sourcen ohne Debug compiliert werden, dann ist der Batterieverbrauch jetzt (soweit absehbar) hervorragend. Wenn er dann auch noch so eingestellt wird, daß er nur alle 8 Sek. aufwacht, dann war jetzt bei mir in den vergangenen 2 Wochen kein Spannungsabfall an den Batterien feststellbar (auf 1/100V gemessen). D.h. die Batterien müßten mehrere Jahre halten...
Die Platinen habe ich mir selber gemacht - einseitig. D.h. es gibt einige Drahtbrücken. Vor der Verwendung bei einem professionellen Platinenhersteller muß das Layout allerdings nochmals kontrolliert werden (Bohrdurchmesser, sonst. Abstände etc).
Gruss,
Martin
Zitat von: Linef am 31 Juli 2016, 14:47:58
Hallo kadettilac89,
ich habe jetzt noch die Eagle-Files und ein paar Fotos von meinem Sensor ins git-repo hochgeladen.
Wenn die Sourcen ohne Debug compiliert werden, dann ist der Batterieverbrauch jetzt (soweit absehbar) hervorragend. Wenn er dann auch noch so eingestellt wird, daß er nur alle 8 Sek. aufwacht, dann war jetzt bei mir in den vergangenen 2 Wochen kein Spannungsabfall an den Batterien feststellbar (auf 1/100V gemessen). D.h. die Batterien müßten mehrere Jahre halten...
Die Platinen habe ich mir selber gemacht - einseitig. D.h. es gibt einige Drahtbrücken. Vor der Verwendung bei einem professionellen Platinenhersteller muß das Layout allerdings nochmals kontrolliert werden (Bohrdurchmesser, sonst. Abstände etc).
Gruss,
Martin
Sieht sehr professionell aus. Hilft mir sicher weiter.
Ich hab bei mir die 8sec. schon seit Beginn aktiv. Mein Sensor läuft seit 2 Monaten und Spannung fällt auch nur langsam. Debugging ist noch aktiv, werde ich auch noch ausschalten.
Danke dir!
Hallo Dirk,
danke für den Tipp mit der alten Lib bzw. deinem 1-6 Fach Taster. Möchte nach langer Pause wieder was basteln. Hatte jetzt versucht die alte LIb mit Arduino 1.5.0 bzw. 1.5.2 und 1.6.5 zu kompilieren. Allerdings ohne erfolg. Bekomme die willdesten Fehlermeldung von "no such File" . Dies konnte ich beheben, indem ich die Header und Sources in den Arduino-Ordner kopiert habe. Allerdings fängt er jetzt mit anderen Fehlermeldungen an wie zb. "prog_Uint8t" wäre keine bekannte deklaration usw.
Hättest Du ne Idee, die mir weiter helfen könnte. Kann vielleicht auch an der Version von Arduino liegen. Weiss allerdings nicht welche ich nehmen soll.
Vielen Dank im Voraus.
Dennis
Die alte lib scheint mir nicht so aufgeräumt zu sein wie die neue.
Ich will auf der Basis der neuen lib einen Strom und Gaszähler bauen, ähnlich der hier im Forum auf Basis von panstamps beschriebenen Lösungen.
Kompilieren geht auf der neuesten Version der arduino Entwicklungsumgebung unter Linux ganz gut.
Ich versuche ein wenig mehr OO ins Framework zu bringen. Einige Verbesserungen hätte ich schon, aber solange ich noch im Lernmodus bin, ist noch nichts konkret.
Ich habe aber noch lange nicht alles verstanden. Warte auch noch auf Hardware aus Asien. Löt arbeiten mit dem cc1101 stehen auch noch an.
Als Grundlage verwende ich die Steuerung des Tv-Vorhangs von Dirk.
Er hat wohl noch ein Wasserzähler Projekt in Arbeit.
Die alte lib würde ich nicht mehr verwenden.
Vielleicht können wir uns ja gemeinsam einarbeiten und uns Hilfe bei Dirk und trilu besorgen, wenn wir nicht mehr weiterkommen. Bisher sind meine Fragen eher unbeantwortet geblieben. Ich komme aber auch noch so voran.
Hallo Dietmar,
also denke das dein Wissen schon detailierte als meines ist. Wollte eigentlich den 6Fach-Taster der alten Lib verstehen und in NewAsksin integrieren. Mein ursprüngliches Vorhaben ist es, einen HM_LC_SW4 mit einem 6-Fach-Taster in einem Programm zusammen laufen zu lassen. Weiss auch, dass das wohl ein grosses Vorhaben werden wird, da ich wohl in der CCU bzw. FHEM eine Config anfertigen muss.
Daher benötige ich dringend eine lauffähige Version der alten Asksin. Um diese in Atmel Studio zu integrieren.
Also soweit ich das mit der Relay-Funktion cmSwitch verstanden habe, müsste ich mir eine eigene zb. cmButton bauen, um einen 6 Fach Taster aufzubauen. Bitte korrigiert mich, wenn ich falsch liege.
Da ich in Vergangenheit noch nicht so sehr mit Pointern beschäfftigt habe, werde ich wohl noch einige Zeit brauchen, um überhaupt auf Euren stand zu kommen.
Würde mich gerne beteiligen. Habe auch schon Erfolgreich eigene Platine mit CC1101 geätzt und zum laufen bekommen.
Was aber glaube mein Hauptproblem ist, dass bisher selbst HM noch kein Modul angeboten hat, das beide Funktionen von Wandtaster und Relay-PCB anbietet. Ist mein Vorhaben vielleicht zu hoch gegriffen? BZW. Geht das überhaupt?
Dazu müssten ja Zwei Funktionen Zeitgleich auf einem Arduino laufen. Einmal zb. cmButton mit bw. 4 Tasten und cmSwitch mit bw. 4 Relayausgängen.
Gruß
East
also ich habe auch erst mal mit der alten bib angefangen und schon nach kurzer Zeit keine List mehr gehabt.
Die neue bib ist aus meiner Sicht leichter zu verstehen, weil sie die verschiedenen Hardwarekomponenten klarer abbildet.
Kompilieren geht mit der neuesten Arduino 1.6.9
ZitatWas aber glaube mein Hauptproblem ist, dass bisher selbst HM noch kein Modul angeboten hat, das beide Funktionen von Wandtaster und Relay-PCB anbietet. Ist mein Vorhaben vielleicht zu hoch gegriffen? BZW. Geht das überhaupt?
Das Problem werde ich auch noch lösen müssen, da ic haber in fhem schon mehrre Moduel betreue, glaube ich dass das Problem lösbar ist, wenn erst mal der Rest funktioniert
ZitatDazu müssten ja Zwei Funktionen Zeitgleich auf einem Arduino laufen. Einmal zb. cmButton mit bw. 4 Tasten und cmSwitch mit bw. 4 Relayausgängen.
Das sind den wahrscheinlich mehrer Kanäle in HM.
Was ich aus dem Code herausgelesen habe ist folgendes:
Im Arduino läuft eine Endlosschleife, und ruft immer hm.poll() auf.
hm.poll() fragt intern sämtliche Hardwarekomponenten ab, ob was anliegt oder passiert ist. Darunter sind auch die von dir neu zu bauenden Kanäle/Geräte. Wenn nichts zu tun ist legt sich der Arduino wieder schlafen. Über setpowermode() kann man einstellen wie lange er schlafen soll: gar nicht, 250ms, 8s.
Der Arduino verfällt dann in Tiefschlaf und verbraucht dann praktisch keinen Strom, wichtig für Batteriebetrieb. Gleichzeitig kann man Interrupts auf PINs legen. Immer wenn auf denen dann etwas los ist, wacht der kleine auf und führt ein wenig Code aus. Man kann sich also dann einem Tastendruck merken und im nächsten Aufwachzyklus auswerten.
Wenn du also mehrere Kanäle erzeugt hast, werden sie nach korrekter Registrierung immer per poll() abgefragt. Eigentlich ist vieles von dem was du brauchst schon in der Klasse configButton (NeuAskSin) vorhanden.
ich habe mal eine Grobstruktur von newasksin dokumentiert:
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
register
ee
AS:hm
cmModel:cm (cmBlind, ...)
//Listen
devDef, modTbl, peerTbl, cnlTbl, devIdnt
everyTimerStart (
cmMyBlind.regInHM(1, 3, &hm); // register user module
cmMyBlind.config(&initBlind, &blindUpdateState, eeVars.initialPos);
)
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
cmModel(cmBlind, ...)
peerSingle, peerOdd, peerEven
class cmChannelModel (cmMyBlind) {
// Contains all register from list 1
lstCnl
// Contains all register from list 3
lstPeer
// Contains all register from list 3 without short or long prefix
l3
AS*:hm
void (*fInit)(uint8_t); // pointer
void (*fUpdateState)(uint8_t, uint8_t, uint32_t);
// stati und viele Standardmetheoden + Trigger{11,40,41}
}
}
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
AS:hm {
public:
CB confButton; ///< config button
EE ee; ///< eeprom module
SN sn; ///< send module
RG rg; ///< user module registrar
LD ld; ///< status led
PW pw; ///< power management
CC cc; ///< load communication module
BT bt;
private
RV rv;
struct s_confFlag { // - remember that we are in config mode, for config start message receive
struct s_stcSlice { // - send peers or reg in slices, store for send slice function
struct s_stcPeer {
struct s_l4_0x01 {
}
extern AS hm;
class waitTimer
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
sketch.ino
Setup()
{}
Loop()
{HM.poll() }
ISR()
{cm.LEDBlinkDetected() }
Mein Plan ist es ein cmStromGasImpulsCounter zu bauen, dass 15 Minuten lang Impulse zählt und dann die Ergebnisse in der fhem-Zentrale abliefert. cmStromGasImpulsCounter soll von Superklasse ChannelModel abgeleitet werden, eine Klasse, die gemeinsamen Code aller cm... aufnehmen soll. Schon übersetzbar, aber ich habe noch keine Ahnung davon was spezifsch und was allgemeingültig in einem channel ist. Aber das wird schon noch.
Dazu möchte ich gern die Kontrolle über die Interrupts bekommen, was mir im Moment nicht möglich ist, da die Interrupts schon belegt sind. Muss ich also wahrscheinlich umbauen, hat Dirk in MotorControl auch gemacht.
Bei Tests gestern habe ich es hinbekommen die Ereignisse eines Tasters, eines Reedkontakts und eines Fototransistors per Interrupt zu zählen. Wenn die hardware kommt, geht es das erste mal an die Kommunikation mit der Zentrale über HM.
Also mit deinem Projekt hört sich das schon vielversprechend an. Super.
Ich weiss jetzt gerade nicht (Kann ich nochmal schauen), ob der 328p das kann, aber ich hatte mal ein wenig mit OpenMCP (AtxMega) zu tun.
Dort ist es so, das es verschiedene InterruptHandler gibt, die verschiedene Modis haben. Soll heissen das die Eventabhängig in unterschiedlichen Wichtigkeitsstufen abgearbeitet werden ( Master , Slave usw...). Das wäre, wenn der ATM328p das kann eine möglichkeit, dieses Problem zu umgehen.
Hier ein Auszug des Xmega 128A1....
"29
[Not recommended for new designs - Use
XMEGA A1U series] XMEGA A1 [DATASHEET]
8067O–AVR–06/2013
14.
Interrupts and Programmable
Multilevel Interrupt Controller
14.1 Features
Short and predictable interrupt response time
Separate interrupt configuration and vector address for each interrupt
Programmable multilevel interrupt controller
Interrupt prioritizing according to level and vector address
Three selectable interrupt levels for all interrupts: low, medium and high
Selectable, round-robin priority scheme within low-level interrupts
Non-maskable interrupts for critical functions
Interrupt vectors optionally placed in the application section or the boot loader section"
@Dietmar
Schaue gerade wie der 328p belegt ist. Ich sehe das da noch einige PCINTx frei sind.
Ich habe nicht das Problem, dass es prinzipiell nicht geht.
Es ist aber so dass ich wegen NewAskSin nicht so Zugriff habe wie ich es will. Ich muss aufpassen, das die Logik des ConfigButtons erhalten bleibt, der obendrein an einem Pin hängt, den ich auch nicht genau identifizieren kann.
Vorrangregeln gibt es am 328p nicht.
So stelle ich mir vor, die Interrupts auszunutzen:
/*
Pullup sketch
a switch connected to pin 2 lights the LED on pin 13
*/
#include <PinChangeInt.h>
// #include <PinChangeIntConfig.h>
const int ledPin = 13;
const int reedPin = 2;
const int fotoPin = 3;
const int buttonPin = 4;
volatile byte foto = 0;
volatile byte reed = 0;
volatile byte button = 0;
// output pin for the LED
// input pin for the switch
void setup() {
Serial.begin(57600);
pinMode(ledPin, OUTPUT);
pinMode (fotoPin, INPUT); //set the pin to input
digitalWrite(fotoPin, HIGH); //use the internal pullup resistor
PCintPort::attachInterrupt(fotoPin, fotoCount, RISING); // attach a PinChange Interrupt to our pin on the rising ed
pinMode (reedPin, INPUT); //set the pin to input
digitalWrite(reedPin, HIGH); //use the internal pullup resistor
PCintPort::attachInterrupt(reedPin, reedCount, RISING); // attach a PinChange Interrupt to our pin on the rising ed
pinMode (buttonPin, INPUT); //set the pin to input
digitalWrite(buttonPin, HIGH); //use the internal pullup resistor
PCintPort::attachInterrupt(buttonPin, buttonCount, RISING); // attach a PinChange Interrupt to our pin on the rising ed
}
void loop(){
Serial.print("reedcount:\t");
Serial.print(reed, DEC);
Serial.print(" buttoncount:\t");
Serial.print(button, DEC);
Serial.print(" fotocount:\t");
Serial.println(foto, DEC);
delay(5000);
}
void reedCount() { reed++; digitalWrite(ledPin, HIGH); delay(300); digitalWrite(ledPin, LOW);}
void fotoCount() { foto++; digitalWrite(ledPin, HIGH); delay(100); digitalWrite(ledPin, LOW);}
void buttonCount() { button++; digitalWrite(ledPin, HIGH); delay(100); digitalWrite(ledPin, LOW);}
Ich habe in letzter Zeit ziemlich viel im DevAES Zweig geändert und das PCI handling komplett erneuert.
Der config button wird in hardware.h im Sketch Ordner definiert.
//- configuration key ----------------------------------------------------------------------------------------
#define CONFIG_KEY PIN_B0 // define the config key pin port
Die PC Interrupt functions findest Du in der HAL.h
extern void registerPCINT(uint8_t PINBIT, volatile uint8_t *DDREG, volatile uint8_t *PORTREG, volatile uint8_t *PINREG, uint8_t PCINR, uint8_t PCIBYTE, volatile uint8_t *PCICREG, volatile uint8_t *PCIMASK, uint8_t PCIEREG, uint8_t VEC);
extern uint8_t checkPCINT(uint8_t PINBIT, volatile uint8_t *DDREG, volatile uint8_t *PORTREG, volatile uint8_t *PINREG, uint8_t PCINR, uint8_t PCIBYTE, volatile uint8_t *PCICREG, volatile uint8_t *PCIMASK, uint8_t PCIEREG, uint8_t VEC, uint8_t debounce);
extern uint8_t checkPCINT(uint8_t port, uint8_t pin, uint8_t debounce); // function to poll if an interrupt had happened, gives also status of pin
extern void maintainPCINT(uint8_t vec); // collects all interrupt vectors and maintains the callback address for external pin change interrupt handling
Den zugehörigen code in hal_extern.h.
Wenn Du also einen Interrupt für einen Pin vom 328'er brauchst, dann registriere den Interrupt mit
registerPCINT(PINBIT, DDREG, PORTREG, PINREG, PCINR, PCIBYTE, PCICREG, PCIMASK, PCIEREG, VEC);
oder per Macro mit
registerPCINT(PIN_C0); Die Macros für die PIN's sind in HAL_atmega328.h definiert.
Jetzt kannst die Interrupts per checkPCINT pollen. Pollen wegen des debounce, also Entprellen...
extern uint8_t checkPCINT(uint8_t PINBIT, volatile uint8_t *DDREG, volatile uint8_t *PORTREG, volatile uint8_t *PINREG, uint8_t PCINR, uint8_t PCIBYTE, volatile uint8_t *PCICREG, volatile uint8_t *PCIMASK, uint8_t PCIEREG, uint8_t VEC, uint8_t debounce);
extern uint8_t checkPCINT(uint8_t port, uint8_t pin, uint8_t debounce); // function to poll if an interrupt had happened, gives also status of pin
Wenn kein Entprellen notwendig ist, kannst Du eine Sprungadresse angeben und wirst im User sketch über Interrupts informiert. Dazu in der hardware.h im User sketch Ordner die Zeile
//#define PCINT_CALLBACK // enables the pin change interrupt callback in user sketch
auskommentieren und im User Sketch die Funktion:
void pci_callback(uint8_t vec, uint8_t pin, uint8_t flag) {
//dbg << "cb, vec:" << vec << ", pin:" << pin << ", flag:" << flag << '\n';
}
einbauen.
Ich hoffe das löst Dein Problem.
Viele Grüße
Horst
Hört sich erst einmal gut an!
Danke dafür - sehe ich mir nachher an
@trilu :
Habe die neue Version gefunden. Die Veränderungen scheinen wie für mich gemacht zu sein.
Leider lassen sich die Beispiele nicht übersetzten. Fast immer hat es mit Definitionen EE::xxx zu tun. Kannst du mir erklären wie ich sie lauffähig bekomme.
Zum Teil reicht es const voranzustellen. In manchen Fällen müssen aber mehr Variablen ergänzt werden. Mangels einer
einer Ahnung, was die bedeuteten, weiß ich nicht was ich tun muss
Ich habe die letzten Wochen ziemlich viel an der Lib geändert. Derzeit lässt sich nur der pcb Sketch kompilieren und betreiben. Die anderen Beispiele muss ich erst noch nach Ziehen...
Hallo Trilu,
habe mir mal deine DEV-AES angeschaut. Habe ein Problem die cmSwitch.h zu kompilieren. Diese meckert über die enum.... Einträge für Action und JT usw. Sie würden zu keiner Klasse gehören. Obwohl ich die zugehörigkeit zu cmSwitch sehe.
Hättest da ne Idee?
in cmSwitch.cpp....
zb.: l3>ACTIONTYPE = ACTION::INACTIVE;
Habe das erste Problem so gelöst:
zb.: l3->ACTIONTYPE = cmSwitch::ACTION(INACTIVE);
Des Weiteren kommen wie schon bei Dietmar beschrieben die Konflikte für beispielsweise EE::s_peerTbl peerTbl[] = hinzu.
Selbst auch mit der PCB, die eigentlcih laufen sollte.
Bin gerade in Bella Italia und kann nicht kompilieren. Bin am Samstag wieder zurück. Mit was kompilierst du?
Und welche Fehler gibt das Ding von sich?
OH... Danke für die Antwort. Und auch noch in deinem Urlaub.
Sorry. Aber ich habe versucht mit arduino 1.6.5 und 1.6.4 zu kompilieren. Da ist es so, das der garnicht kompiliert, da das kompilieren bei ca 1/3 kleben bleibt. Bei beiden Versionen auf verschiedenen Rechnern.
Dann habe ich zusätzlich in Atmel Studio 7 mit der Arduino Ide probiert. Dort haut er mir das raus.....
Error conflicting declaration 'EE::s_peerTbl peerTbl []' und....
Error no matching function for call to 'cmRemote::regInHM(int, int, AS*)'
Error conflicting declaration 'EE::s_peerTbl peerTbl []' und....
Error no matching function for call to 'cmRemote::regInHM(int, int, AS*)'
Die Fehler hatte ich auch - hat nix mit dem Compiler zu tun.
Beim ersten Fehler muss man const voranstellen
Beim zweiten Fehler entfällt der dritte Parameter.
etwa so:
const EE::s_peerTbl peerTbl []
...remote[i].regInHM(int, int)
Ich vermute, dass sich in AS einiges geändert hat, die Beispiele aber nicht angepasst wurden.
Bei mir lässt sich pb6 compilieren, aber irgendwie scheint loop() nicht zu laufen
Ich Nutze arduino 1.6.9 auf Linux.
Fehler beim compilieren haben in der Regel nichts mit der Version des Compilers zu tun - glaube ich jedenfalls.
Die nicht ausgeführte loop() hat sich erst einmal geklärt.
Da ich noch kein cc1101 Modul angeschlossen habe, kommt die init() Funktion nicht zum Ende.
Also mein Problem und wahrscheinlich gelöst.
Der init vom cc1101 fängt Fehler nicht ab, deshalb wird init bei einem fehlenden Modul nie beendet. Der pb6 lässt sich vermutlich kompilieren, der ist aber work in progress. Da fehlt noch die komplette Sende Funktion. Der Switch ist das Einzige was im Moment funktioniert. Ich mach nächste Woche wieder weiter...
Ok,
Kein großes Problem - warte jetzt erst mal bis ich mein cc1101 gelötet habe.
Wenn du wieder zurück bist quäle ich dich vielleicht nochmals mit etwas Hintergrundwissen, trigger{40,41,11}. Würde es nicht vielleicht Sinn machen eine Superklasse für alle cmXXXXXX zu bauen. Sie alle haben Methoden, die weitestgehend gleich sind. Und der Pflegaufwand würde sinken.
apropo Senden:
ich habe gesehen, dass die Sendefunktion immer in AS eingebaut werden muss. Macht es nicht Sinn eine SendeFunktion so allgemein zzu schreiben, dass man ihr alles an Nutzdaten mitgeben kann? So, muss man NewAskSin immer wieder verändern.
Ist es überhaupt einfach und damit sinnvoll ein eigenes HM-Gerät zu bauen. Ich müsste ja die gesendeten Datenpakete auch noch in Readings verwandeln. Generisch scheint das in CUL_HM auch nicht zu sein.
Aber erstmal schönen Urlaub in Italien - wäre auch gern dort!
Ich glaube das eine Super Klasse wenig Sinn macht. Die Chanel Module müssen ja alle unterschiedlich auf die Nachrichten, Events reagieren.
Trigger 11, sind Nachrichten die von der Zentrale kommen. Z.b. schalte den Dimmer in 10 Sekunden auf 100%
Trigger 40, wird von Push Button Peers verwendet und liefert nur die Info Peer, Peer Chanel, Long oder Short und einen counter.
Trigger 41, kommt von Peer Sensoren, ähnlich wie Trigger 40 plus ein Byte Sensorwert.
Eigene Geräte in FHEM ist derzeit schwierig, da alle Geräte in HM cul hart verdrahtet sind. Ich nutze aber derzeit Homegear und habe zum erstellen der Config ein destillregs gebaut. Das generiert mir ein entsprechendes Device XML File, das für die CCU und Homegear passt. Vielleicht kann Martin sowas ähnliches in HM cul integrieren. Hat aber noch Zeit, soweit ist die Lib ja noch nicht...
aber ist das ganze so nicht übersichtlicher und für Anfänger einfacher zu verstehen?
ChannelModel (Superklasse) -noch nicht sauber aufgebaut
class ChannelModel {
//- user code here ------------------------------------------------------------------------------------------------------
public://----------------------------------------------------------------------------------------------------------------
...
...
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
// ---------------------------------------------------------------------
void adjRly(void); // setting of relay status
void sendStatus(void); // help function to send status messages
void rlyPoll(void); // polling function
// mandatory functions for every new module to communicate within AS protocol stack ------------------------------------
uint8_t modStat; // module status byte, needed for list3 modules to answer status requests
uint8_t modDUL; // module down up low battery byte
uint8_t regCnl; // holds the channel for the module
AS *hm; // pointer to HM class instance
virtual void firstStart(void) ;
virtual void config(void Init(uint8_t), void Switch(uint8_t,uint8_t)) ; // handover for jump addresses
virtual void poll(void) = 0 ; // poll function, driven by HM loop
virtual void trigger11(uint8_t value, uint8_t *rampTime, uint8_t *duraTime) ; // what happens while a trigger11 message arrive
virtual void trigger40(uint8_t msgLng, uint8_t msgCnt) ; // same for peer messages
virtual void trigger41(uint8_t msgBLL, uint8_t msgCnt, uint8_t msgVal) ; // same for sensor messages
void showStruct(void);
void hmEventCol(uint8_t by3, uint8_t by10, uint8_t by11, uint8_t *data, uint8_t len); // call back address for HM for informing on events
void regInHM(uint8_t cnl, uint8_t lst, AS *instPtr); // register this module in HM on the specific channel
void setToggle(void); // toggle the module initiated by config button
void configCngEvent(void); // list1 on registered channel had changed
void pairSetEvent(uint8_t *data, uint8_t len); // pair message to specific channel, handover information for value, ramp time and so on
void pairStatusReq(void); // event on status request
void peerMsgEvent(uint8_t type, uint8_t *data, uint8_t len); // peer message was received on the registered channel, handover the message bytes and length
void peerAddEvent(uint8_t *data, uint8_t len); // peer was added to the specific channel, 1st and 2nd byte shows peer channel, third and fourth byte shows peer index
};
cmStromGasImpulsCounter
class cmStromGasImpulsCounter : public ChannelModel {
private:
uint32_t lastDataSend = 0;
volatile uint8_t stromEventCounter [bufferLenPlusReserve];
volatile uint8_t gasEventCounter [bufferLenPlusReserve];
public:
virtual void config(void Init(uint8_t), void Switch(uint8_t, uint8_t));
// void init (uint8_t channel); // declare function to jump in
// void switch_ (uint8_t channel, uint8_t status); // declare function to jump in
void registerStromTick();
void registerGasTick();
void sendeDatenAnMaster(uint8_t idx);
virtual void poll() ; //
virtual void trigger11(uint8_t value, uint8_t *rampTime, uint8_t *duraTime) ; // what happens while a trigger11 message arrive
virtual void trigger40(uint8_t msgLng, uint8_t msgCnt) ; // same for peer messages
virtual void trigger41(uint8_t msgBLL, uint8_t msgCnt, uint8_t msgVal) ; // same for sensor messages
};
config key gedrückt - sollte pairing sein:
<- 0E76
<- 0E 00 80 10 33 11 22 00 00 00 06 01 00 00 00 (1834)
und im event Monitor:
2016-08-26 20:27:00 CUL nanoCUL UNKNOWNCODE A0E0080103311220000000601000000::-45:nanoCUL
2016-08-26 20:27:02 CUL nanoCUL UNKNOWNCODE A0E0180103311220000000601C80000::-43.5:nanoCUL
2016-08-26 20:27:05 CUL nanoCUL UNKNOWNCODE A0E0280103311220000000601000000::-40.5:nanoCUL
2016-08-26 20:27:22 Global global UNDEFINED HM_331122 CUL_HM 331122
2016-08-26 20:27:22 Global global DEFINED HM_331122
2016-08-26 20:27:22 Global global SAVE
2016-08-26 20:27:22 CUL_HM HM_331122 D-firmware: 1.0
2016-08-26 20:27:22 CUL_HM HM_331122 D-serialNr: HBswitch01
und ein automatisch angelegter switch:
Internals:
CFGFN
DEF 331122
IODev nanoCUL
LASTInputDev nanoCUL
MSGCNT 1
NAME HM_331122
NR 49
STATE ???
TYPE CUL_HM
lastMsg No:03 - t:00 s:331122 d:000000 10006C4842737769746368303100410100
nanoCUL_MSGCNT 1
nanoCUL_RAWMSG A1A03840033112200000010006C4842737769746368303100410100::-40:nanoCUL
nanoCUL_RSSI -40
nanoCUL_TIME 2016-08-26 20:27:22
protLastRcv 2016-08-26 20:27:22
rssi_at_nanoCUL avg:-40 min:-40 max:-40 lst:-40 cnt:1
Readings:
2016-08-26 20:27:22 D-firmware 1.0
2016-08-26 20:27:22 D-serialNr HBswitch01
Helper:
HM_CMDNR 3
mId 006C
rxType 2
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +331122,00,00,00
nextSend 1472236042.14274
prefIO
rxt 0
vccu
p:
331122
00
00
00
Mrssi:
mNo 03
Io:
nanoCUL -38
Prt:
bErr 0
sProc 0
Q:
qReqConf 00
qReqStat 00
Role:
chn 1
dev 1
prs 1
Rssi:
At_nanocul:
avg -40
cnt 1
lst -40
max -40
min -40
Attributes:
IODev nanoCUL
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-LC-SW1-BA-PCB
msgRepeat 1
room CUL_HM
serialNr HBswitch01
subType switch
webCmd statusRequest:toggle:on:off
sieht das gut aus?
Hallo Jungs ich habe im Serial Monitor folgendes Problem.
polling ch:0
polling ch:1
1h� �����
hm polling
RG polling
polling ch:0
polling ch:1
.:10h� �����
hm polling
RG polling
polling ch:0
polling ch:1
.:18h� �����
hm polling
RG polling
polling ch:0
polling ch:1
.:26h� �����
hm polling
RG polling
polling ch:0
polling ch:1
.:34h� �����
hm polling
RG polling
polling ch:0
polling ch:1
.:43h�
immer wenn der Arduino mit hm.pw.setMode(POWER_MODE_WAKEUP_8000MS); in den Sleepmode versetzt wird, verschluckt der Monitor bzw. der Arduino Zeichen. Kann jemand sagen woran das liegt und ob man das abstellen kann.
habe es so vergeblich versucht:
void loop() {
// - AskSin related ---------------------------------------
delay(100);
dbg << (getMillis()/1000) << F("hm poll ") << "\n";
delay(100);
hm.poll(); // poll the homematic main loop
// - user related -----------------------------------------
}
[code]
@dietmar, drück Mal den Config Key für 2 oder 3 Sekunden. Der Pairing String ist viel länger und enthält die Seriennummer.Beim Sleepmode bin ich mir nicht sicher ob der noch funktioniert. Den habe ich seit langem nicht mehr angefasst. Das er Zeichen verschluckt ist aber normal. Beim Sleepmode wird zuerst allesan IO abgedreht und dann die CPU Schlafen geschickt. Das darunter die serielle leidet ist klar.
Ich habe mir das Modell mit der Oberklasse noch Mal angeschaut, habe aber noch ein Verständnis Problem.
In der class channelmodel wird Poll definiert. Diese Poll wird regelmäßig von hm aufgerufen. Wie ruft Poll die eigentliche Poll Funktion im channelmodul auf?
Selbiges gilt für die Trigger. Trigger40 ist in deinem Beispiel ja definiert über
Void channelModell::trigger40()
Wie rufe ich von dort void cmStromGasImpulscounter::trigger40 auf?
Werde den config key morgen drücken und berichten für heute ist Feierabend.
Bin froh dass das Löten geklappt hat und das die ersten Tests für mich erst mal erfolgreich waren.
Bevor ich anfange zu fabulieren.
hier sind zwei Webseiten, die das hoffentlich gut erklären:
https://de.wikibooks.org/wiki/C%2B%2B-Programmierung:_Polymorphie (https://de.wikibooks.org/wiki/C%2B%2B-Programmierung:_Polymorphie)
http://openbook.rheinwerk-verlag.de/oop/oop_kapitel_05_002.htm (http://openbook.rheinwerk-verlag.de/oop/oop_kapitel_05_002.htm)
Kurz zusammengefasst:
man definiert in der Superklasse Funktionen und kann sie auf dem Abstraktionslevel der Superklasse benutzen. In C++ ist das Schlüsselwort virtual wichtig. In neueren Sprachen ist das Schlüsselwort nicht mehr notwendig da ist einfach alles virtual.
In der Kindklasse kann man die Funktion überschreiben. Wenn dann konkrete Abkömmlinge(cmStromGasImpulscounter) definiert werden und auf dem Abstraktionslevel der Superklasse eine überschriebene Funktion aufgerufen wird, wird immer die Funktion der Kindklasse aufgerufen.
Etwas so - :
void vaterklasse::init(p1,p2) {
_p1 = p1
_p2 = p2
}
void subklasse::init(p1,p2,p3) {
vaterklasse.init(p1,p2);
_p3 = p3
}
Wenn auch der Code aus der Superklasse aufgerufen werden soll(wie im Beispiel), muss man das explizit selbst machen.
Im Grund entsteht durch das hierarchische Klassenmodell so etwas wie eine implizite Delegation der Aufgabenverteilung in der Hierarchie nach oben. Man muss dabei sehr sehr aufpassen was man wie definiert, weil eine Klassenhierarchie sehr statisch ist und nicht leicht verändert werden kann, besonders dann, wenn ersteinmal viel Software darauf basiert.
Aber man muss mal überlegen was man durch die Definition einer Klasse erreichen kann wenn man Mehrfachvererbung nutzt:
Class neueKlasse : klasse1,klasse2,klasse3,klasse4
Dann erbt die neue Klasse alle Funktionen der Väter und Mütter.
Vererbung ist immer dann sinnvoll, wenn Klassen eine gewisse Ähnlichkeit aufweisen.
Beispielsweise ist das bei den restlichen Klassen aus Asksin nicht der Fall: Power hat nichts mit cc1101zu tun.
Aber die Channels sind in vieler Hinsicht ähnlich. Der große Vorteil ist, das der Code, der für alle channel gilt nur einmal existiert und viel einfacher weiterentwickelt und gewartet werden kann.
Der Kommentar in den existierenden channels deutet darauf hin:
//-------------------------------------------------------------------------------------------------------------------------
//- predefined, no reason to touch -
//-------------------------------------------------------------------------------------------------------------------------
void THSensor::regInHM(uint8_t cnl, uint8_t lst) {
Wenn dir das gefällt, helfe ich gern es in Asksin einzubauen. Und ich lerne auch was.
Der Winter ist lang.
have mal zu pairen versucht -kommt leider dieser Fehler:
2016-08-28 11:34:02 CUL_HM HM_331122 D-firmware: 1.0
2016-08-28 11:34:02 CUL_HM HM_331122 D-serialNr: HBswitch01
2016-08-28 11:34:02 CUL_HM HM_331122 R-pairCentral: set_0x513749
2016-08-28 11:34:05 CUL nanoCUL UNKNOWNCODE ERR:CCA
2016-08-28 11:34:11 CUL nanoCUL UNKNOWNCODE ERR:CCA
2016-08-28 11:34:15 CUL nanoCUL UNKNOWNCODE ERR:CCA
im Monitor finde ich das:
debug startet...
SN.
RV.
PW.
debug startet...
HM_LC_SW1_BA_PCB
AskSin-Lib V 0.2.4
AS.
EE.
PowerMode: 0
initRly: 1
....
CC.
123 - ready
HMID: 33 11 22, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 33 11 22 00 00 00 06 01 00 00 00 (1829)
switchRly: 1, 200
<- 0E77
<- 0E 01 80 10 33 11 22 00 00 00 06 01 C8 00 00 (9492)
switchRly: 1, 0
<- 0E74
<- 0E 02 80 10 33 11 22 00 00 00 06 01 00 00 00 (24000)
<- 1A75
<- 1A 03 84 00 33 11 22 00 00 00 10 00 6C 48 42 73 77 69 74 63 68 30 31 00 41 01 00 (33608)
<- 1A72
<- 1A 04 84 00 33 11 22 00 00 00 10 00 6C 48 42 73 77 69 74 63 68 30 31 00 41 01 00 (86496)
10 73 EF CA F7 E4 89 56 23 DD B9 90 6C 48 24 00 A0
getIdxByPeer, cnl:1, peer:51 37 49 00, ret:255
isPeerValid:51 37 49 00, ret:0
x> 10 05 A0 01 51 37 49 33 11 22 00 05 00 00 00 00 00 (87801)
<- 0A73
<- 0A 05 80 02 33 11 22 51 37 49 00 (87822)
10 77 E3 BE CB 90 25 32 1F D9 B5 94 70 4C 28 04 B0
getIdxByPeer, cnl:1, peer:51 37 49 00, ret:255
isPeerValid:51 37 49 00, ret:0
x> 10 01 B0 01 51 37 49 33 11 22 00 05 00 00 00 00 00 (93378)
<- 0A77
<- 0A 01 80 02 33 11 22 51 37 49 00 (93398)
kann jemand damit was anfangen
Das sieht schon ganz gut aus, ich vermute aber, du hast den GDO2 nicht, oder falsch angeschlossen.
Du bekommst einen vollen cc1101 Buffer falsch signalisiert.
<- 0E76
<- 0E 00 80 10 33 11 22 00 00 00 06 01 00 00 00 (1829)
Das 0e76 ist zu viel, da wird was falsches signalisiert.
bist du durch meine Erklärungen zum Thema Vererbung, Super- Kindklasse durchgestiegen?
Es war ein Anfang, bin gerade am Testen. Ist aber viel Arbeit, schmeißt mein delegate Konzept über den Haufen. Könnte aber einfacher für channel Module werden und hoffentlich kleinerer Code.
Der Tipp hat etwas gebracht:
Pairing funktioniert scheinbar:
HMID: 33 11 22, MAID: 00 00 00
<- 0E76
<- 0E 00 80 10 33 11 22 00 00 00 06 01 00 00 00 (1829)
<- 1A77
<- 1A 01 84 00 33 11 22 00 00 00 10 00 6C 48 42 73 77 69 74 63 68 30 31 00 41 01 00 (91130)
<- 1A74
<- 1A 02 84 00 33 11 22 00 00 00 10 00 6C 48 42 73 77 69 74 63 68 30 31 00 41 01 00 (132502)
10 75 F1 CC F9 E2 F7 E0 AD AB 87 66 42 1E FA D6 A0
getIdxByPeer, cnl:1, peer:51 37 49 00, ret:255
isPeerValid:51 37 49 00, ret:0
x> 10 03 A0 01 51 37 49 33 11 22 00 05 00 00 00 00 00 (133050)
<- 0A75
<- 0A 03 80 02 33 11 22 51 37 49 00 (133071)
13 72 EE CB F6 E5 88 57 22 DC B8 9C 7A 57 39 44 2B 30 00 E9
getIdxByPeer, cnl:1, peer:51 37 49 00, ret:255
isPeerValid:51 37 49 00, ret:0
x> 13 04 A0 01 51 37 49 33 11 22 00 08 02 01 0A 51 0B 37 0C 49 (133255)
x0 :02
x2 :0A
x4 :0B
x6 :0C
new masterid
<- 0A72
<- 0A 04 80 02 33 11 22 51 37 49 00 (133289)
0B 73 EF CA F7 E4 89 56 23 DD B9 A6
m> 0B 05 A0 01 51 37 49 33 11 22 00 06 (134047)
<- 0A73
<- 0A 05 80 02 33 11 22 51 37 49 00 (134068)
0E 70 FC C9 F4 E7 8A 55 20 DE B8 95 B9 95 B0
m> 0E 06 B0 11 51 37 49 33 11 22 02 01 C8 00 00 (294655)
<- 0E70
<- 0E 06 80 02 33 11 22 51 37 49 01 01 00 00 6B (294679)
switchRly: 1, 200
0E 71 ED D8 E5 F6 9B 44 31 2F 09 E4 08 E4 A0
m> 0E 07 A0 11 51 37 49 33 11 22 02 01 C8 00 00 (296184)
<- 0E71
<- 0E 07 80 02 33 11 22 51 37 49 01 01 00 00 6A (296208)
switchRly: 1, 0
0E 7E EA D7 E2 89 2C 3B 06 C0 9E 7B 9F 7B B0
m> 0E 08 B0 11 51 37 49 33 11 22 02 01 C8 00 00 (429091)
<- 0E7E
<- 0E 08 80 02 33 11 22 51 37 49 01 01 00 00 6B (429115)
switchRly: 1, 200
0E 7F FB C6 F3 F8 9D 4A 37 31 0F EA 0E EA A0
m> 0E 09 A0 11 51 37 49 33 11 22 02 01 C8 00 00 (429309)
<- 0E7F
<- 0E 09 80 02 33 11 22 51 37 49 01 01 00 00 6B (429333)
0E 7C E8 D5 E0 8B 2E 39 04 C2 9C 79 55 31 B0
m> 0E 0A B0 11 51 37 49 33 11 22 02 01 00 00 00 (432524)
<- 0E7C
<- 0E 0A 80 02 33 11 22 51 37 49 01 01 00 00 6B (432548)
switchRly: 1, 0
switchRly: 1, 200
2016.08.28 20:45:14 3: CUL_HM set HM_331122 off
2016.08.28 20:45:12 3: CUL_HM HM_331122 repeat, level 00 instead of C8
2016.08.28 20:45:12 3: CUL_HM HM_331122 repeat, level 00 instead of C8
2016.08.28 20:45:10 3: CUL_HM set HM_331122 on
2016.08.28 20:42:59 3: CUL_HM HM_331122 repeat, level 00 instead of C8
2016.08.28 20:42:57 3: CUL_HM HM_331122 repeat, level 00 instead of C8
2016.08.28 20:42:56 3: CUL_HM set HM_331122 on
2016.08.28 20:40:15 3: CUL_HM pair: HM_331122 switch, model HM-LC-SW1-BA-PCB serialNr HBswitch01
2016.08.28 20:39:33 2: autocreate: define HM_331122 CUL_HM 331122
2016.08.28 20:39:33 2: CUL_HM Unknown device HM_331122 is now defined
es lag an einer falschen Verbindung de GDO0.
Hatte es wie bei einem nanoCul an einen UNO angeschlossen - GDO2 wird nicht gebraucht und GDO0 muss an D2
#define CC_GDO0 PIN_D2 // GDO0 pin, identify data received on falling edge
<- 0E76
ist aber noch nicht verschwunden - habe aber herausgefunden, dass daschauher den gleichen Wert bekommen hat und auch lange verzweifelt war.
https://forum.fhem.de/index.php/topic,14140.msg341252.html#msg341252 (https://forum.fhem.de/index.php/topic,14140.msg341252.html#msg341252)
Zitat von: trilu am 28 August 2016, 20:18:59
Es war ein Anfang, bin gerade am Testen. Ist aber viel Arbeit, schmeißt mein delegate Konzept über den Haufen. Könnte aber einfacher für channel Module werden und hoffentlich kleinerer Code.
Also virtuelle Methoden sind auf dem 8bit AVR sehr teuer - sprich benötigen relativ viel Code und auch Daten. Ich experimentiere gerade mit Templates rum, um das ganze Device-Channel-Handling einfacher benutzbar zu machen. Eigentlich wollte ich die Entwicklung mindestens bis zum vollwertigen Switch treiben, bevor ich das ganze öffentlich mache. Damit sie Klassen entsprechend stabil sind. Aber da hier gerade wieder Bewegung in die Entwicklung kommt, kann ich vielleicht auch die ein oder andere Idee beisteuern. Der aktuelle Code ist in meinem GitHub zu finden:
https://github.com/pa-pa/AskSinPP.git
Hier mal kurz die Unterschiede zum (New)AskSin Code:
* im Ganzen mehr in C++ Klassen gekapselt
* Timer-Klasse, die Code zu einem bestimmten Zeitpunkt startet / Alarm ausführt
* Channel-Basis-Klasse, die direkt mit dem Flash arbeitet - kein RAM für die Channel-Listen-Kopien benötigt
* Templates zum konfigurieren der Channels eines Devices
* keine "handberechneten Tabellen" für die ChannelDaten nötig, damit einfacher neue Devices aufzusetzen
Wie gesagt, es fehlt noch einiges an Code bis zum funktionierenden Device - aber die grundsätzlichen Ideen sollten schon gut sichtbar sein.
CC<- 0E76
<- 0E 00 A0 10 33 11 22 51 37 49 06 01 00 00 00 (1829)
CC<- 0E76
<- 0E 00 A0 10 33 11 22 51 37 49 06 01 00 00 00 (2151)
CC<- 0E76
<- 0E 00 A0 10 33 11 22 51 37 49 06 01 00 00 00 (2473)
timed out (2773)
0E76 ist kein wirkliches Problem - scheint aus CC zu kommen:
habe am Ende von CC::sndData folgenden debugcode gefunden.
CC habe ich ergänzt um sicher zu sein, dass die Zeile auch wirklich von hier stammt.
#ifdef CC_DBG // only if cc debug is set
dbg << F("CC<- ") << _HEXB(buf[0]) << _HEXB(buf[1]) << '\n';//pTime();
#endif
Zitat0E76 ist kein wirkliches Problem - scheint aus CC zu kommen
Muss ich mir heute noch Mal anschauen, weiß nicht mehr wozu das debug im CC dient.
ZitatAlso virtuelle Methoden sind auf dem 8bit AVR sehr teuer - sprich benötigen relativ viel Code und auch Daten
Ich habe das Mal am pcb Sketch getestet. Ist etwas übersichtlicher geworden, hat aber auch 600 Byte gekostet. Das ist zu viel...
@papa - ich muss mir Mal deinen Ansatz genauer anschauen.
Wie machst du in deinem Ansatz das Konfiguration der Channel Module?
ZitatZitat
Also virtuelle Methoden sind auf dem 8bit AVR sehr teuer - sprich benötigen relativ viel Code und auch Daten
Ich habe das Mal am pcb Sketch getestet. Ist etwas übersichtlicher geworden, hat aber auch 600 Byte gekostet. Das ist zu viel...
ist das nur hinsichtlich der verbrauchten Bytes ein Problem oder auch von der Laufzeit her ein Problem?
Ich war schon lange nicht mehr auf Systemen unterwegs, auf denen man bytes sparen muss.
Man könnte ja den Versuch unternehen die ChannelModel genutzen Methoden nicht per virtual zu beschreiben, sondern als Delegate-Klasse zu nutzen:
call ChannelModel::regInHM(...)
call ChannelModel::sonstwiefunktion(...)
Dann sit das ganze Übersichtlicher und muss nicht in jeder cmChannelKlasse als Kopie vorliegen.
Dem ChannelModell müßte man dann die triggerFunktionen als callback mitgeben.
Laufzeit ist egal, zumindest ist mir nichts aufgefallen. Das Problem ist die Code Größe.
Der PCB Sketch ist derzeit schon bei 70% Nutzung. Wenn jetzt noch ein 2 Tasten Remote dazukommt sind wir vermutlich bei 80%.
Wenn der 2 Tasten Remote dann auch noch Touch sein soll, brauchen wir noch die I2C Funktionen, naja, und irgendwann ist Speicher Ende :-)
Ok, verstanden.
Was verursacht den umfangreichen Code.
Sind das Bibliotheken, die zugebunden werden, oder ist es AS und die Schwesterklassen?
Eine Schwesterklasse Channelmodel sollte noch drin sein vor allem dann, wenn mehre cmChannelmodelle den gleichen Code teilen können.
Apropos:
Wenn HM_LC_SW1_BA_PCB scheinbar anlernbar ist, müsste ich dann on/off schalten können. Ich glaube ich bekomme immer "missing acknoledge".
Vielleicht findet ihr in Papas Ansatz noch interessante Lösungen die dann in NewAskSin einfließen. Die Sache mit den channel Definitionen habe ich auch noch nicht gefressen.
ich vermute das die codegröße aus dem überschreiben von einigen virtual functions kommt. den rest hatte ich ja soweit bereinigt, also wirklich vergleichbar gemacht.
kannst ja mal testen, habe die virtual class sache hochgeladen...
ansonsten, ja, wenn du pairen kannst muss auch remote schalten gehen.
Zitat von: trilu am 30 August 2016, 07:57:00
@papa - ich muss mir Mal deinen Ansatz genauer anschauen.
Wie machst du in deinem Ansatz das Konfiguration der Channel Module?
Im Prinzip wird alles durch Zusammenstecken der Templates konfiguriert. Den Rest macht dann der Compiler - erlöst alles auf. Z.B. die List1 des Switches aus meiner Testimplementierung. Den Start macht die SwitchList1Data Klasse. Sie definiert das Datenlayout der Liste sowie die Mapping-Funktionen von Offset zu Register und umgekehrt. Die Datenmember könnte man sich auch noch sparen, aber ich mache lieber sizeof() als selber rechnen. Die eigentliche Liste wird duch das Anlegen der ChannelList<SwitchList1Data> definiert. Im Prinzip kommt hier nur die EEProm-Adresse rein, bei welcher die Listedaten liegen. Außerdem gibt es hier die Methoden zu Lesen und Schreiben der Daten im EEProm. Ein Channel wird dann durch den Listen1Typ, den Listen3Typ sowie die Anzahl der Peers definiert. Außerdem kommt noch die Statemachine dazu, die immer switchState() aufruft, wenn eine Zustandsänderung gemacht wird. Das wird dann überladen, um die Pins zu schalten.
class SwitchChannel : public Channel<SwitchList1,SwitchList3,4>, public SwitchStateMachine
Das Device wird wieder mit den ChannelDatenTyp und die Anzahl der Channel definert. Als Argument kommt die Startadresse im EEProm. Von hier aus werden alle EEPromAdressen berechnet.
MultiChannelDevice<SwitchChannel,4> switchdev(0x20);
Derzeit geht das Pairen und einfache Schalten schon. Bei einem 4 Channel Switch komme ich auf folgende Code/Daten Größen:
Program: 12746 bytes (38.9% Full)
(.text + .data + .bootloader)
Data: 584 bytes (28.5% Full)
(.data + .bss + .noinit)
Ist also noch ganz gut Luft - aber auch noch nicht alles drin. So ich hoffe, hiermit kann man den Code (leider noch voll unkommentiert) besser verstehen.
@ trilu:
ich versuche über die Funktion pci_callback(vec, bInt, pcint_vector_byte[vec].curr & bInt);
den Vector, den Pin und die Funktion falling/raising/... herauszufinden.
Kann es sein, dass die Funktion maintainPCINT nicht funktioniert?
Das Ergebnis für den gleichen Pin variert:
Für PIN_C0 bekomme ich:
cb, vec:1, pin:0, flag:0
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:0, flag:0
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:0, flag:0
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:0, flag:0
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:0, flag:0
cb, vec:1, pin:2, flag:2
und für PIN_C1 kommt
cb, vec:1, pin:3, flag:2
cb, vec:1, pin:3, flag:2
cb, vec:1, pin:3, flag:2
cb, vec:1, pin:3, flag:2
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:3, flag:2
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:3, flag:2
cb, vec:1, pin:2, flag:2
cb, vec:1, pin:2, flag:2
vec scheint zu stimmen, pin und flag sehen komisch aus.
void maintainPCINT(uint8_t vec) {
pcint_vector_byte[vec].curr = *pcint_vector_byte[vec].PINR & pcint_vector_byte[vec].mask; // read the pin port and mask out only pins registered
pcint_vector_byte[vec].time = getMillis(); // store the time, if debounce is asked for
#ifdef PCINT_CALLBACK // callback only needed if defined in hardware.h
uint8_t bInt = pcint_vector_byte[vec].curr ^ pcint_vector_byte[vec].prev; // evaluate the pin which raised the interrupt
pci_callback(vec, bInt, pcint_vector_byte[vec].curr & bInt); // callback the interrupt function in user sketch
#endif
}
ich habe es jetzt ersteinmal so gemacht:
void PCint(uint8_t port) {
uint8_t bit;
uint8_t curr;
uint8_t mask;
uint8_t pin;
// get the pin states for the indicated port.
curr = *portInputRegister(port+2);
// dbg << "curr: " << curr << "\n";
mask = curr ^ PCintLast[port];
// dbg << "mask: " << mask << "\n";
PCintLast[port] = curr;
// mask is pins that have changed. screen out non pcint pins.
if ((mask &= *port_to_pcmask[port]) == 0) {
return;
}
// mask is pcint pins that have changed.
for (uint8_t i=0; i < 8; i++) {
bit = 0x01 << i;
if (bit & mask) {
pin = port * 8 + i;
pin = i;
dbg << "port: " << port << " pin: " << pin << " rising " << ((curr & bit) == 0) << "\n";
#ifdef PCINT_CALLBACK // callback only needed if defined in hardware.h
pci_callback(port, pin, ((curr & bit) == 0)); // callback the interrupt function in user sketch
#endif
}
}
}
/**
* @brief This function is called from the different interrupt vector functions while an interrupt
* had happened. Within this function we check also if there is a callback for an interrupt registered.
*
* @param vec Is the vector byte, were the interrupt comes from
*/
void maintainPCINT(uint8_t vec) {
PCint(vec);
pcint_vector_byte[vec].curr = *pcint_vector_byte[vec].PINR & pcint_vector_byte[vec].mask; // read the pin port and mask out only pins registered
pcint_vector_byte[vec].time = getMillis(); // store the time, if debounce is asked for
//#ifdef PCINT_CALLBACK // callback only needed if defined in hardware.h
//uint8_t bInt = pcint_vector_byte[vec].curr ^ pcint_vector_byte[vec].prev; // evaluate the pin which raised the interrupt
//pci_callback(vec, bInt, pcint_vector_byte[vec].curr & bInt); // callback the interrupt function in user sketch
//#endif
}
//- -----------------------------------------------------------------------------------------------------------------------
void pci_callback(uint8_t vec, uint8_t pin, uint8_t flag) {
char pinString [3];
// hm.pw.stayAwake(100);
pinString[0] = 'B' + vec;
pinString[1] = '0' + pin;
pinString[2] = 0;
dbg << "cb, vec:" << vec << ", pin:" << pin << ", flag:" << flag << " PIN_" << pinString << '\n';
}
das ist das Ergebnis:
port: 0 pin: 0 rising 1
cb, vec:0, pin:0, flag:1 PIN_B0
port: 1 pin: 0 rising 1
cb, vec:1, pin:0, flag:1 PIN_C0
port: 1 pin: 1 rising 1
cb, vec:1, pin:1, flag:1 PIN_C1
Eigentlich funktioniert sie schon, sie hat nur mehr Flags
* This functions returns a 3 for a raising edge, 2 for a falling edge, 1 if no interrupt had happend and the pin is high
* and a 0 if the pin is low.
Ich versuche beide Algorithmen zu verstehen.
Vielleicht funktioniert sie ja, nur ich habe noch nicht geblickt wie.
Zitat von: Dietmar63 am 04 September 2016, 07:05:42
Ich versuche beide Algorithmen zu verstehen.
Vielleicht funktioniert sie ja, nur ich habe noch nicht geblickt wie.
hab's versucht, bin aber noch nicht sicher ob ich es verstanden habe.
in in der callback funktion kommt dies an. Welcher pin hat dann wie gefeuert?
Wie bekomme ich es aus den Parametern heraus?
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:3, flag:1
cb, vec:1, pin:3, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:3, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:3, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:3, flag:1
cb, vec:1, pin:1, flag:1
cb, vec:1, pin:1, flag:1
registriert habe ich C0 und C1.
Hi,
ich möchte ein bestehendes Modul anpassen und finde zu einem Teil nichts ...
Irgendwo werden die Devicetypes definiert damit diese dann in FHEM erkannt werden. Im bestehenden Modul sehe ich das hier ...
# $HMConfig::culHmModel{'F101'} = {name => 'HB-UW-Sen-THPL-I', st => 'THPLSensor', cyc => '00:10', rxt => 'l:w:c:f', lst => 'p', chn => '',};
$HMConfig::culHmModel{'F201'} = {name => 'HB-UW-Sen-TH-Pn', st => 'THPnSensor', cyc => '00:10', rxt => 'w:c', lst => 'p', chn => '',};
Es ist in HMConfig_SenTH.pm von LineF enthalten, ist aber eine allgemeine Frage.
Wo muss ich das definieren wenn ich mir z. B. ein HB-UW-Sen-THP-Pn mit F301 bauen möchte? Gibt es hierzu eine Anleittung oder ein Template in dem das gut dokumentiert ist?
Danke im Voraus!
Meines Erachtens wird das meiste in der Datei selber definiert (und nur ein Teil aus HMConfig.pm übernommen).
Ein weiterer Teil scheint dann in 10_CUL_HM.pm hart codiert zu sein (z.B. bei einem RT-DN)...
Hier die Grundparameter des Devices:
$HMConfig::culHmModel{'F201'} = {name => 'HB-UW-Sen-TH-Pn', st => 'THPnSensor', cyc => '00:10', rxt => 'w:c', lst => 'p', chn => '',};
Hier dann die Register - soweit sie nicht bereits in der HMConfig.pm definiert sind
$HMConfig::culHmRegDefine{'lowBatLimitTH'} = {a=>18.0,s=>1.0,l=>0,min=>1.0,max=>5,c=>'',f=>10,u=>'V',d=>0,t=>'Low batterie limit, step 0.1 V.'};
$HMConfig::culHmRegDefine{'oscCal'} = {a=>35.0,s=>1.0,l=>0,min=>0,max=>255,c=>'',f=>'',u=>'',d=>0,t=>'OSCCAL: calibration value of controller frequency'};
Dann noch, welche Register das Device haben soll.
Wobei - da gebe ich Dir schon recht - ich auch nicht weiß, wo die restlichen "Standard"-Register her kommen; es sind ja tatsächlich mehr, als hier gelistet (zumindest das pairCentral)
# Register model mapping
$HMConfig::culHmRegModel{'HB-UW-Sen-TH-Pn'} = {
'burstRx' => 1,
'lowBatLimitTH' => 1,
'ledMode' => 1,
'transmDevTryMax' => 1,
'oscCal' => 1
};
Hmmm, ist das hier nur für die "Description" da?
# subtype channel mapping
$HMConfig::culHmSubTypeSets{'THPnSensor'} = {
'peerChan' => '0 <actChn> ... single [set|unset] [actor|remote|both]',
'fwUpdate' => '<filename> <bootTime> ...',
'getSerial' => '',
'getVersion' => '',
'statusRequest' => '',
'burstXmit' => ''
};
Und dann kommt die Funktion, die die übertragenen Bytes wieder auseinanderpfriemelt...
# Subtype spezific funtions
sub CUL_HM_ParseTHPnSensor(@){
my ($mFlg, $frameType, $src, $dst, $msgData, $targetDevIO) = @_;
...
Wobei mir bislang noch nicht klar ist, wie ich jetzt Register pro Peer definieren kann.
Im Device habe ich sie schon mal angelegt, aber wie muss ich sie hier definieren, damit ich sie dann auch per Kommando setzen kann?
Vielleicht kann ja martinp876 hier uns einen Tip geben?
Martin
Zitat von: Linef am 10 September 2016, 21:55:23
Meines Erachtens wird das meiste in der Datei selber definiert (und nur ein Teil aus HMConfig.pm übernommen).
Ein weiterer Teil scheint dann in 10_CUL_HM.pm hart codiert zu sein (z.B. bei einem RT-DN)...
Hier die Grundparameter des Devices:
$HMConfig::culHmModel{'F201'} = {name => 'HB-UW-Sen-TH-Pn', st => 'THPnSensor', cyc => '00:10', rxt => 'w:c', lst => 'p', chn => '',};
Hi Martin,
vielen Dank für die ausführliche Antwort! Ich dachte ich muss das culHmModel noch irgendwo (device-xml?) definieren. Scheinbar nicht.
Wollte dein Modul auf BME280-Sensor umbauen und ein eigenes THP-Modul bauen. Mehr um das ganze zu verstehen, könnte natürlich auch das F101-Modul vom Wettersensor (trilu?) nehmen und einfach Helligkeitswert ignorieren.
Naja, der BME280 streut mehr als 2°C nach oben, Illusion alles klein und mit einem genauen Temp-Sensor aufzubauen erstmal weg. Bin enttäuscht da der BME-Sensor im Internet wegen der Genauigkeit hoch gelobt wird. Gibt etliche Foren in denen das behandelt wird, scheinbar müsste der Sensor neu kalibriert werden wenn er zu heiß gelötet wurde (Reflow).
Zitat von: Tom71 am 04 Juni 2016, 10:51:41
- Kompilieren mit Arduino IDE für "Arduino Pro or Pro Min, 3.3V, 8Mhz)
- Umwandeln der hex-> eq3
- Flashen per OTA
Dann kommt auf der Console:
AskSin OTA Bootloader V0.7.0
Start App ˜,¿§¿£ÍÞ¿¬�¿ Þ�ãÓ£ÑÞ]œÑ
Die Kompiler-Params sind:
avr-g++" -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10609 -DARDUINO_AVR_PRO -DARDUINO_ARCH_AVR "-IC:arduino" "-IC:eightanaloginputs" "HM-Sensor-DS.ino.cpp" -o "nul"
Hi Tom71,
hast du das OTA hinbekommen? Wenn ja, welchen Boatloader und nach welcher Anleitung hast du ihn geflasht?
Um besser das Verhalten eines Arduinos hinsichtlich WDT und powerDown verstehen zu können habe ich mir folgendes kleines TestProgramm gebaut:
/*
*/
#include <PinChangeInt.h>
#include <avr/wdt.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>
#define offBrownOut() MCUCR = (1<<BODS)|(1<<BODSE); MCUCR = (1<<BODS);
#define backupPwrRegs() uint8_t xPrr = PRR; PRR = 0xFF;
#define recoverPwrRegs() PRR = xPrr;
const int testLed = 3;
const int ledPin = 13;
const int pirPin = 14;
int WDTtime = 0;
long tim = 0;
volatile int pir;
volatile int wdt;
int wdtold = -1;
void wdtEnable (uint8_t period, uint8_t interrupt) {
wdt_enable(period);
if (interrupt == 1) {
WDTCSR |= (1 << WDIE);
Serial.print("setting interrupt: ");
Serial.print(interrupt);
Serial.println("");
Serial.flush();
}
WDTtime = 2 << (period + 3); // in Millisekunden
}
void setup() {
Serial.begin(57600);
Serial.print("starting pirWDTtest");
Serial.print("\tms:\t");
Serial.print(millis());
Serial.println("");
Serial.flush();
pinMode(ledPin, OUTPUT);
pinMode (pirPin, INPUT); //set the pin to input
PCintPort::attachInterrupt(pirPin, pirCount, RISING); // attach a PinChange Interrupt to our pin on the rising ed
//delay(500);
sei();
}
void loop(){
unsigned long now = millis();
if (wdt != wdtold) {
Serial.print(" pircount:\t");
Serial.print(pir);
Serial.print("\twdtcount:\t");
Serial.print(wdt);
Serial.print("\tms:\t");
Serial.print(tim);
Serial.print("\mod:\t");
Serial.print(now % 1000);
Serial.print(" ");
Serial.print(WDTtime);
Serial.println("");
}
Serial.flush();
ADCSRA = 0; // disable ADC
// #################
if (wdt != wdtold) {
if (wdt>0 && wdt%5 == 0) {
//wdtEnable (1, 0);
wdtEnable (9, 1);
} else {
wdtEnable (9, 1); // 16*2^period ms als interrupt
}
}
wdtold = wdt;
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
cli();
if (1)
{
sleep_enable();
sleep_bod_disable();
sei();
sleep_cpu();
sleep_disable();
}
sei();
Serial.print("... wieder wach");
Serial.println("");
Serial.flush();
// #################
}
void pirCount()
{ pir++; /* voltAus(); */ digitalWrite(ledPin, HIGH); delay(10); digitalWrite(ledPin, LOW);}
ISR(WDT_vect)
{
wdt++;
tim += WDTtime;
// wdt_reset(); // reset watchdog counter
// WDTCSR |= (1<<WDIE); // reenable interrupt to prevent system reset
// WDIE & WDIF is cleared in hardware upon entering this ISR
// wdt_disable();
}
Es startet den WDT-Timer des A. für 8 (Code 9) Sekunden und vesetzt ihn in den SLEEP_MODE_PWR_DOWN Zustand.
Ohne PIN-Change-Interrupt passiert das Erwartete. Der Arduino wacht alle 8192 ms auf und gibt über Serial die eine Zeile mit den Variablen aus.
Wenn ich aber den PIN-Change-Interrupt (Zeile 75) aktiviere passiert etwas Unerwartetes: Wenn über pirPin ein Interrupt ausgelöst wird, wacht der A. auf(ok!), arbeitet den Interrupt über die Routine picCount() ab, legt sich dann aber nicht!!! schlafen, sondern fährt mit der Hauptschleife loop() fort und gibt unerwarteter Weise eine Zeile aus und startet den timer neu. Das lässt sich nur mit der kleinen (schon eingebauten) Sonderlogik über wdtold abfangen.
Ist dieses Verhalten bekannt?
Wenn das immer so ist, bedeutet das, dass wenn man im (New)AskSin Interrupts verarbeitet, die Zeitmessungen auch über getMillis() nicht stimmt:
Ein Interrupt wird irgendwann ausgelöst, die bis dahin vergangene Zeit wird nicht berechnet aber der Timer wird neu gestartet. Im Mittel müssten pro Interrupt bei 8s WDTs 4 Sekunden verloren gehen.
Oder befinde ich mich mit meinen Vermutungen irgendwie auf einem Holzweg?
Da hast Du Recht. Es ist nicht ohne weiteres möglich rauszufinden, warum man aus dem Power down zurückgekehrt ist. Vor allem ist es (zumindest mir) nicht bekannt, wie man rauskriegt, wieviel Zeit inzwischen vergangen ist. Das geht sicherlich nur über eine externen Uhr.
... Oder man macht es wie ich dem Beispiel oben : man startet den Watchdog nur dann neu, wenn wdt und wdtold sich unterscheiden. Dann ist sichergestellt, dass der Watchdog timer abgelaufen ist.
Die Zeit wird dann auf Basis des 128k wdt timers berechnet
Trotzdem weisst Du nicht, wie lange der Sleep gedauert hat und wieviel millis Du korregieren musst.
Doch ich bin schon der Meinung, dass man die Zeit einigermaßen gut messen kann, weil sie nur in
ISR(WDT_vect) aufsummiert wird.
NewAskSin startet bei einem Interrupt den timer nur jedesmal neu und dadurch kommt es zu Fehlern.
Das weitere Problem ist, dass Watchdog timer mit 128khz bestimmt ungenauer ist als der 16Mhz Timer.
Ja, der WD-Timer ist z.T. katastrophal ungenau (5-8% daneben).
Ich habe mir deshalb eine automatische Kalibrierung dazu gebaut.
Die ermittelt mit Hilfe des normalen (RC-genauen) 1ms-Timers die wirkliche Laufzeit zwischen dem Start und dem Ablauf des WD-Timers. Und dann wird eben im WDT-ISR nicht z.B. 256ms dazu addiert, sondern 278...
Und den RC-Oszillator kalibriere ich über ein eigenes Register. Damit bekomme ich genügend Genauigkeit hin, um die Empfangsfenster eines HM-CC-RT-DN zu treffen.
Ich hätte auch gerne den Quarz als Timer verwendet, aber dann kann ich mit dem Power-Down-Modus nicht so weit runter fahren - der Quarz-Oszillator muß weiter laufen und der braucht einiges mehr an Strom als nur der WDT.
Bei Batteriebetrieb versucht man halt, alles Mögliche einzusparen.
Auch eine Lösung mit dem separaten Uhrenquartz geht nicht - zumindest hatte ich keine verwertbare Idee...
Martin
Danke, dass bestätigt meine Vermutung.
Kannst du auch die von mir beschriebene Problematik mit den Interrupts bestätigen?
Dass ein Interrupt mit laufenden Watchdog timer nicht nur den ISR ausführt, sondern auch die
Hauptschleife loop() weiterführt. Eigentlich dürfte in ihr der Arduino nur sofort wieder schlafen gelegt werden.
In den meisten Fällen wird aber der Watchdog timer neu gestartet. In diesen Fällen kann man dann nicht sagen wieviel Zeit vergangen ist.
In NewAskSin kann man debugging per
dbg << xxx << yyy << zzz << aaa;
Über den seriellen Anschluss durchgeführen.
Ich finde einfach nicht den Code, um dies in eigenen Projekten zu nutzen.
Kann mir jemand auf die Sprünge helfen.
Hallo Dietmar,
wenn der Atmel schlafen gelegt wurde, kann er über verschiedene Ereignisse aufgeweckt werden, z.B. WD-Interrupt oder PC-Interrupt.
Das bedeutet aber nicht, daß er nur die ISR abarbeitet und sich dann wieder schlafen legt.
...er wird aufgeweckt...und läuft dann komplett, bis er irgendwo per sleep-Kommando wieder zur Ruhe geschickt wird.
D.h. nach einem PC-Int wird zwar die ISR abgearbeitet, aber er ist danach wach und damit kommt er auch im Power-Modul ans Ende der Routine, kehrt von dort zurück und ist in der Main-Loop des AS-Moduls...
Also ganz normales Verhalten.
"dbg" ist ein Alias für "Serial" - definiert in macros.h.
Serial kommt aus den Arduino-Files HardwareSerial*
Viele Grüße,
Martin
Ok, versuche ich dort mein Glück
Danke Dietmar
Zum Thema WDT und PCINT nochmal:
Im Normalfall wird der PCINT in der NewAskSin nur durch den Config-Taster ausgelöst - und das ist recht selten der Fall.
Damit tritt das "falsche Weiterzählen" vergleichsweise selten auf.
Grundsätzlich ist die Problematik m.E. schwer lösbar. Wenn der Atmel wach ist, soll ja der 1ms-Timer verwendet werden.
Wenn beispielsweise durch einen PCINT der Atmel schon früher aufgeweckt wird, müßte man den WDT noch zu Ende laufen lassen um festzustellen, wieviel ms nach dem PCINT der WD-INT kommt. Nur so wüßte man, wieviele ms nach dem Start des WDT der PCINT auftrat.
Anschließend müßte man den normalen 1ms-Timer "nachkorrigieren". Das beeinflußt dann aber wieder bereits gestartete Timer aus der Timer-Klasse, so daß diese Timings dann nicht mehr stimmen...
Martin
ja, so in etwa habe ich mir das gedacht.
daran erkennt man, dass der Atmel dafür nicht designt wurde.
Zitat
Wenn beispielsweise durch einen PCINT der Atmel schon früher aufgeweckt wird, müßte man den WDT noch zu Ende laufen lassen um festzustellen, wieviel ms nach dem PCINT der WD-INT kommt. Nur so wüßte man, wieviele ms nach dem Start des WDT der PCINT auftrat.
genau so habe ich es im Beispielscetch gemacht. Ich habe ihn einfach weiterlaufen lassen und in der ISR 8192ms addiert. Das passt einigermaßen.
Mein Problem ist, dass ich die Blinks einer Fotodiode zählen will(500Hz/KWH). Alle 5 Mintuen sollen dann Meldungen über den Stromverbrauch an die FHEM-Zentrale gehen. Es soll im Prinzip ein Nachbau des
HM-ES-TX-WM werden. Der liefert fertige Leistungswerte, die kann man nur mit vernünftigen Zeitbezug errechnen. Ich könnte die Logik in die Zentrale verlagern, dann müsste ich aber dort
HM-ES-TX-WM verändern.
Im Moment hat sich allerdings herausgestellt, dass meine LED am Stromzähler nicht hell genug ist deshalb baue ich einem LM4250 dazwischen. Mal sehen ob es damit klappt. Die Schaltung und der Scetch funktionieren schon. Habe es mit einer LED probiert, die der A. selbst in sehr kurzen Abständen schaltet. 5 Blinks pro Sekunde waren kein Problem.
Wie hast du die Kalibrierung des WDT timers gebaut?
Für
Serial << "xxx" << "yyy" << "zzz\n" ist folgende Zeile erforderlich:
template<class T> inline Print &operator <<(Print &obj, T arg) { obj.print(arg); return obj; }Damit klappt es.
Danke Dietmar
Eigentlich ganz einfach:
void calibrateWatchdog() { // initMillis() must have been called yet
uint8_t sreg = SREG; // remember interrupt state (sei / cli)
wdt_cal_ms = 0;
startWDG250ms();
uint16_t startMillis = getMillis();
wdt_int = 0;
wdt_reset();
sei();
while(!wdt_int) // wait for watchdog interrupt
;
SREG = sreg; // restore previous interrupt state
wdt_cal_ms = getMillis() - startMillis; // wdt_cal_ms now has "real" length of 250ms wdt_interrupt
stopWDG();
dbg << F("wdt_cal: ") << wdt_cal_ms << F("\n");
}
ISR(WDT_vect) {
// nothing to do, only for waking up
addMillis(wdtSleep_TIME);
wdt_int = 1;
}
void startWDG250ms(void) {
WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = (1<<WDIE) | (1<<WDP2);
wdtSleep_TIME = wdt_cal_ms;
}
void startWDG8000ms(void) {
WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = (1<<WDIE) | (1<<WDP3) | (1<<WDP0);
wdtSleep_TIME = wdt_cal_ms * 32;
}
In der Kalibrierungsroutine Flag (das wird in der WD-ISR gesetzt) zurücksetzen, WDT auf 0 setzen, aktuellen 1ms-Counter merken, Interrupts freigeben und auf gesetztes Flag warten. Dann kann die wirkliche WD-Laufzeit anhand des 1ms-Counters berechnet werden.
Diesen Wert dann für die künftigen Korrekturen in der WD-ISR merken.
Martin
Danke für den Code!
Damit werde ich mal testen - kann man ja fest im setup() einbauen.
Dann wird automatisch auf neuer Hardware kalibriert.
Gruß Dietmar
Zitat von: kadettilac89 am 18 September 2016, 09:44:14
Hi Tom71,
hast du das OTA hinbekommen? Wenn ja, welchen Boatloader und nach welcher Anleitung hast du ihn geflasht?
Ja, hier ist mein Flash-Workflow:
- Kompilieren des Bootloaders mit der Änderung der Serial und HM-ID in devices/HB-UW-Sen-THPL.h
- make clean HB_UW_Sen_THPL -> Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex
- Dann flashen des OTA-Bootloaders mit meinem Raspi:
sudo bin/avrdude -Cbin/avrdude.conf -p m328p -P gpio -c gpio -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m -e -Uflash:w:Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex:i - Dann mit Arduino-IDE die Software übersetzt und per OTA geflashed:
./flash_ota.sh HM-Sensor-UWS7475130.hex UWS7475130
#!/bin/bash
FILE_NAME=$1
php hex2eq3.php --inFile $FILE_NAME --outFile $FILE_NAME.eq3 --spmPageSize 128 --outFormat eq3 --withCrcCheck --pathTo-srec_cat /usr/local/bin/srec_cat
sudo flash-ota -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03VVGB-if00-port0 -f $FILE_NAME.eq3 -s $2
Hier nochmal etwas ausführlicher der erste Teil: https://tom71blog.wordpress.com/2016/05/13/universalsensor-fuer-homematic/
Zum flashen über OTA muss man das hex-File in ein eq3-File umwandeln, daher der Weg über hex2eq3.php und srec_cat
Zitat von: Dietmar63 am 26 September 2016, 11:19:54
Danke für den Code!
Damit werde ich mal testen - kann man ja fest im setup() einbauen.
Dann wird automatisch auf neuer Hardware kalibriert.
Gruß Dietmar
Danke nochmals für den Code.
Habe ihn als Grundlage für ein eigenes kleines Testprogramm genutzt, und beim normalen Arduino eine Abweichungen von 11.34% ermittelt. Mal sehen wie es mit dem Mini aussieht.
Danke dir!
Gruß Dietmar
Hallo,
brauche eure Hilfe. Ich möchte eine alte Wetterstation mit dem Universalsensor auf homematic umrüsten. Das Ganze soll wie eine HM-WDS100-C6-O funktionieren.
http://www.fhemwiki.de/wiki/HM-WDS100-C6-O_Funk-Kombi-Sensor_OC3 (http://www.fhemwiki.de/wiki/HM-WDS100-C6-O_Funk-Kombi-Sensor_OC3)
Könnt Ihr mir bei der Definition der register.h helfen? Wie bekomme ich die verschiedenen Werte in die payload?
Ganz super wäre es, wenn ich ein Beispiel bekäme, bei dem z:b. Temperatur, Luftdruck als Konstanten verschickt werden. Anpassen an die verschiedenen Sensoren
und den Regenmengenmesser würde ich mir zutrauen, aber wie die register.h aussehen muß bekomme ich nicht hin (-> Parameterliste).
Als Entwicklungssystem verwende ich einen Arduino Mini mit der newAsksin Library. Die Firmware wird dann über ein FTDI Modul auf den Arduino geladen.
Danke für dei Hilfe
Frank
Zitat von: Tom71 am 26 September 2016, 20:59:55
Ja, hier ist mein Flash-Workflow:
- Kompilieren des Bootloaders mit der Änderung der Serial und HM-ID in devices/HB-UW-Sen-THPL.h
- make clean HB_UW_Sen_THPL -> Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex
- Dann flashen des OTA-Bootloaders mit meinem Raspi:
.....
Hallo Tom71, habe vergessen mich zu bedanken! Komme aktuell nicht dazu und mein Prototyp läuft auf dem Breadboard. Werde mich im Winter mal näher damit befassen. Aber dennoch schon jetzt ... danke![/list]
Hallo,
Ich suche nach einer Möglichkeit, meinen NewAskSin-Sketch im Powermode 3 zusätzlich per Interrupt aufzuwecken. Aber ich verstehe einfach nicht, an welcher Stelle ich ansetzen muss.
Kann mir jemand eine kleine Starthilfe geben?
Micky
Gesendet von meinem MD_LIFETAB_P9516 mit Tapatalk
Zitat von: Frank_S am 12 Oktober 2016, 18:32:10
Hallo,
brauche eure Hilfe. Ich möchte eine alte Wetterstation mit dem Universalsensor auf homematic umrüsten. Das Ganze soll wie eine HM-WDS100-C6-O funktionieren.
Bei der NewAskSin kann ich nicht wirklich helfen, aber ich habe ein entsprechendes Beispiel in meiner Reimplementierung aufgenommen. Siehe
https://forum.fhem.de/index.php/topic,57486.0.html (https://forum.fhem.de/index.php/topic,57486.0.html)
Vielleicht ist das ja was für Dich.
Hallo Zusammen,
wollte mich mal wieder melden. Ich habe in der letzten Zeit ziemlich viel an der NewAskSin gebastelt und einige Vorschläge/Kritikpunkte aufgegriffen.
Die NewAskSin benötigt jetzt kein destillregs mehr, wobei das nicht ganz stimmt - destillregs wird in Zukunft das entsprechende XML file für die CCU oder Homegear generieren :-)
Ich habe das fastdellegate für die channel module durch variable Klassen ersetzt. cmMaster macht das Kanalhandling und kann von eigenen Klassen überschrieben werden.
Alle Parameter für die verschiedenen Listen werden von der Software selbst generiert, so dass es die Rechnerei in der Register.h nicht mehr gibt.
Die verschiedenen HM Nachrichten sind als Structs abgebildet, so das man auf Parameter in der Nachricht direkt zugreifen kann.
Wer Lust hat es sich mal anzuschauen findet die Änderungen im DevAES Zweig - das derzeit funktionierende Beispiel ist HM_LC_SW1_BA_PCB.
Ist aber noch einiges zu tun - AES muss ich noch überarbeiten, die Sendefunktion an alle Peers wird noch angepasst und einige Funktionsaufrufe zum channel Modul gefallen mir auch noch nicht.
Ich werde bei Gelegenheit die Doku anpassen um das Zusammenspiel der Module und Structs zu erklären. Vielleicht finden sich ja noch ein paar Mitstreiter um am Code zu arbeiten. Ich denke die neue Struktur ist zukunftstauglich und eine gute Basis für viele verschiedene Channel Module. Am Ziel hat sich nichts geändert, ich hätte gerne eine Oberfäche zum Zusammenklicken von einem Device mit verschiedenen Modulen/Funktionalitäten, bekomme ein paar Dateien zum Aufspielen auf den Arduino und für FHEM/CCU/Homegear und kann das Device verwenden...
Liebe Grüße
Horst
Hallo,
ich habe jetzt meinen HM_SEC_WDS Eigenbau auf die NewAskSin umgestellt.
Alles läuft soweit, inklusive des PCINT und mit den Registern scheint mir auch alles gut zu sein.
Allerdings hat mich jetzt doch der Ergeiz gepackt und ich will wissen, was ich mit den Registern noch anstellen kann/muss.
Das mit dem destillregs.pl scheint zu funktionieren.
Jetzt habe ich Register, die ich vermutlich auch irgendwie aus dem Code adressieren könnte...wenn ich verstehen würde wie :(
Ich müsste doch z.B. im Programmcode mitkriegen, wenn, sagen wir, bei einem Bewegungssensor ein Brightnessfilter gesetzt würde, damit ich diesen dann beim Erzeugen eines Alarms berücksichtigen kann.
Also:
Hat jemand einen Tipp, wie der Zugriff auf die Register funktioniert?
Micky
Hallo trilu,
unglaublich dass du immer noch an der NewAskSin dran bist. Ich habe ja damals auch intensiv da rumprobiert mit meinen eigenen Devices aber als dann so das lief, was ich selbst dringend brauchte, hab ich mich lang nicht mehr damit beschaeftigt. Habe immer noch einige der Aufputz Schaltaktoren mit Taster und auch einen panstamp mit 8 Relais zur Steuerung meiner Fussbodenheizung. Das aber alles noch basierend auf der "Old AskSin"...ich hoffe ich habe bald Zeit mir mal den Stand anzusehen! Find ich toll dass es da noch weiter geht.
Ich wollte ja damals so gerne auch den Dimmer umsezten aber bei der 230V Version bin ich dann doch etwas zurueckhaltend da man dann ja die Phasenerkennung usw. alles selbst machen muss. Bugs könnten da im Worst Case zu Brandentwicklung fuehren...
Zitat von: micky0867 am 20 Oktober 2016, 21:46:37
Jetzt habe ich Register, die ich vermutlich auch irgendwie aus dem Code adressieren könnte...wenn ich verstehen würde wie :(
Ich müsste doch z.B. im Programmcode mitkriegen, wenn, sagen wir, bei einem Bewegungssensor ein Brightnessfilter gesetzt würde, damit ich diesen dann beim Erzeugen eines Alarms berücksichtigen kann.
Vom Grundsatz kümmert sich die Lib um die Listen - d.h. Du musst nur die Aktionen festlegen, was mit den Werten passieren soll.
Schau Dir mal im letzten commit im DevAES das Beispiel der PCB an. In cmSwitch.h/cpp siehst Du das Struct, das ich über die Werte lege
Und in der poll, was ich dann damit mache...
Hallo zusammen!
Erstmal möchte ich einen dicken Lob und ein großes Danke für die lib da lassen! Echt klasse, dass sich schon mal jemand die Mühe gemacht hat.
Ich bin gerade dabei mich ein bisschen in den Code einzuarbeiten und versuche erstmal das HM_LC_SW1_BA_PCB Beispiel aus dem devAES zum Laufen zu kriegen.
Auch wenn ich mir etwas blöd vorkomme bei der Frage, aber wie sieht es eigentlich auf der Hardwareseite aus? :D Wie zB verkabel ich den config key, damit das pairing überhaupt funktioniert? Gibt es irgendwo ein Schatplan von dem ganzen Gerät?
Danke für das Lob!
Das Hardware Setup findest Du im jeweiligen Example Ordner - Beim 328p ist die Peripherie so definiert:
//- cc1100 hardware CS and GDO0 definitions -------------------------------------------------------------------
#define CC_CS PIN_B2 // chip select
#define CC_GDO0 PIN_D2 // GDO0 pin, identify data received on falling edge
#define CC_MISO PIN_B4 // SPI port MISO
#define CC_MOSI PIN_B3 // SPI port MOSI
#define CC_SCLK PIN_B5 // SPI port Clock
//- LED's definition ------------------------------------------------------------------------------------------
#define LED_RED PIN_D6 // define the red led pin port
#define LED_GRN PIN_D4 // define the green led
#define LED_ACTIVE_LOW 0 // leds connected to GND = 0, VCC = 1
//- configuration key ----------------------------------------------------------------------------------------
#define CONFIG_KEY PIN_B0 // define the config key pin port
Ja, das hatte ich gesehen...aber wie schalte ich den key jetzt? Gegen vcc oder gegen masse?
Den Ausgang für den Schalter habe ich inzwischen gefunden, hatte völlig übersehen dass der PIN_D3 ja in den userfunctions unten definiert wird ::)
dann gegen masse :-)))
Ich bin endlich mal zum Testen gekommen und konnte problemlos pairen und den Aktor schalten.
Besten Dank nochmal!
kurze Frage: beim Sketch HM_PB_6_WM55 verlangt er nach "fatal error: cmRemote.h: No such file or directory"
Wo finde ich eigentlich die Library "cmRemote"?
Danke im Voraus
Hallo,
erstmal Danke für die vielen Informationen hier im Forum. Ich sitze nun schon eine Weile an meinem Aufbau und komme nicht so recht weiter.
Was habe ich vor?
Ich möchte im ersten Schritt einfach einen kleinen "Sniffer" bauen. Mit der AskSin ist dafür im Prinzip alles fertig - wovon ich erstmal begeistert bin.
Da ich leider keinen TRX868 TI mehr aufgetan habe (nur SI), habe ich ein CC1101 mit 868 MHz angeschlossen. Die Konfiguration mit dem CC1101 funktioniert und meldet zum Schluss auch "ready" zurück.
Ich habe auch alle Debug-Anzeigen eingeschaltet. Wenn ich nun eine Homematic-Komponente in das Paring versetzte hätte ich nun in den Debugausschriften zu mindestens irgendwas erwartet (Anzeige der Roh-Daten). Da ich nichts gesehen habe, habe ich zunächst den Interrupt überprüft und die Prüfung auf Daten des CC1101 ins Polling geschaltet (er fragt also immer, ob Daten vorhanden sind) und lasse mir die empfange Datenanzahl anzeigen.
Leider liest er nie Daten vom CC1101 aus - er meldet immer Null Bytes vorhanden. Es scheint so, als ob er per 868 MHz keine Daten empfängt oder ich (das erwarte ich) was falsch gemacht habe.
Die Register vom CC1101 kann ich allerdings problemlos auslesen - daher schließe ich weiterhin eine fehlerhafte Kommunikation zwischen Arduino und CC1101 aus.
Hat jemand noch eine Idee was ich überprüfen müsste, oder wo meine Fehler liegen könnte?
Vielen Dank im Voraus.
LG
Kühmi
Hast du eine Antenne angeschlossen?
Zitat von: Kuehmi am 25 November 2016, 11:29:02
Hat jemand noch eine Idee was ich überprüfen müsste, oder wo meine Fehler liegen könnte?
Warum nimmst du nicht einen nanoCUL oder <irgendwas>CUL als Sniffer?
Da ist doch praktisch schon alles drin.
Micky
Heute wurde bei uns für 2 Stunden der Strom abgestellt. Mein HM_SEC_WDS hat sich danach scheinbar noch einmal gemeldet (Alive). Dann waren die Batterien zu schwach.
Zufall? Oder fängt der Sensor an zu pollen, wenn kein ACK kommt?
Gesendet von meinem Toaster.
Ich bin nach langer Zeit mal wieder dazu gekommen, mich mit dem Thema zu beschäftigen. Mein Ziel ist es den HM-LC-RGBW-WM nachzubauen.
Mal zum grundsätzlichen Ansatz, wenn ich "neue" (im Sinne von bis jetzt noch nicht von trilu umgesetzten) devices erstellen will.Ich blicke durch den dataflow von Nachricht empfangen bis zur Funktionsausführung einfach nicht durch...
Kann mir mal jemand kurz erläutern, was ich alles anpassen/neu erstellen muss? Ich hoffe das kommt jetzt nicht so rüber als hätte ich es selber noch gar nicht versucht, weil ich wirklich keine konkrete Frage stellen kann, aber wie gesagt fehlt mir einfach der Ansatz :(
Ok, ich versuche mal etwas konkreter zu werden...
Ausgehend von dem Beispiel, gibt es ja zunächst die ino datei, in der die eigentliche Funktionalität umgesetzt wird. Im switch-beispiel die cmSwitch::initSwitch und cmSwitch::switchSwitch. Dort würde jetzt die Ausgabe der PWM Signale rein kommen.
Ich kann jetzt aber keine bestehenden cm-Module übernehmen, sondern muss ein eigenes schreiben, in dem auch die Message behandelt wird? Das wird dann in ptr_CM[] initialisiert.
Ist das soweit richtig?
Außerdem blicke ich noch nicht so ganz, wie das mit den message strukturen gemacht wird. Einmal sind in der register.h ja die messages definiert, in der cmSwitch.h sind aber auch schon definitionen.
Kann mir dazu noch jemand genaueres sagen?
Auf der Suche nach einem geringeren Stromverbrauch (derzeit ca. 0.7 mA), bin ich (wie auch schon Dietmar63) auf SLEEP_MODE_PWR_DOWN gestossen.
Wenn dieser aktiviert wird, sinkt der Verbrauch auf 0.004 mA!
In der Power.h ist der entsprechende Aufruf bereits vorgesehen, aber auskommentiert....
@trilu
Gibt es einen besonderen Grund dafür?
Außer der Tatsache, dass getMillis() beeinflusst wird, was bei meinen Sensor aber egal ist.
Micky
Hallo Arduino Gemeinde,
ich habe mir eine CC1101 am Arduino angeschlossen und kann erfolgreich mit FHEM kommunizieren (Beispiel HM_LC_Bl1_SM), leider kommen die driveUp und driveDown Kommandos nicht durch, es bleibt bei reading "R-driveUp set_14 s".
Ist im Beispiel der Bestätigungsbutton vergessen worden? Pin 8 gegen GND bringt nur versenden von FW Version und HMID.
https://forum.fhem.de/index.php?topic=66987.msg595653#msg595653 (https://forum.fhem.de/index.php?topic=66987.msg595653#msg595653)
Bitte um Hilfe!
Gruß ein völlig verzweifelter Michael
OK, ich konnte das Rätsel mit den Registern jetzt selbst lösen, leider scheint die cmBlind.cpp aber nicht auf die driveDown und driveUp Werte zu reagieren.
set HM_51F669 pct 40
Zack, 40. sofort.
Gruß Michael
Hallo,
woher weiß dein Aktor jetzt, wo 40% sind?
Micky
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
wird ja normalerweise anhand der driveUp und driveDown Zeit berechnet.
driveUp 26s -> Rollade brauch 26 Sekunden um hoch zu fahren wenn ganz geschlossen, fährt man also auf 50% sind das 13 Sekunden.
Das macht der Aktor selbstständig, dummerweise zählt der Sketch nicht richtig, das Ergebnis ist sofort drin.
Gruß Michael
Vermutlich liegt es an der cnlTbl,
wie setzt sich das pAddr zusammen? der Rest war relativ Logisch:
EE::s_cnlTbl cnlTbl[] = {
// cnl, lst, sIdx, sLen, pAddr, hidden
{ 0, 0, 0x00, 6, 0x001f, 0, },
{ 1, 1, 0x06, 13, 0x0025, 0, },
{ 1, 3, 0x12, 29, 0x0029, 0, },
}; // 21 byte
const uint8_t cnlAddr[] PROGMEM = {
0x02,0x0a,0x0b,0x0c,0x15,0x18,
0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,0x30,0x57,0x56,0x00,
0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0f,0x11,0x1c,0x1d,0x1e,0x1f,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,
}; // 48 byte
Hallo Zusammen,
mal wieder ein kleines Update von mir. Hatte gar keine Benachrichtigung bekommen, dass hier was geschrieben wurde - komisch...
Mittlererweile ist die Newasksin doch etwas vorangeschritten und der Dimmer und WM55 6 Kanal Taster im DevAES branch funktionieren ganz gut. Der Taster auch mit AES, den Dimmer habe ich mit AES noch nicht getestet.
Die einzige größere Baustelle ist noch das PowerManagement.
Der Aufbau der Lib hat sich komplett geändert und damit auch die Register.h. Schaut einfach mal in das Example: HM_LC_Dim1PWM_CV
Das wäre auch die Basis für den RGB Dimmer. Zumindest für den ersten Kanal.
Im Dimmer Example funktionieren auch die virtuellen Kanäle, etc - Hab das Ding gerade mit Powerleds im Testbetrieb und möchte mehrere Lampen im Haus demnächst damit ausstatten.
Für Eigenentwicklung von Modulen muss man in Zukunft eigentlich nur noch eine .h und .cpp (siehe cm_remote und/oder cm_dimmer) erstellen und die register.h anpassen. Statusmeldungen und restliche Kommunikation sollte per Default funktionieren.
Eingefügt werden dann die Channels in der register.h:
/*
* @brief definition of the device functionallity per channel
*/
CM_MAINTENANCE cm_maintenance(0); // 24 byte flash, 124 byte sram
CM_DIMMER cm_dimmer1(10, 0, 0); // 7332 byte flash, 330 byte sram - further 256 byte flash, 173 byte sram
CM_DIMMER cm_dimmer2(2, 1, 0);
CM_DIMMER cm_dimmer3(2, 2, 0);
CM_MASTER *cmm[4] = {
&cm_maintenance,
&cm_dimmer1,
&cm_dimmer2,
&cm_dimmer3,
};
In cm_dimmer kann man auch die State Machine relativ gut sehen, die müsste sich auch für Schaltkanäle und den Blind eignen.
Wie gesagt, momentan bin ich noch an der HW für den Dimmer am basteln, wenn das soweit klappt kümmere ich mich um den Blind sketch und das Power Management...
Doku ist natürlich immer noch Mangelware :-))))))
Viele Grüße
Horst
Ist es möglich eine Klasse für einen Microsekunden Waittimer zu bauen?
Das wäre für eine Lüftersteuerung eines PC Lüfters notwendig.
https://forum.fhem.de/index.php/topic,69079.0.html (https://forum.fhem.de/index.php/topic,69079.0.html)
Hallo Horst,
ich habe mir den cm_dimmer angesehen, leider habe ich mit dem Branch DevAES so meine Probleme.
Für die Arduino WEB IDE musste ich einige Dateien mit Groß und Kleinschreibung anpassen, Dateien hießen anders als im Quellcode und eine wurde sogar mit groß und klein angesprochen, da musste ich den Quellcode ändern.
Der Native Editor wirft mit noch mehr fehlern um sich z.B. Bindestriche in Dateinamen sind nicht erlaubt, womit entwicklest du?
Gruß Michael
In der "normalen" (also nicht Web) Arduino-IDE habe ich noch keine Probleme mit Bindestrichen gehabt.
Das not-case-sensitive kommt wohl von Windoof äääh... Windows
Micky
Hallo Trilu,
habe in der Branch-DevAES in der Register.h gelesen, das du testweise einen Mischbetrieb (Remote und Switch kombiniert) zustande bekommen hattest.
Wäre es aus deiner Sicht möglich, ein Homematic-Gerät zu errichten, das 2 Channels einer Remote und wiederum 2 Channels eines Switch besitzt?
Der einzige Frage die ich mir an diesen Punkt stelle, kann eine CCU damit umgehen?
Vielen Dank im Voraus.
Da mein vorhaben momentan anscheinend nicht funktioniert, habe ich eine andere idee. Der ConfigButton hat ja auch die funktion den ersten Kanal, bei kurzem Tastendruck (scn == 2) zu tooglen.
Meine Frage wäre jetzt, um für jeden Kanal einen Taster zu bauen, muss ich gezwungenermaßen den ConfigButton nachbauen?
BZW. muss ich einen normalen Button auch in der AS.cpp bzw .h erstellen, um dies zu programmieren, oder gibt es einen einfachen weg?
Z.B.: Das ich den Tastendruck eines neuen Eingangs einfach mit in das Scenario des ConfigButtons packe?
if (mode == 1) { // keyShortSingle
if (scn == 1) pHM->sendDEVICE_INFO(); // send pairing string
if (((scn == 2 || btnNew == 1) ) && (modTbl[0].cnl)) modTbl[0].mDlgt(0,1,0,NULL,0); // send toggle to user
So könnte ich mein vorheriges Vorhanden umgehen. Dazu kann ich dann als Rückkopplung in der CCU ein Programm erstellen, wo durch so einen Tastendruck zwei Ausgänge geschaltet werden, um eine Art Remote und switch kombinieren zu können.
Durch das schalten eines zweiten Relays hätte ich dann eine Statusmeldung von der CCU, das das schalten quittiert wurde.
Für Hilfe wäre ich sehr dankbar.
Falls ich dich nicht ganz falsch verstanden habe, gibt es sowas von ELV.
https://www.elv.de/homematic-8-kanal-empfangsmodul.html
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Nein. Trotzdem Danke. Meinte die kombination aus Remotebuttons und Relayswitch. Heisst es gibt momentan kein Gerät das das kann.
Muss mittels einem bzw. zwei Kanäle die CCU verständigen können. Das ist ja nicht das Problem. Weiter möchte ich zusätzlich das, dann ein Relay auf dem gleichen Board als Empfang geschaltet wird.
Die HM-Mod-Re und auch -EM8 module habe ich die können das gleiche wie jeweils Remote- oder Switchboard.
Möchte halt mein SW4-Board nur um Schalter für jeden Kanal einzeln erweitern.
Verstehe ich nicht. Wenn ich bei mir einen Button drücke, wird das jeweilige Relais geschaltet und die CCU informiert.
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Das Thema interessiert mich auch, ich habe vor Belüftungssysteme als Dimmer zu betreiben und dabei wäre es super wenn Temperatur und Feuchtigkeitsdaten zurückgesendet würden.
Am besten von vier Sensoren.
Gruß Michael
@micky0867
ja klar hast ja recht, aber ich meine das ich zb einen schalter zb den ConfButton betätige und den ersten Kanal schalte. Dies bekommt die CCU mit und ich programmiere dann einen zweiten Kanal der von der CCU, nur bei Empfang geschaltet wird. So habe ich einmal eine Remotetaste und zum anderen durch die Rückkopplung der CCU zum Board den eigentlichen Switch.
Wenn du mit dem Aktor von ELV 8 Buttons und 8 Relais hast, kannst du doch an 4 Buttons die Relais unbelegt lassen und bei den anderen 4 Buttons die Relais belegen, ohne die Buttons zu nutzen. Dann ein DoIf, und Button 1 schaltet via Fhem Relais 5
Gesendet von meinem SM-T813 mit Tapatalk
Hi Asksin Experten,
ich habe ein komisches Phänomen, ich habe basierend auf Linef Wettersensor, der auf der NewAsksin aufbaut, versucht einen SHT31 einzubauen. Wenn ich die Wire.h einhänge hängt der Sensor bei Wire.endTransmission(). Selbe Hardware, Aufbau mit dem Beispiel nur für SHT31 läuft problemlos, also richtig verkabelt und Arduino OK. Getestet mit Arduiono mini pro 8mhz und nano 16mhz.
Online habe ich gefunden, dass diese "Hänger" vorkommen wenn die Verkabelung niicht passt, oder ein Sensor defekt ist. Beides kann ich ausschließen da es mit dem Beispielcode ja funktioniert. Beispielcode 1:1 übernommen funktioniert in Asksin nicht mehr.
Ich habe mir Debug-Anweisungen in der Console ausgegeben, da sehe ich wo es nicht weiter geht.
Kann es sein, dass in der Asksin irgendwo I2C-Ports A4+A5 benötigt bzw. geblockt werden? Ich habe selber nichts gefunden. I2C braucht exklusiv die beiden Ports darum kann ich auch keine anderen verwenden.
Mir wäre jetzt eigentlich nichts bekannt, was die I2C-Anschlüsse des Atmel in der NewAskSin-Lib beeinflussen würde...
Muss I2C noch mit Power versorgt werden? Die Lib schaltet am Anfang alle Module im Atmel ab. Interrupts freigegeben?
Vielleicht passt wirklich was in der Initialisierung noch nicht...
Viele Grüße,
Martin
Hi Linef,
war nur eine Vermutung. Ich habe mit der Basis 1.4 von dir getestet die ich sein fast einem Jahr im Einsatz habe. Dein Release 2 bekomm ich nicht compiliert. Muss ich mir nochmal ansehen ... wenn ich Zeit finde werde ich das irgendwann nochmal in Angriff nehmen.
Habe zum Test mal den Temp-Sensor von Dirk (Fork auf NewAskSin) getestet, hier würde es funktionieren. Liegt demnach nicht an der NewAskSin-Lib.
Hallo,
ich bin neu hier im Forum und betreibe meinen erstes FHEM seit ein paar Wochen. Momentan nutze ich ihn nur als Anwesenheitserkennung über die Fritzbox, da ich noch auf meine Arduino nano + CC1101 Module aus China warte.
In der Zwischenzeit wollte ich mich mal mit der Asksin Library beschäftigen, da mir die Originalprodukte doch etwas zu teuer sind und ich schon einige Erfahrung mit Reverse-Engineering besitze.
Diese habe ich von hier (https://github.com/trilu2000/AskSin) runtergeladen und mal versucht den HM_LC_SW1_BA_PCB zu bauen. Dies ging so ohne weiteres nicht.
1. Fehlten Libraries (BMP085, Sensirion, TSL2561, Wire). Nachdem ich diese aus dem Internet heruntergeladen habe und mir in den Header Register.h einige Funktionen definiert hatte (alle, die in der HM_LC_SW1_BA_PCB aufgerufen werden), scheint es kurz davor, dass der Compiler durchläuft. Jetzt sagt er mir aber, dass die Klasse Sensiron keinen Teilnehmer config besitzt, welcher unter Sensor_SHT10_BMP085_TSL2561.cpp:21:9 aufgerufen wird:
sht10->config(data,sck); // configure the sensor
Wahrscheinlich habe ich also die falschen Libraries heruntergeladen.
Deswegen meine Frage, wo bekomme ich die entsprechenden Libraries her?
Viele Grüße und großes Lob an euch Entwickler.
Hi StefanH,
AskSin ist die ältere Version. Es gibt ein "NewAskSin" auch von Trilu,
https://github.com/trilu2000/NewAskSin/tree/master/examples (https://github.com/trilu2000/NewAskSin/tree/master/examples)
Und alternativ von papa eine Erweiterung AskSin++ die leichter zu erweitern ist / sein soll.
https://forum.fhem.de/index.php?topic=57486.0 (https://forum.fhem.de/index.php?topic=57486.0)
Kannst ja mal testen mit welcher Version du zurecht kommst bzw. schon Beispiele für dich enthält.
Die Libs die dir fehlten sind für Temperatursensoren, komisch dass diese angekreidet werden wenn du einen Schaltaktor bauen willst.
Was genau willst du bauen? Es gibt für manches schon fertige Projekte, z. B. für Temp-Sensoren den Wettersensor von Dirk
https://forum.fhem.de/index.php?topic=20620.0 (https://forum.fhem.de/index.php?topic=20620.0)
oder von LineF
https://github.com/LineF/HM-Sensor (https://github.com/LineF/HM-Sensor)
Ich habe mir jetzt mal die AskSin++ angeschaut. Diese lässt sich auf Anhieb kompilieren.
Ich hatte einfach mal ein Beispiel rausgesucht und versucht zu bauen. Anscheinend habe ich ausgerechnet das mit dem Sensor gebaut.
Der Plan ist eine Ventilaotrsteuerung zu bauen, da mein Ventilator in Mietwohnung immer auf Stufe 1 läuft um die gesetzlich vorgeschriebene Belüftung bei Neubauten sicherzustellen. Dazu habe ich mir 4 Temperatur/Feuchtesensoren gekauft. Diese sollen jetzt über FHEM den Ventilator steuern.
Zitat von: StefanH am 08 Juni 2017, 13:50:46
Ich habe mir jetzt mal die AskSin++ angeschaut. Diese lässt sich auf Anhieb kompilieren.
Ich hatte einfach mal ein Beispiel rausgesucht und versucht zu bauen. Anscheinend habe ich ausgerechnet das mit dem Sensor gebaut.
Der Plan ist eine Ventilaotrsteuerung zu bauen, da mein Ventilator in Mietwohnung immer auf Stufe 1 läuft um die gesetzlich vorgeschriebene Belüftung bei Neubauten sicherzustellen. Dazu habe ich mir 4 Temperatur/Feuchtesensoren gekauft. Diese sollen jetzt über FHEM den Ventilator steuern.
Mir ist zwar nicht ganz klar was du genau bauen willst, aber ein Hinweis ... es gibt hier im Forum etliche Posts von Personen die Lüftersteuerungen abhängig von Temperatur und Luftfeuchte gebaut haben. Für Bad oder Keller. Vielleicht kannst hier auch das ein oder andere übernehmen damit du nicht alles neu erfinden musst. Die HM-spezifischen Dinge sind natürlich nicth enthalten, aber Fragen zu Luftfeuchte, Dauer, ....
Um die Auswertung von Temperatur und Luftfeuchte wollte ich mich erst später kümmern. Erst einmal sehen, dass ich den Ventilator geschaltet bekomme und die Messwerte in FHEM eingelesen bekomme. Aber vielen Dank schon mal für den Hinweis.
Ich melde mich, wenn das System läuft oder ich weitere Fragen habe.
Zitat von: StefanH am 08 Juni 2017, 14:43:39
Ich melde mich, wenn das System läuft oder ich weitere Fragen habe.
Ich gehe von letzterem aus :) ... viel Spass beim Basteln