Ui. Gute Besserung!
							
						
					Ankündigung
				
					Einklappen
				
			
		
	
		
			
				Keine Ankündigung bisher.
				
			
				
	
ESP8266 KNX mit ETS
				
					Einklappen
				
			
		
	X
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Danke, ist ein komplizierter Beinbruch, werde demnächst viel Zeit zu Hause verbringen müssen/dürfen... Geistig bleibe ich aber dabei!
 
 Gruß Waldemar
 
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Naja, die "main exec pipeline" für asynchrone Sachen wie Ein- und Ausschaltverzögerungen steht schon. Die Logikfunktionen und Verarbeitung des Ausgangssignals auch. Bei den Eingängen brauche ich noch (und jetzt logischerweise länger), da sollten noch für Eingänge mit DPT > 1 Intervall- und Hysterese-Funktionen rein. Und ich muss noch rausfinden, wie ich mit dem Stack DPT 16 schreibe.
 
 Aber die große Herausforderung wird es, das auf den SAMD zu bringen, das hab ich einfach noch nie gemacht.
 
 Find ich super spannend...
 
 Gruß Waldemar
 
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Autsch. Gute Besserung!Zitat von mumpf Beitrag anzeigenDanke, ist ein komplizierter Beinbruch, werde demnächst viel Zeit zu Hause verbringen müssen/dürfen...Gruß
 Frank
 
 Soziologen sind nützlich, aber keiner will sie. Bei Informatikern und Administratoren ist es umgekehrt.
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Danke euch allen, aber ich wollte den thread nicht kapern, ist ziemlich OT...
 
 Gruß Waldemar
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 henfri Ich glaube dein BME hatte eine andere I2C-Adresse. Kannst du erst mal probieren ob es mit dem knx-demo geht?
 
 mumpf Erwischt. Das hatte gefehlt. Die Flags sollten eigentlich gemäß https://support.knx.org/hc/de/articl...03188089-Flags funktionieren. Also fast so wie du geschrieben hast. Nur kann man auch ohne Ü-Flag ReadRequests absetzen. (Jetzt auch bei mir Den Speicherbedarf habe ich nicht konkret analysiert. Da müsste man mal ausgehend von der KnxFacade die Größe der Klassen analysieren. Dazu gibt es bestimmt Tools. Dazu kommen (Anzahl zugewiesender GA + 1)*2 (Anzahl GA/KO Kombinationen + 1) + ca. 20 Byte pro KO. Alles nur geschätzt. Das kommt auch ziemlich darauf ob der Code für 64 Bit oder 32 Bit ist. Das sollte aber letztlich egal sein. Zur not kannst du auch einen ESP32 nehmen. Der hat dann 512KB RAM. Ich habe den Code dafür zwar noch nicht geschrieben, aber schon so ein Board hier. Den Speicherbedarf habe ich nicht konkret analysiert. Da müsste man mal ausgehend von der KnxFacade die Größe der Klassen analysieren. Dazu gibt es bestimmt Tools. Dazu kommen (Anzahl zugewiesender GA + 1)*2 (Anzahl GA/KO Kombinationen + 1) + ca. 20 Byte pro KO. Alles nur geschätzt. Das kommt auch ziemlich darauf ob der Code für 64 Bit oder 32 Bit ist. Das sollte aber letztlich egal sein. Zur not kannst du auch einen ESP32 nehmen. Der hat dann 512KB RAM. Ich habe den Code dafür zwar noch nicht geschrieben, aber schon so ein Board hier.
 
 P.S.: Auch von mir gute Besserung. Wenn du zu Hause einen PC hast kannst du doch jetzt prima Zeit zum programmieren. Zuletzt geändert von thesing; 27.05.2019, 21:29. Zuletzt geändert von thesing; 27.05.2019, 21:29.
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Hi,
 
 Das mache ich gerne, zumindest für DPT 1,2,5,5.001,6,7,8,9,16,17,232 - das sind die, die ich unterstützen will.Wer mag kann ja schon mal testen.
 
 Allerdings "darf" ich noch bis zum 7.6. (oder gar den Montag drauf) im Krankenhaus bleiben, dauert also noch etwas... Gut Ding will Weile haben.
 
 Dann also ESP32... Verstehe ich das richtig? Du willst sowieso noch coding spendieren, damit der ESP32 über microBCU mit KNX kommunizieren kann. Das könnte ich dann nutzen. Hört sich gut an. Bei 512k könnte ich noch ein paar Kanäle mehr machen... Bis die ETS platzt... 
 
 Danke für die Genesungswünsche... Hoffe, du hattest einen schönen Urlaub.
 
 Gruß Waldemar
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Ah, das stimmt. Hmm, ich werde mal einfach beides bestellen und dann testen, wie ich mit dem Speicher klar komme. 2 SAMD Module a 40-50 Kanäle würden ja auch gehen.
 
 Ich konzentriere mich erstmal auf die Funktionalität.
 
 @Thomas: Danke für die korrektur mit den flags. Das mit dem ReadRequest ist ja unkritisch. Testen kann ich allerdings erst, wenn Ich zu Hause bin... Wird ein Read Request eigentlich nur an die erste GA eines KO oder an alle geschickt? Da weiß ich noch nicht mal, wie s sein sollte... Erwarten würde ich aber nur die erste, sonst bekommt man wieder mehrere unterschiedliche Antworten und muss damit klar kommen.
 
 Gruß Waldemar
 
 
 
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Ja es sollte nur an ein ReadRequest zur ersten GA geschickt werden. Ausprobiert habe ich das wahrscheinlich nie.
 
 Ich habe nun bei der neuen KO-Wert-Api Dpt1 und Dpt9 getestet und ins Linux-Beispiel (https://github.com/thelsing/knx/blob...linux/main.cpp) eingebaut.
 
 Im wesentlichen gibt es am GroupObject jetzt folgende neue Methoden:
 
 Man kann nun mit
 den Datenpunkttyp festlegen oder abfragen.Code:Dpt dataPointType(); void dataPointType(Dpt value);
 
 Wenn man einen festgelegt hat man mit
 Den Wert abfragen oder setzen. dabei schreibt die *NoSend Variante den Wert zwar in das Gruppenobjekt, sendet ihn aber nicht auf den Bus. Die try* Variante sagt einem ob die Zuweisung geklappt hat. (Wenn bei Dpt 9.1 (Temperatur °C) z.B. ein Wert < -273 zugewiesen wird erhält mal false. Der Wert des GroupObjects wird nicht verändert)Code:void valueNoSend(const KNXValue& value); KNXValue value(); void value(const KNXValue& value); bool tryValue(KNXValue& value);
 
 Man kann auch den Datenpunkttyp bei anderen Varianten direkt angeben:
 Die KNXValue Klasse ist eine Art Union und kann je nach Kontext verschiedene Typen präsentieren:Code:KNXValue value(const Dpt& type); void value(const KNXValue& value, const Dpt& type); void valueNoSend(const KNXValue& value, const Dpt& type); bool tryValue(KNXValue& value, const Dpt& type);
 Der Vorteil ist dass man nun sowas schreiben kann wieCode:KNXValue foo = 4; // (int) 4 reinschreiben int i = foo; // i hat nun den Wert 4 foo = 2.0; // foo hat nun den Wert (double) 2.0 double d = foo; // d hat nun den Wert 2.0 i = foo; // FEHLER: i hat nun eine "zufälligen" Wert i = foo.doubleValue(); // i hat nun den Wert (int) 2 undCode:temp.value(24.3) . Dafür muss man aber auch immer an eine Variable vom richtigen Typ zuweisen. Ein Gruppenobjekt von Datenpunkttyp 9 liefert eben double-Werte. Wenn man die an ein int zuweist erhält man Müll. Im Zweifel kann man auchCode:double wert = temp.value() schreiben um explizit den double-Wert aus dem Objekt zu kriegen.Code:temp.value().doubleValue() 
 Ich bin mir nicht sicher ob das so gut ist. Wie seht ihr das? Wahrscheinlich ist das eh nicht verständlich genug geschrieben.
 
 Die KNXValue-Klasse befindet sich übrigens hier: https://github.com/thelsing/knx/blob...tconvert.h#L58 falls jemand genau drauf schauen möchte.
 
 Der Code für sämtliche Konvertierung der Datenpunkttype ist in https://github.com/thelsing/knx/blob...dptconvert.cpp zu finden.
 
 So das reicht erstmal für heute 
 
 Kommentar
- 
	
	
	
		
	
	
		
		
		
		
		
		
		
	
	
 Kein Ding, das werde ich dann testen...Zitat von thesing Beitrag anzeigenJa es sollte nur an ein ReadRequest zur ersten GA geschickt werden. Ausprobiert habe ich das wahrscheinlich nie.
 
 Ansonsten geht das ja ab hier... und ich kann damit nicht "rumspielen"... Aber nach Pfingsten (dann komm ich raus aus dem Krankenhaus) geht es dann los!
 
 Danke schon mal.
 
 Noch mal ne Frage, die oben untergegangen ist: Wenn ich zur Laufzeit mit bau.parameters().getXXX() parameter lese, kommen die dann aus dem Flash oder RAM? Ich hab noch keine praktische Erfahrung mit Mikrocontroller-Programmierung, hatte aber irgendwo gelesen, dass Lesen aus dem Flash schlecht fürs Timing (also langsam) ist und man sich vorher alle benötigten Daten auf einmal ins RAM kopieren sollte. Ich ging bisher davon aus, dass bau.readMemory(); genau das macht, wollte mich nur vergewissern. sonst würde ich meine Programmstruktur etwas anders aufbauen...
 
 Gruß, Waldemar
 
 Kommentar



Kommentar