[eBUS 2.0] Configuration support/contribution

mikulaos · January 27, 2018, 4:01pm

Helo!
Today, I have noticed some issues during the setup of my production set. There were errors in the configuration files that I have corrected and sent along with the new commands. The pull request is open.

If there are two or more handlers for a command, for those for which there is no thing, the handler will not take the telegram and that’s fine.
The problem is that in this situation the eBUS metrics register it as an error. I think it would be good to change this behavior so metrics only show real errors.

The vrc700 often requires the identification of all devices with which theoretically can be linked. Since most are not present, and vrc700 identifies them three times, there is a large number of “fake mistakes” being recorded.
So is it possible to handle telegrams for which there is no response from the slave?

The goal is that the eBUS metrics count only the real mistakes.

There are still some telegrams from my controller for which there are no commands, I will study it and report when it is updated.

csowada · January 27, 2018, 4:02pm

Use column PBSB (like 40 50, 40 80 or 40 22) as command and column [ID] as static default value from the csv file.

ChrisPe · January 27, 2018, 8:04pm

Hi Christian,

Great to see you back on the binding

I don’t remember of all issues, but I still have two in my concern list:

When session is lost with a network ebus converter, the binding stale there, a watchdog that reset the connection and reconnect in such a case would be very helpful.
The label of the “unresolved ratio” is actually reverse and disply “resolved ratio” instead
(Edit: this one is fixed in the last snapshot of the Alpha16)

lukics · January 27, 2018, 9:05pm

I did not get it?
the command (PBSB) is different from for read (40 50) and write (40 80), ID is the same (01)

r9,,LuftmengeStufe1,,,,4050,01,aktuell,,UIR,,m³/h,,minimum,,UIR,,m³/h,,maximum,,UIR,,m³/h,,Schrittgroesse,,UIR,,m³/h,,Werkseinstellung,,UIR,,m³/h
w,,LuftmengeStufe1,408001,,,4080,01,,,UIR,,m³/h

e.g.?

        {   
            "label":    "Fan Step 1",
            "id":       "ac.fan_step_1",
            "command":  "40 50",

            "get": {
                "master": [
                    {"type": "static", "default": "40 50 01"}
                ],
                "slave": [
                    {"name": "cur", "type": "word", "label":"Fan Step 1 Current", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "min", "type": "word", "label":"Fan Step 1 Min", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "max", "type": "word", "label":"Fan Step 1 Max", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "stp", "type": "word", "label":"Fan Step 1 Step", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "fac", "type": "word", "label":"Fan Step 1 Factory", "reverseByteOrder": true, "format":"%.1fm³/h"}   
                 ]
            },
            "set": {
                "master": [
                    {"type": "static", "default": "40 80 01"},
                    {"name": "cur", "type": "word", "label":"Fan Step 1 Current", "reverseByteOrder": true, "min": 50, "max": 150, "step":5, "format":"%.1fm³/h"}   
                ]
            }
        },

I can just have a single “command” in one section

lukics · January 28, 2018, 10:05am

With this config I get values but am not able to set any value:

        {   
            "label":    "Fan Step 1",
            "id":       "ac.fan_step_1",
            "command":  "40 50",

            "get": {
                "master": [
                    {"type": "static", "default": "01"}
                ],
                "slave": [
                    {"name": "cur", "type": "word", "label":"Fan Step 1 Current", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "min", "type": "word", "label":"Fan Step 1 Min", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "max", "type": "word", "label":"Fan Step 1 Max", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "stp", "type": "word", "label":"Fan Step 1 Step", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "fac", "type": "word", "label":"Fan Step 1 Factory", "reverseByteOrder": true, "format":"%.1fm³/h"}   
                 ]
            },
            "set": {
                "master": [
                    {"type": "static", "default": "01"},
                    {"name": "cur", "type": "word", "label":"Fan Step 1 Current", "reverseByteOrder": true, "min": 50, "max": 150, "step":5, "format":"%.1fm³/h"}   
                ]
            }
        },

I would one working example the rest should be easy.

andi_x · January 28, 2018, 10:56am

a quick info about my testing of the VRC700 files with the binding from 25.01.2018

my config: Vaillant VWF 117, VRC700, VR900, VRC9535

i had a bit of troubles during my first testing, so here are my steps for a fresh / clean setup.

Delete old snapshot in addon folder
Copy the new files to the addon folder
adding my own custom json, with the missing broadcast support from VRC430
Running in karaf console:
a. smarthome:ebus reload
b. smarthome:ebus update
adding all the discoverd things
rebooting my raspberry

because of the problems with my esera adapter, i want to keep the traffic low on the bus.
i started with disabled auto-polling on all things and during testing i activated only one thing at one time.
as soon i identified my needings, i enabled custom polling intervals for these groups.

everything looks very good at this moment, i just recognized that i miss the broadcasts from my VRC9535 (temp & DCF time).
i copied the commands from the VRC430 file and added it to my personal/custom json:

    "commands":
    [
        {
            "label":    "Outside temperature",
            "id":       "controller.bc.temp_outside",
            "command":  "B5 16",

            "broadcast": {
                "master": [
                    {"type": "static", "default": "01"},
                    {"name":"temp_outside", "type": "data2b", "label": "Outside Temperature", "min": -50, "max": 70, "format":"%.1f°C"}
                ]
            }
        },

        {
            "label":    "Controller Date",
            "id":       "controller.bc.datetime",
            "command":  "B5 16",

            "broadcast": {
                "master": [
                    {"type": "static", "default": "00"},
                    {"name": "datetime", "type":"datetime"}
                ]
            }
        }
    ]

in my unrecognized file there is currently just one unknown broadcast (every 1-3 minutes)

Check and unescape telegram
***************************

Original data : 10 FE B5 05 02 5C 00 E8 AA
Unescaped data: 10 FE B5 05 02 5C 00 E8 AA

Analyse the telegram
********************

10 FE B5 05 02 5C 00 E8 AA
^^------------------------ Source address       | Type: Master         | 10
   ^^--------------------- Destination address  | Type: Broadcast      | FE
      ^^ ^^--------------- Command              |                      | B5 05
            ^^------------ Master Data Length   | Length: 2            | 02
               ^^ ^^------ Master Data          |                      | 5C 00
                     ^^--- Master CRC           |                      | E8

update: moved the custom json from step 4 to 3.

andi_x · January 28, 2018, 12:34pm

details about my testing of the thing Vaillant VRC 700 hot water circuit (15):

HWC operation mode: this is nice, i’m able to set auto, off, day, night
in the official mulitmatic app i was only able to set: auto, off, on
and on the VRC 700 directly i can set: auto, off, day
so there is one option more

HWC timers: alle timers are correct and the same in openhab, vrc700 and the multimatic app.

Circulation timers: i have no circulation, but i get some values in openhab for Wed (00:30+2:50+00:10+11:10) and Sat (11:00+01:50). i’ve checked the values on the VRC700 and the offical app -> everything is empty (00:00 - 00:00)
i saved this values again on the VRC and it was ok in openhab after that.

HWC setpoint temperature: my water temp i have selected -> ok
HWC storage temperature: my water temp in my boiler -> ok

HWC SF mode: i get the options: auto, ventilation, party, veto, load in openhab
and have 6 values in VRC the values:
1-mal Speicherladung, 1-mal Stoßlüften, 1 Tag außer Haus, 1 Tag zu Haus, Party, System off
and in the multimatic app 7 values:
Ferien, 1-mal Speicherladung, 1-mal Stoßlüften, 1 Tag außer Haus, 1 Tag zu Haus, Party, System off
i think:
party=party
ventilation=1-mal Stoßlüften
load=1-mal Speicherladung
auto=1 Tag zu Haus ???
veto=1 Tag außer Haus???

HWC flow temperature: ??? (i think this is during heating?)

HWC bank holiday start/end and HWC holiday start/end:
this must be the planning for days at home and days not at home, the values are correct - but i miss the temperature value for the days not at home.
I think there is a problem with the translation, should these not be called something like “Planned days at home” and “Planned days not at home”. as i understand bank holiday and holiday are the same -> a day not at home

Updates: HWC flow temperature: --> yes just started, it’s the heating temperature

ChrisPe · January 29, 2018, 4:27pm

Hi Andy,

shouldn’t the step 3 and 4 be reversed, so that the updated json would be updated before running the reload and update ?

I would even put the step 4 before step 2 if you remove and put back the jar file.

andi_x · January 29, 2018, 6:41pm

Hi Chris,
you are right - would be better.
i think it works for me because of the final reboot.

i will move step 4 in my posting.
thx!

andi_x · January 30, 2018, 7:07pm

details about my testing of the thing Vaillant VRC 700 general (15):

HWC - Hot Water Circuit: (all values: kwH)
1] energy sum - value from ebus: 229 - real value: 560
2] energy sum this month - value from ebus: 126 - real value: 127 [OK]
3] energy sum last month - value from ebus: 131 - real value: 133 [OK]

HC - Heating Circuit: (all values: kwH)
1] energy sum - value from ebus: 97 - real value: 1829
2] energy sum this month - value from ebus: 208 - real value: 474
3] energy sum last month - value from ebus: 169 - real value: 628

Energy Sum -> value from ebus: 70 kwH …i think this should be in real HC+HWC 2389
Total yield -> value from ebus: 208 kwH …

Other Items:
Actual Time and Actual Date => both OK
Water pressure => OK
Average outside temperature (3h) => OK (not live value, rounded value from 3h)
Displayed outside temperature => empty

for all other items i have to find the associated real values…

csowada · January 30, 2018, 7:46pm

Hello @andi_x,

good work. But could give us the raw telegrams, with expected values. This would help to identify the issues.

andi_x · January 30, 2018, 8:19pm

vrc700_general.gen.energy_sum_hwc
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 58 00 BE 00 08 01 00 58 00 E5 09 00 00 AA 00"

vrc700_general.gen.energy_sum_this_month_hwc
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 50 00 A7 00 08 01 00 50 00 7E 00 00 00 5C 00" 

vrc700_general.gen.energy_sum_last_month_hwc
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 54 00 66 00 08 01 00 54 00 83 00 00 00 84 00"

