HB-UNI-Sensor1-THPD-BME280

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

Shortie
Beiträge: 9
Registriert: 29.06.2021, 20:33
System: keine Zentrale (nur Pairing, FHEM etc.)

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von Shortie » 04.07.2021, 15:51

jp112sdl hat geschrieben:
03.07.2021, 17:39
Shortie hat geschrieben:
03.07.2021, 17:21
Das Pairing mit einem HM-CC-RT-DN scheint zu klappen.
Behalte mal im Auge, ob das Timing klappt.
Ich erinnere mich dunkel an das aufwendige Feintuning...
https://github.com/pa-pa/AskSinPP/blob/ ... -I.ino#L10
Scheint leider der Fall zu sein, fürs Schlafzimmer hatte ich umgeflasht auf HB-UNI-Sensor1-THPD-BME280, fürs Wohnzimmer noch nicht. Im Chart hab ich jeweils für Schlaf und Wohnzimmer den jeweiligen Sensor und den Weather Channel des entsprechenden Thermostats reingenommen.
Wohnzimmer ist mit kleiner Verzögerung (vermutlich weil _Weather erst etwas später an fhem meldet) gleich.
Schlafzimmer sind die Werte auseinander (Sensor liegt aktuell mit im Wohnzimmer), ganz selten sind die Linien im Chart übereinander. Fällt das Thermostat nach einer bestimmten Zeit ohne Meldung auf seine eigene Messung zurück?
Ich habe mir mal den Code angeschaut, im Weather.h wird dafür, wie von Jérôme angemerkt, einiger Aufwand getrieben, daher wird das auch mit dem HB-UNI-Sensor1-THPD-BME280 auch nicht so einfach nachzubauen sein.

Mal sehen wie ich dann weiter mache, hab glaub ich noch ein paar DS18B20 in der Bastelkiste, dann könnte man damit für die Thermostate etwas bauen.
Oder ich versuche mal auf Basis des HM-WDS40-TH-I und der Implementierung der weiteren Werte aus HB-UNI-Sensor1-THPD-BME280 etwas zu bauen. Das Erstellen und forschen wie das ganze in fhem eingebaut werden muss hat mir schon eine Menge neue Erkenntnisse über AskSinPP und wie das alles funktioniert beschert.

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von jp112sdl » 04.07.2021, 15:57

Shortie hat geschrieben:
04.07.2021, 15:51
noch ein paar DS18B20 in der Bastelkiste
Ich find die DS18B20 für Batteriebetrieb mittlerweile doof, weil sie a) 3V lt. tech. spec benötigen (funktionieren aber auch noch zuverlässig weit daraunter) und b) Abfrage der Daten recht lange dauert.
Ist zwar noch im Millisekundenbereich, aber über die Monate summiert sich das.

Wo ich nur Temperatur benötige, nehme ich nun NTC.

Shortie hat geschrieben:
04.07.2021, 15:51
Fällt das Thermostat nach einer bestimmten Zeit ohne Meldung auf seine eigene Messung zurück?
Das kann ich dir leider nicht sagen.
Aber das Prinzip mit den Timeslots ist dir bekannt? (das HKT wacht nur zu bestimmten errechneten Zeit kurz auf und erwartet genau in dem Moment das Telegramm vom verknüpften Sender)

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
FUEL4EP
Beiträge: 584
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 77 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von FUEL4EP » 04.07.2021, 18:03

jp112sdl hat geschrieben:
03.07.2021, 17:39
Shortie hat geschrieben:
03.07.2021, 17:21
Das Pairing mit einem HM-CC-RT-DN scheint zu klappen.
Behalte mal im Auge, ob das Timing klappt.
Ich erinnere mich dunkel an das aufwendige Feintuning...
https://github.com/pa-pa/AskSinPP/blob/ ... -I.ino#L10
Ich werde bei nächster Gelegenheit (das kann ein paar Tage dauern), das Feintuning entsprechend HM-WDS40-TH-I.ino#L10 in den HB-UNI-Sensor1-THPD-BME280 Sketch als Option einzubauen. Beim Test brauche ich Eure Hilfe.
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von TomMajor » 04.07.2021, 18:22

