Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to filter serial number updates within EEP A5-12-01 processing for Eltako DSZ14DRS? #83

Open
tboesch opened this issue Jan 4, 2020 · 4 comments

Comments

@tboesch
Copy link

tboesch commented Jan 4, 2020

Hi Daniel

I monitor the power consumption of my heat pump using a couple of Eltako DSZ14DRS'. This works fine for most of the telegrams arriving using EEP A5-12-01. However every 10 minutes these meters transmit their serial number spread over two telegrams (according to [1], page T-11). I reckon these serial number telegrams get interpreted as sensor values and mess up the values ultimately seen in Grafana.

It appears to me that other people have the same problem (i.e. looking at [2]).

Can I filter out these serial number telegrams in your binding? They are static and thus would be easy to get rid of with a basic pattern based filtering.

Thanks for any help and best regards

Tobias

PS: I like your project very much. This is the first time I could install an enocean binding in openhab and get almost all my gear working without having to do any coding whatsoever. Very cool!

[1] https://www.eltako.com/fileadmin/downloads/de/Gesamtkatalog/Eltako_Gesamtkatalog_KapT_low_res.pdf,

[2] https://community.openhab.org/t/new-openhab2-enocean-binding/39917/313

@tboesch tboesch changed the title How to filter serial number updates within EEP A5-12-01 processing for (Eltako DSZ14DRS)? How to filter serial number updates within EEP A5-12-01 processing for Eltako DSZ14DRS? Jan 4, 2020
@dominikkv
Copy link
Collaborator

Hey @tboesch,

there is an option for EEP A5-12-XX to filter out those readings. Try to activate validateValue on the totalusage channel:

    Thing measurementSwitch 11223344 "Deckenlicht" @ "Wohnzimmer" [ enoceanId="11223344", senderIdOffset=1, sendingEEPId="D2_01_09_PERMUNDO", receivingEEPId="D2_01_09_PERMUNDO","A5_12_01", broadcastMessages=false, suppressRepeating=false, pollingInterval=500 ] {
        Channels:
            Type totalusage : totalusage [ validateValue=true ]
    }

image

@tboesch
Copy link
Author

tboesch commented Jan 5, 2020

Hi @dominikkv

Thank you for your reply and suggestion. I turned the validate value flag on. I had to upgrade to open hab 2.5.0 to get it (from 2.5.0M1), but this does not seem to solve my problem.

Furthermore I have realized that not only the serial number updates but the alternate tariff (which these meters support) interferes with the value timeseries. I.e. whenever I receive usage updates for the alternate, unused by me tariff, they are all 0 and get merged into the timeseries for the tariff I am using. In short I have two effects messing up my data and not only for usage but for power readings too.

I see two options here:

  1. Filtering of messages before they are being processed (which could work for me as I am using only one tariff)

  2. Implementing a Eltako compliant variant of EEP A5-12-01

I'll investigate the feasibility of 1 some more later today and would be open to suggestions how to best takle 2.

My current approach would be (not verified in the code):

  1. Add a new version of the EEP for Eltako
  2. Add separate usage and power channels for the different tariffs
  3. Ignore the serial number updates (processing would probably need some sort of state and if someone is interested in the serial number they can still grep the log files)

Any thoughts on this?

Thank you and best regards

Tobias

@fruggy83
Copy link
Owner

fruggy83 commented Jan 9, 2020

Hi @tboesch,

I think option 2 would be the best approach. We have already manufacturer specific implementations of certain EEP. So it should not be a big deal. I have some time this weekend to implement this. Do you have a testing environment where you could test a new openocean version?

Best regards
Daniel

@tboesch
Copy link
Author

tboesch commented Jan 9, 2020

Hi @fruggy83

I have worked on this over the last two days and deployed it yesterday on my installation. The code can be found at https://github.com/tboesch/openocean/tree/DSZ14DRS

It is looking good currently and I think I'll have a pull request ready this weekend.

Best regards,
Tobias

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants