OK - done 
Thanks for the quick answer.
Hereafter the log with, in the middle, the value from the pressure retrieved by ebusd.
2020-01-30 17:21:15.231 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ...
2020-01-30 17:21:15.399 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|1008b5110102 050314964c78|
2020-01-30 17:21:15.399 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D0200|
2020-01-30 17:21:15.405 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|-s FF 08B509030D0200:ERR: command not enabled|
2020-01-30 17:21:15.407 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Ebusd send error: "command not enabled" for data [FF08B509030D0200]
2020-01-30 17:21:17.407 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|1008b5100900004b6cffff00ff00 0101|
2020-01-30 17:21:17.410 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|3108b509030d0200 03c50300|
2020-01-30 17:21:17.420 [TRACE] [bus.service.parser.EBusParserService] - No command method matches the telegram 10 08 B5 10 09 00 00 4B 6C FF FF 00 FF 00 12 00 01 01 9A 00 AA ...
==> /var/log/openhab2/events.log <==
2020-01-30 17:21:17.432 [vent.ItemStateChangedEvent] - ebus_bai_3285f593_bai_boiler_pressure_pressure changed from NULL to 0.965
2020-01-30 17:21:17.441 [vent.ItemStateChangedEvent] - ebus_bai_3285f593_bai_boiler_pressure_status changed from NULL to 0
==> /var/log/openhab2/openhab.log <==
2020-01-30 17:21:17.474 [DEBUG] [ervice.device.EBusDeviceTableService] - DATA TABLE UPDATE EBusDevice [masterAddress=0x31, slaveAddress=0x36, lastActivity=1580401277440, manufacturer=null(null), deviceId=, softwareVersion=null, hardwareVersion=null]
2020-01-30 17:21:17.476 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ...
2020-01-30 17:21:17.611 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 36070400|
2020-01-30 17:21:17.613 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|-s FF 36070400:ERR: command not enabled|
2020-01-30 17:21:17.616 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Ebusd send error: "command not enabled" for data [FF36070400]
I have no idea of what is ācommeand not enableā for data.
I have added : EBUSD_OPTS="āscanconfig --accesslevel=*"
in the ebusd conf file
Could you please try it with the example parameter for ebusd without running it as a service?
ebusd -d /dev/ttyUSB1 --enablehex --scanconfig= -f -p 8888
The message is from ebusd, you should check it there. Looks like the commands are blocked for security reason.
Thank for the tip.
āenablehex was missing. I have now activated and it is working even when running as a service.
I will be busy in the next days, but I will try to help decode telegram or debug the binding in future. What I will investigate more deeply is the telegrams from the controler, which doesnāt seem to appear in openhab while they are visible in ebusd.
Setpoint and Status02 telegrams.
Thank again for your help and work
I do not know, if the follow is really a protocoll failure, or if it is an ebus issue.
I had send diverse GET-Statements on the ebus to find out if there is an answer of vms02 and what could it be.
For the following statements I get an error. But for me the sequence should be OK ?
My understanding is that the last Byte of an answer quite often is the status and AA means cutoff
For the last one also the result as example:
smarthome:ebus resolve "FF ED B5 09 03 0D 06 00 2B 00 03 85 FD AA 4C 00"
smarthome:ebus resolve "FF ED B5 09 03 0D 0A 00 F3 00 03 85 FD AA 4C 00"
smarthome:ebus resolve "FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF AA 01 00"
openhab> smarthome:ebus resolve "FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF AA 01 00"
***************************************************************************************************************************************************
** Error on checking telegram: Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF AA] **
** !!! Warning: All following results are wrong and only displayed for information purpose !!! **
***************************************************************************************************************************************************
Hello @Roland62,
your telegram is not valid. It contains AA in the slave data, but AA is only allowed on the end of the telegram. If you need the value AA, you have to mask it.
Hi csowada,
thanks for the answer.
But I haveānt sent it, it was an answer of a vaillant device (VMS 08, on the ebus with the ID vms02).
Makes my wonder that a vaillant device sent an illegal answer.
But still thanks.
Maybe it is the masked variant, but is not allowed as raw telegram. And the decoder uses the raw format.
You could try to replace the AA with the masked bytes A9 01
Hi Csowada,
thanks is working fine. Think in ebus-(un)resolved.scv the āUnescaped dataā is stored.
This as hint for other user, maybe have the same symtomā¦
openhab> smarthome:ebus resolve "FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF A9 01 01 00"
Check and unescape telegram
***************************
Original data : FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF A9 01 01 00
Unescaped data: FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF AA 01 00
Analyse the telegram
********************
FF ED B5 09 03 0D 0C 00 9F 00 03 39 FF AA 01 00
^^--------------------------------------------- Source address | Type: Master | FF
^^------------------------------------------ Destination address | Type: Slave | ED
^^ ^^------------------------------------ Command | | B5 09
^^--------------------------------- Master Data Length | Length: 3 | 03
^^ ^^ ^^------------------------ Master Data | | 0D 0C 00
^^--------------------- Master CRC | | 9F
^^------------------ Slave ACK | | 00
^^--------------- Slave Data Length | Length: 3 | 03
^^ ^^ ^^------ Slave Data | | 39 FF AA
^^--- Slave CRC | | 01
^^ Master ACK | | 00
Resolve the telegram
********************
Found 1 command method(s) for this telegram.
Values from command 'test01' with method 'GET' from collection 'custom-vms02'
value = -12.4375
status = 169
hi, after update to last version I see again this error:
2020-02-02 20:35:15.579 [ERROR] [bus.service.parser.EBusParserService] - Error while firing onTelegramResolved events!
java.lang.NullPointerException: null
at org.openhab.binding.ebus.internal.handler.EBusHandler.supportsTelegram(EBusHandler.java:537) ~[?:?]
at org.openhab.binding.ebus.internal.handler.EBusBridgeHandler.onTelegramResolved(EBusBridgeHandler.java:270) ~[?:?]
at de.csdev.ebus.service.parser.EBusParserService.fireOnTelegramResolved(EBusParserService.java:117) [bundleFile:?]
at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:95) [bundleFile:?]
at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:152) [bundleFile:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Hello @modenet,
is it possible that you have one Thing without a masterAddress and a slaveAddress? It would be better to create a github issue for that.
Hello All,
Yesterday I published a version. There are not so many changes in this release, because it seems to be working so far.
- There are now two rule actions to send complex commands, see README.MD for an example.
- It contains some improvements for the ebusd connector.
- Improvement of the console command
send - Setter Only channels are now also displayed for the Things
- Other minor fixes
1 Like
Installed, tested - seems is working perfect (as least for me). Specially I have checked all named issues.
Thanks csowada !!!
Hello @csowada,
I have a big problem. From some time, unfortunately I donāt know exactly how long, I cannot set any parameter via this binding. Reading works ok. For example, when I set Hc1OPMode I see in ebusd logs:
[main notice] direct cmd: ff10b509040e2f0003
[update notice] sent unknown MM cmd: ff10b509040e2f0003
And nothing happens.
I use ebusd connector.
But using: ebusctl write -c 470 Hc1OPMode works as expected.
What Iāve check: simplified configuration. created new things+items, restarted ebusd daemon, restarted openhab, but nothing helps.
What could it be? What can I troubleshoot more?
Current binding version: 2.5.1-6, but with 2.5.1-2 it didnāt work either.
Could you send log details for the working ebusd command? The send raw data is interesting for me.
But Master-Master Telegrams are unusual for Vaillant, I think it should be a Master- Slave telegram ?!
I need more details here, but what I can see is that your destination address is maybe wrong. In your example it is 10, but it should be 15 if Iām not wrong.
Send raw data from ebusd log:
[main notice] direct cmd: ff10b509040e2f0004
[update notice] sent unknown MM cmd: ff10b509040e2f0004
[bus notice] >ff10b509040e2f0004f3<00
On Vaillant VRC 470 thing i have:
Slave Address: 15
Master Address: 10
But changing master to 15 doesnāt change directo cmd. It is still ff10ā¦
@csowada Thanks for including the ebusd fixes that is now reliable for me.
I get several messages with
Skip matching command due to invalid response data length
and
No command method matches the telegramā¦
Logs around those sections are
> 2020-02-12 19:49:00.222 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ... > 2020-02-12 19:49:00.331 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D6E04| > 2020-02-12 19:49:00.440 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|-s FF 08B509030D6E04:00| > 2020-02-12 19:49:00.440 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|ff08b509030df203 0101| > 2020-02-12 19:49:00.441 [TRACE] [dev.ebus.command.EBusCommandRegistry] - Skip matching command due to invalid response data length ... [bai.boiler.temp_d_flow_ext:GET] > 2020-02-12 19:49:00.441 [TRACE] [dev.ebus.command.EBusCommandRegistry] - DATA: FF 08 B5 09 03 0D 6E 04 4A 00 00 00 00 AA > 2020-02-12 19:49:00.442 [DEBUG] [s.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command boiler.mode_summer_winter_switch > 2020-02-12 19:49:00.443 [TRACE] [ng.ebus.internal.handler.EBusHandler] - eBUS handler cfg EBusHandlerConfiguration [slaveAddress=08, masterAddress=03, filterAcceptMaster=false, filterAcceptSlave=true, filterAcceptBroadcasts=true, polling=60.0] > 2020-02-12 19:49:00.443 [TRACE] [bus.service.parser.EBusParserService] - No command method matches the telegram FF 08 B5 09 03 0D 6E 04 4A 00 00 00 00 AA ... > 2020-02-12 19:49:00.443 [DEBUG] [ng.ebus.internal.handler.EBusHandler] - Handle received command by thing Vaillant BAI00 (08) with id ebus:bai:740379ea:08 ... > 2020-02-12 19:49:00.443 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram FF 08 B5 09 03 0D 6E 04 4A 00 00 00 00 AA > 2020-02-12 19:49:00.443 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key mode_summer_winter_switch with value 1 > 2020-02-12 19:49:02.445 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|ff08b509030d6e04 00| > 2020-02-12 19:49:02.446 [TRACE] [dev.ebus.command.EBusCommandRegistry] - Skip matching command due to invalid response data length ... [bai.boiler.temp_d_flow_ext:GET] > 2020-02-12 19:49:02.446 [TRACE] [dev.ebus.command.EBusCommandRegistry] - DATA: FF 08 B5 09 03 0D 6E 04 4A 00 00 00 00 AA > 2020-02-12 19:49:02.447 [TRACE] [bus.service.parser.EBusParserService] - No command method matches the telegram FF 08 B5 09 03 0D 6E 04 4A 00 00 00 00 AA ... > 2020-02-12 19:49:02.447 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram FF 08 B5 09 03 0D 6E 04 4A 00 00 00 00 AA > > 2020-02-12 19:48:49.357 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:bai:740379ea:08:bai_boiler_temp-return#temp-return" with "FF 08 B5 09 03 0D 98 00 B7" ... > 2020-02-12 19:48:49.357 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ... > 2020-02-12 19:48:49.516 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D9800| > 2020-02-12 19:48:49.635 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|-s FF 08B509030D9800:05670498fb00| > 2020-02-12 19:48:49.636 [TRACE] [dev.ebus.command.EBusCommandRegistry] - Skip matching command due to invalid response data length ... [bai.boiler.temp_return:GET] > 2020-02-12 19:48:49.637 [TRACE] [dev.ebus.command.EBusCommandRegistry] - DATA: FF 08 B5 09 03 0D 98 00 B7 00 05 67 04 98 FB 00 3A 00 AA > 2020-02-12 19:48:49.638 [TRACE] [bus.service.parser.EBusParserService] - No command method matches the telegram FF 08 B5 09 03 0D 98 00 B7 00 05 67 04 98 FB 00 3A 00 AA ... > 2020-02-12 19:48:49.639 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram FF 08 B5 09 03 0D 98 00 B7 00 05 67 04 98 FB 00 3A 00 AA > 2020-02-12 19:48:50.255 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:bai:740379ea:08:bai_boiler_temp-flow#temp-flow" with "FF 08 B5 09 03 0D 18 00 BC" ... > 2020-02-12 19:48:50.255 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ... > 2020-02-12 19:48:50.417 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D1800| > 2020-02-12 19:48:50.568 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|-s FF 08B509030D1800:03a60400| > 2020-02-12 19:48:50.568 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|ff08b509030d9800 05670498fb00| > 2020-02-12 19:48:50.569 [TRACE] [dev.ebus.command.EBusCommandRegistry] - Skip matching command due to invalid response data length ... [bai.boiler.temp_return:GET] > 2020-02-12 19:48:50.569 [TRACE] [dev.ebus.command.EBusCommandRegistry] - DATA: FF 08 B5 09 03 0D 98 00 B7 00 05 67 04 98 FB 00 3A 00 AA > > > 2020-02-12 19:48:50.571 [DEBUG] [ng.ebus.internal.handler.EBusHandler] - Handle received command by thing Vaillant BAI00 (08) with id ebus:bai:740379ea:08 ... > 2020-02-12 19:48:50.571 [TRACE] [bus.service.parser.EBusParserService] - No command method matches the telegram FF 08 B5 09 03 0D 98 00 B7 00 05 67 04 98 FB 00 3A 00 AA ... > 2020-02-12 19:48:50.571 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_flow with value 74.375 > 2020-02-12 19:48:50.571 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram FF 08 B5 09 03 0D 98 00 B7 00 05 67 04 98 FB 00 3A 00 AA > 2020-02-12 19:48:50.571 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key status with value 0 > 2020-02-12 19:48:51.246 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:bai:740379ea:08:bai_boiler_state-thermostat-24V#state-thermostat-24V" with "FF 08 B5 09 03 0D 0E 00 E2" ... > 2020-02-12 19:48:51.246 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ... > 2020-02-12 19:48:51.419 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D0E00| > 2020-02-12 19:48:51.537 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|-s FF 08B509030D0E00:0101| > 2020-02-12 19:48:51.537 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<--|ff08b509030d1800 03a60400| > 2020-02-12 19:48:51.538 [TRACE] [dev.ebus.command.EBusCommandRegistry] - Skip matching command due to invalid response data length ... [pmw.pmw.temp_d_acutal_tapping:GET] > 2020-02-12 19:48:51.539 [TRACE] [dev.ebus.command.EBusCommandRegistry] - DATA: FF 08 B5 09 03 0D 0E 00 E2 00 01 01 9A 00 AA > 2020-02-12 19:48:51.539 [DEBUG] [s.internal.handler.EBusBridgeHandler] -
Is this a configuration file issue? Iām not sure how to fix them. Do you want an issue creating to track this? And if so which project would you like it in? Do you need any more logs to help with this or is this enough.
Thanks
John
No, you should change the log level back to debug or info. Trace messages are for me 