Da gab es auch schon früher ein paar Leute bei FHEM die mit EXTRAMILLIS Feintuning betrieben haben um eine funktionierende Kommunikation zwischen Thermostat und Sensor zu bekommen.
siehe z.B. hier den Beitrag von Gernott (auch die Beiträge davor und dahinter).

ich glaube mich zu erinnern das der aktuelle Wert von EXTRAMILLIS in der AskSinPP ein Resultat eines solchen Feintunings bei einem FHEM user war.
Viele Grüße,
Tom

TomMajor
Beiträge: 1790
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von TomMajor » 04.07.2021, 19:31

und hier ist der andere FHEM thread und die Stelle wo es mal um die Kopplung ging, noch etwas früher als mein link oben vorhin.
Das ist das legendäre und ewig lange "Selbstbau HM_WDS10_TH_O mit Luftdruckmessung" Thema was mich auch in 2018 zur Neuauflage/Redesign der HB-UNI-Sensor1 Platine V2.01 inspiriert hatte.
Gernott beschreibt dort u.a. wie man erkennt ob die Synchronisierung verloren geht.
Viele Grüße,
Tom

Shortie
Beiträge: 9
Registriert: 29.06.2021, 20:33
System: keine Zentrale (nur Pairing, FHEM etc.)

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von Shortie » 04.07.2021, 20:36

FUEL4EP hat geschrieben:
04.07.2021, 18:03
Ich werde bei nächster Gelegenheit (das kann ein paar Tage dauern), das Feintuning entsprechend HM-WDS40-TH-I.ino#L10 in den HB-UNI-Sensor1-THPD-BME280 Sketch als Option einzubauen. Beim Test brauche ich Eure Hilfe.
Danke, testen kann ich gerne übernehmen. Ich hab aktuell 3 Thermostate und Sensoren zur Verfügung die ich dank Sommer gut zum Testen nutzen kann.

Benutzeravatar
FUEL4EP
Beiträge: 584
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 77 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von FUEL4EP » 09.07.2021, 17:39

Hi Shortie,

das Einbauen der EXTRAMILLIS / EXTRADELAY in HB-UNI-Sensor1-THPD-BME280.ino gestaltet sich doch nicht so einfach wie ich annahm. Die Klassenschablone WeatherChannel von Weather.h und HB-UNI-Sensor1-THPD-BME280.ino haben sich sehr weit voneinander entfernt und passen nicht mehr zueinander, ohne sie komplett umzubauen. Bei der Code-Analyse von Weather.h bin ich auf die Methode nextSendSlot von AskSinPP.h gestossen, die Zeit in Ticks bis zum nächsten Sendeschlitz berechnet:

Code: Alles auswählen


class AskSinBase {
  Storage storage;
public:
..
..
..
  /** Calculate time until next send slot
   * \param id Homematic ID of the device
   * \param msgcnt current message counter
   * \return next send slot in sysclock ticks
   */
  static uint32_t nextSendSlot (const HMID& id,uint8_t msgcnt) {
    uint32_t value = ((uint32_t)id) << 8 | msgcnt;
    value = (value * 1103515245 + 12345) >> 16;
    value = (value & 0xFF) + 480;
    value *= 250;

    DDEC(value / 1000);DPRINT(".");DDECLN(value % 1000);

    return value;
  }
Diese Methode wird nur von von der Methode 'reactivate'

Code: Alles auswählen

template <class HAL,class CLOCKTYPE,class SENSORSTYPE,int PEERS_PER_CHANNEL,int EXTRADELAY,class LIST0,class LIST1=List1,class LIST4=List4>
class WeatherChannel : public Channel<HAL,LIST1,EmptyList,LIST4,PEERS_PER_CHANNEL,LIST0>, protected RTCAlarm {

private:
  SENSORSTYPE sens;

public:
  WeatherChannel () : Channel<HAL,LIST1,EmptyList,LIST4,PEERS_PER_CHANNEL,LIST0>() {}
  virtual ~WeatherChannel () {}

  
 ..
 ..
 ..
 
  void reactivate (Message& msg) {
    uint32_t nextsend = AskSinBase::nextSendSlot(msg.from(),msg.count()) + EXTRADELAY;
    CLOCKTYPE::instance().add(*this,nextsend);
    // reactive measure before send
    CLOCKTYPE::instance().add(sens,nextsend-sens.before());
  }
  
verwendet. Von den AsksinPP Beispielprogrammen wird die Klasse WeatherChannel nur von HM-WDS40-TH-I.ino und HM-WDS10-TH-O.ino verwendet.

Frage: Hängt bei allen anderen Sensoren und Aktoren der nächste Sendezeitpunkt nicht von HMID und msgcnt ab (siehe oben 'nextSendSlot')?

Warum ist das so? (oder liege ich da falsch?)

Haben wir in Realität ein festes Senderaster? Meine Auffassung ist nein.

Hintergrund meiner Frage ist, dass in der Methode 'nextSendSlot' das EXTRADELAY addiert wird.

Je tiefer ich mich in den Code rein grabe, desto mehr Fragen türmen sich für mich auf. Wer kann da helfen?
Zuletzt geändert von FUEL4EP am 10.07.2021, 10:41, insgesamt 1-mal geändert.
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von jp112sdl » 09.07.2021, 17:44

FUEL4EP hat geschrieben:
09.07.2021, 17:39
Haben wir in Realität ein festes Senderaster?
Die variablen Slots (und somit die Verwendung von nextSendSlot braucht es nur in Verbindung mit dem Peering mit einem HM-CC-RT-DN.
Der Zeitpunkt des nächsten Aufwachens des HM-CC-RT-DN hängt vom Messagecounter des Sensors ab.

Und eigentlich muss der Sensor auch (einmalig) ein Burst schicken, um nach seiner Inbetriebnahme das HM-CC-RT-DN erzwungen aufzuwecken.
Denn der Counter geht ja plötzlich wieder von vorn los, wovon das HM-CC-RT-DN nix weiß.
Um da erstmal in den Gleichtakt zu kommen, muss es geweckt werden.
FUEL4EP hat geschrieben:
09.07.2021, 17:39
Frage: Hängt bei allen anderen Sensoren und Aktoren der nächste Sendezeitpunkt nicht von HMID und msgcnt ab (siehe oben 'nextSendSlot')?
Korrekt.
Sonst gibt es immer ein festes Intervall ohne schnickschack

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
FUEL4EP
Beiträge: 584
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 77 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von FUEL4EP » 09.07.2021, 18:04

Hi Jérôme,

vielen Dank für Deine fantastisch schnellen und wie immer präzise Antworten.

Den ganzen 'schnickschack' ausschließlich für die Synchronisation mit dem HM-CC-RT-DN zu implementieren ist dann viel Aufwand.

@Shortie: Da muss ich noch viel mehr Zeit finden, um mich da reinzuknien .. Ich überlege mir nochmals, ob es doch ohne Komplettumbau geht. Ansonsten muss ich Dich bitten, die Idee aufzugeben, den HB-UNI-Sensor1-THPD-BME280 mit dem HM-CC-RT-DN zu koppeln. Zur Zeit ohne den 'schnickschack' Zauber geht es wahrscheinlich nur manchmal oder zufällig, dass Messwerte vom HB-UNI-Sensor1-THPD-BME280 auf den HM-CC-RT-DN übernommen werden.

Zusätzliche hilfreiche Information zur Kopplung eines HM-CC-RT-DN Thermostaten mit einem externen Temperatursensor sind zu finden unter Github und unter Youtube. Damals schon von Dir :D
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

Shortie
Beiträge: 9
Registriert: 29.06.2021, 20:33
System: keine Zentrale (nur Pairing, FHEM etc.)

Re: HB-UNI-Sensor1-THPD-BME280

Beitrag von Shortie » 10.07.2021, 22:55

Hi Ewald,

vielen Dank für deine Bemühungen. Da es doch etwas komplizierter ist werde ich nun 2 Sensoren pro Raum vorsehen. Einmal deinen Sensor und einen weiteren, der nur die Temperatur an das Thermostat sendet.

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“