vrc700_general.gen.energy_sum_hc
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 57 00 50 00 08 01 00 57 00 61 17 00 00 35 00"

vrc700_general.gen.energy_sum_this_month_hc
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 4F 00 7B 00 08 01 00 4F 00 D0 01 00 00 C1 00"

vrc700_general.gen.energy_sum_last_month_hc
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 53 00 91 00 08 01 00 53 00 A9 02 00 00 CD 00"

vrc700_general.gen.energy_sum
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 5C 00 7F 00 08 01 00 5C 00 46 21 00 00 52 00"

vrc700_general.gen.yield_total
smarthome:ebus resolve "FF 15 B5 24 06 02 00 00 00 3E 00 7E 00 08 01 00 3E 00 D0 63 00 00 44 00"

i hope this is not depending on the esera ethernet adapter,


******************************************************************************************************************************************************************************
** Error on checking telegram: Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF 15 B5 24 06 02 00 00 00 58 00 BE 00 08 01 00 58 00 E5 09 00 00 AA] **
**     !!! Warning: All following results are wrong and only displayed for information purpose !!!                                                                          **
******************************************************************************************************************************************************************************

ChrisPe · January 30, 2018, 10:15pm

Hi,

so I added some messages for bai on GitHub, and try to figure out why are the time/date messages wrong. For date, I have seen that the ID should be 6100 instead of 6000, and it works fine, now I get “2018-01-30 00:00:00” for message “FF 15 B509 03 0D 61 00 BE 00 03 1D 01 12 6E 00”,

However the time still get wrong. Some 6000 are in the resolved log, but most are in the unresolved, and the result seems random
resolved example:

FF 15 B509 03 0D 60 00 25 00 03 08 39 14 92 00

unresolved examples:

FF 15 B5 09 03 0D 60 00 25 00 03 05 1B 03 B2 00
FF 15 B5 09 03 0D 60 00 25 00 03 05 34 05 3E 00
FF 15 B5 09 03 0D 60 00 25 00 03 06 25 01 A9 00
FF 15 B5 09 03 0D 60 00 25 00 03 07 11 02 2B 00
FF 15 B5 09 03 0D 60 00 25 00 03 07 16 15 CB 00
FF 15 B5 09 03 0D 60 00 25 00 03 0A 39 06 AC 00
FF 15 B5 09 03 0D 60 00 25 00 03 0B 39 00 BC 00

I think the “time” type have an issue. If I look in the unresolved csv, I take the line:

29/01/2018 21:22	FF	15	B5 09	03 0D 60 00 25 00 03 07 16 15 CB 00

Using resolve, I get:

Values from command 'controller.time' with method 'GET' from collection 'vrc430'
  time                 = 22:07:10

However, if I decode manually the data byte, I got:
15=21
16=22
07=07
Which looks like the time of the log (21:22).

Another example, with the line:

30/01/2018 00:17	FF 15 B5 09 03 0D 60 00 25 00 03 0A 11 00 D7 00

There again, resolve give me that:

Values from command 'controller.time' with method 'GET' from collection 'vrc430'
  time                 = 17:10:10

But decoding manually the bytes give me:
00=00
11=17
0A=10
Which is again the time of the log line (00:17).
So it looks like the time type is getting the hour, minutes and second in the wrong order

ChrisPe · January 30, 2018, 10:38pm

I got the same B5 05 broadcast that I still cannot identify:

I would love to see what they could be purposed for, even if it’s limited in term of occurrences.

mikulaos · January 30, 2018, 11:24pm

B5 05 is “Set operational data”.
Next byte is message length.
After that there is command.
After command there is data.
Since destination is FE, telegram ends with CRC and SYN
For 02 29 00 2C AA data is 0, this could be some kind of status. See if anything turned on or off at the time you get those telegrams.
for 03 62 XX XX YY AA you could convert those XX values to various datatypes and sort them chronological. A clear picture might appear.

ChrisPe · January 31, 2018, 12:34am

Well, the 02 29 00 2C AA is sent every hour, so it could be a lot of thing. Maybe I should trigger some actions or configuration from the VRC470 itself to see other messages of the same type.

There are some broadcast based on B505 related in the csv files from john30, but none seems to match.

I tried to dig ebus wiki as well, through archives.org ( https://web.archive.org/web//http://ebus-wiki.org/doku.php/ebus/ ) but without any additional luck.

andi_x · January 31, 2018, 11:26am

if somebody wanted to test, this is the vaillant-vrc9535-configuration.json.
it provides dcf77 date/dime and the outside temperature

<<removed / already in next version of general VCR700 json>>

mikulaos · January 31, 2018, 1:27pm

Those commands should be in BAI or other configuration. VRC 9535 is not an eBus participant! It is allready added in vrc700-general for next release and you can see it on github.

andi_x · January 31, 2018, 1:42pm

ok sorry

csowada · January 31, 2018, 2:18pm

You are right, this are two bugs. The first bug is, that the date command and the time command uses the same id as you already fixed in github. The second bug is that time uses a wrong encoding for the time. I can push the changes this evening.