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

Easy way to load an other Elster-table ? #5

Open
Kopernikus82 opened this issue Jan 20, 2024 · 4 comments
Open

Easy way to load an other Elster-table ? #5

Kopernikus82 opened this issue Jan 20, 2024 · 4 comments

Comments

@Kopernikus82
Copy link

Hello Simon,

i updatet to 1.3 and it seams that everything is working as expected.
As you now, i am using a tecalor TTL 5.6 with a WPM 4. As we talked,
it seams that the datapoints / can adresses are not the same as the older
models.
Is there an easy way to configure a other elster-table as you did in your
scetch ? Or must i set up a ne table and load sketch via arduino (or whatever)
to the devices ?

kind regards
Stefan

@simonlmn
Copy link
Owner

Unfortunately, there isn't a way to configure/upload such a table at runtime (via the API or otherwise). It is actually the "hardcoded" table found in ValueDefinitions.h which is more or less specific to the model I tested with.

I am currently working on switching to a configurable definition table and provide the current one only as a prepared file one can upload during the initial setup (or define your own). It may take a few days (or maybe even weeks, depending on how much time I find for that) though.

Until then, you really have no other option than to modify/create the ValueDefinitions.h file, re-compile and upload you modified version instead.

@simonlmn simonlmn mentioned this issue Jan 20, 2024
@danriedl
Copy link

+1 had the same question.

Thanks @simonlmn for taking a look at it.
I'd not go with recompiling another table in the future, maybe it is possible to modify/upload the file with the UI?

Also the ElsterTable.inc is in that format:

static const ElsterIndex ElsterTable[] =
{
  { "FEHLERMELDUNG"                                    , 0x0001, 0},
  { "KESSELSOLLTEMP"                                   , 0x0002, et_dec_val},
  { "SPEICHERSOLLTEMP"                                 , 0x0003, et_dec_val},

Which is kind of weird - and as mentioned in #4 that json-file looks promising.

@simonlmn let me know, if I can assist you in the ui approach!

Thanks in advance!

@simonlmn
Copy link
Owner

A quick heads-up: I have been working on the "run-time" definitions feature for a bit now and it looks pretty promising, though it may take some more time until I can finish that properly (there are some APIs that do not work fully at the moment and the UI has not been adapted and is mostly broken). You can have a peek at it on the branch https://github.com/simonlmn/can-wifi-gateway-stiebel-eltron/tree/switch-to-runtime-value-definitions. For an example how a definitions file could look like, see https://github.com/simonlmn/can-wifi-gateway-stiebel-eltron/blob/switch-to-runtime-value-definitions/misc/definitions/lwz5splus.json.

I kind of got a bit out of hand and in some aspects I got carried away with a few refactorings, so the overall changes are relatively large. As I have completely switched to JSON for all APIs now and also changed the internal storage to JSON (mostly, some parts need to adapted), the new final release will become 2.0.0 as it is a major change and definitely not backwards compatible. But that's probably not a problem for you :)

@simonlmn
Copy link
Owner

simonlmn commented Feb 23, 2024

There is now a first pre-release (v2.0.0-alpha) which I actually ran and tested on my installation using a secondary device. It looks like it is working and it should be possible to freely define what values are behind which IDs on the bus. The UI allows to configure all of that, but I took a few shortcuts and it requires editing JSON documents and it is not that "user-friendly".

As there is no documentation yet, I guess it may be hard to try it out, but maybe you can give it a shot.

Quick summary of how it works:

Before you can configure any datapoints for reading/writing, you have to define the IDs and how the values shall be interpreted. An example how this looks for the LWZ5Splus is mentioned in my previous post. Basically, you have to define for each value ID:

  • a name (32 characters at most)
  • a unit (can be empty, otherwise use any value of the Unit enum)
  • an access "mode": Readable or Writable
  • a codec which controls how the raw bytes are read/written and interpreted on the "byte level" (one of "U8", "S8", "U16" or "S16")
  • a converter which controls how the raw value is converted into an actual number, boolean or more "complex" type (enums or bitfields at the moment). E.g. for numbers there are the converters "int" for integers and "10^-1", "10^-2" and "10^-3" for decimals with the respective scale/number of decimals.

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