Decoding DCF message from WH31E/DNT000005 #1290
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Protocol 125 supplemented by decoding of the DCF message.
…FHEM into master_SD_WS_125_DCF
add testdata for DNT000005 temp tum sensor DCF message
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1290 +/- ##
==========================================
+ Coverage 84.31% 85.56% +1.24%
==========================================
Files 138 140 +2
Lines 10301 10347 +46
Branches 1691 1701 +10
==========================================
+ Hits 8685 8853 +168
+ Misses 1615 1493 -122
Partials 1 1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
elektron-bbs
changed the title
|
Ich habe folgendes Verstanden, es gibt eine T/H Sensor der sendet auch ein DCF Zeitsignal . Ist das korrekt? |
sidey79
reviewed
Jan 21, 2025
sidey79
reviewed
Jan 21, 2025
@sidey79 das ist korrekt. -> Link dazu
|
|
Okay Danke für die Bestätigung. Wieso packen wir das Zeitsignal dann nicht als Reading in das jeweilige device? Dafür gibt es ja bestimmt eine Erklärung :) |
Die Erklärung ist eigentlich einfach, da ich bei mehreren Sensoren jeweils zur "selben Zeit" dann ein Reading hätte, so dachten wir, ist ein zentrales Device übersichtlicher. (DFC Zeit kommt bei allen Sensoren fast identisch)
zur besseren Vorstellung Auszug Logfile: |
|
@HomeAutoUser Mir würde beim State dann auch noch einfallen, dass ich es vielleicht anders formatieren möchte und dann würde ich als Reading die Sekunden oder Angaben wie Stunde, Minute usw. vermissen damit ich es per stateformat in anderer Form darstellen kann. Wäre das interessant? |
|
@sidey79 , über die bzw. das Reading kann man natürlich sich austauschen was gut oder angebracht für den User besser erscheint. Formatierung mit "stateformat" könnte man überdenken, aber da hatten wir bisher keine Einfälle, welche uns günstig erschienen. Was würde deiner Meinung nach sinnvoll sein? @elektron-bbs sieht das Ganze vielleicht aus einer anderen Sicht wieder. Für mich wäre maximal interessant, wann die Zeit synchronisiert wurde und welcher Sensor. |
|
Erstmal soweit vorerst alles korrekt. Es handelt sich um den Sensor DNT000005, der das gleiche Protokoll verwendet wie z.B. der WH31E. Alle x Stunden (den Abstand haben wir noch nicht ermittelt) sendet er 6 mal je zwei Zeitnachrichten.. Ich wollte das Reading dcf auch zuerst dem jeweiligen Sensor zuordnen, das ging aber nicht weil kein Kanal in den Zeitnachrichten enthalten ist und so haben wir uns überlegt ein Device anzulegen (SD_WS_125_DCF), wo von allen Sensoren die Zeitnachrichten landen. Die Ausgabe von state ist verschieden je nach Sensorident: Einzelne Reading für Jahr, Monat, Tag usw. anzulegen halte ich für übertrieben. Ein individuelles Stateformat kann man sich ja auch aus dem Reading dcf basteln. Die kleinen Änderungen bei LaCrosse 1 und 2 schlummern bei mir schon lange. Ich habe sie jetzt bei dieser Gelegenheit gleich mit hier eingebaut, weil mir ein extra Branch, Pull request usw. dafür zu aufwändig erschien. |
|
Ok stateformat mit substr oder sowas dann? Gibt es überhaupt einen Anwendungsfall für die Zeit? Also würde jemand damit einen Zeitserver betreiben wollen? Theoretisch ginge das aber ich würde das maximal machen weil es vielleicht cool klingt :) |
Oder split oder wie auch immer...
Mir fällt eigentlich auch keine sinnvolle Anwendung ein. |
|
Sind hier noch Änderungen gewünscht oder können wir das so übernehmen nach der Freigabe @sidey79 ? |
|
Das Verhalten mit dem Zeit Gerät, lässt sich das in der Commandref beschreiben? |
commandref has been updated
|
Ich habe die commandref noch ergänzt, allerdings wüsste ich jetzt nicht, was man dazu noch schreiben könnte. Das ist ja eigentlich selbsterklärend. |
sidey79
approved these changes
Jan 26, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the current behavior?
(You can also link to an open issue here, if this describes the current behavior)
No decoding of the DCF messages of the sensors WH31E and DNT000005.
What is the new behavior (if this is a feature change)?
Decoding of DCF messages from sensors WH31E and DNT000005.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
no
Other information:
Added length_max attribute in SD_ProtocolData.pm for all WH series sensors to disable error messages when receiving other sensors.