[OpenWebNet] Supporto centrale 4 zone

Ciao @giacob
si era pensato, assieme a @massi, di aprire un thread parallelo, in Italiano, per discutere del supporto alla centrale a 4 zone.

In passato ce l’avevo anche io, ora non più… per questo motivo il tuo supporto è fondamentale :slight_smile:
io ho un impianto che nasce “standalone” con 6 H4691 (che possono gestire in autonomia le 6 zone) al quale, per motivi di testing, affianco alla bisogna una 3550 (99 zone).
Con te copriamo anche il caso 4 zone con 3 localoffset.

Ho fatto delle modifiche veloci al binding per permetterti di testarne il funzionamento.
Facci sapere!


version date download link
3.4.2 ALPHA 1 19 Feb 2023 download
3.4.2 ALPHA 2 20 Feb 2023 download

Hi @aconte80, ok. How should I proceed to update to your snapshot? Preferably without losing my current configuration.

sono riuscito ad installare manualmente la 3.4.2 ALPHA 1. Mi riusciresti a spiegare meglio cosa è stato fatto?

Quando creo un thing bus_thermo_cu, non posso modificare l’indirizzo 0. Configurandolo manualmente ho notato è stata tolta la validazione, ma anche inserendo 0#1 continua a inviare i comandi hardcodati con #0 invece di #0#1.

Su quale branch state lavorando?

Questa sicuramente è da vedere meglio. dobbiamo lavorare con il where che viene configurato dall’utente:

  private String getWhere(String where) {
    if (this.isCentralUnit)
      return "#0"; // <--- why?
    return this.isStandAlone ? where : ("#" + where);

L’unica cosa significativa sui log è

2023-02-19 23:02:26.256 [DEBUG] [er.OpenWebNetThermoregulationHandler] - initialize() Is 4 zones Central Unit? true

Ciao Giorgio,
ottimo che sei riuscito ad installarlo senza perdere la configurazione (io di solito per questo mi creo una installazione parallela di OH su un’altra cartella)

hai ragione, mi era sfuggito con un ctrl-z di troppo quella riga. Ho pubblicato una nuova versione.

Bad news, adding some 4 zone cu events in OwnIdTest I discovered openwebnet4j library has the WhereThermo constructor broken. We have to work on that project first. I have a strange logging behavior, I don’t know why at runtime it doesn’t log any errors but clearly it can’t extract the zone #0#1. There is probably some exception hiding code somewhere.

English please, this is an international community !

1 Like

Hi guys, I prepared a solution proposal.

I decided to avoid the removal of the first # in the central unit deviceWhere. This causes several issues in where normalization logic and ownIdFromWhoWhere logic, because z#a is already used for actuators.
I decided to support both #0 format and the old 0 in the thing configuration, just for backward compatibility, but documentation should indicate the “full” where format with # character. I removed the readOnly property for the thermo central unit thing where parameter and updated the description.

in openwebnet4j library I decided to keep WhereThermo#zone as an integer for backward compatibility, and create a new WhereThermo#centralUnitId property which will contain the 4-zone cu unique id (e.g.: #0#1 will have zone=0 and centralUnitId=1). In case of 99-zone cu, the centralUnitId will be -1.

I’m proposing to avoid updateSetpoint processing in case the thermo message doesn’t contain a setpoint temperature, because this causes several broken updateState with 11.5°C. This is still not that robust in my opinion. We should iterate over it a little bit more.

I’m also proposing to avoid that handleSetpoint send a writeSetpointTemperature event if current mode is OFF, because this also enable the manual heating mode. This can be discussed, it’s a user experience aspect. I don’t like that I can accidentally switch-on heating touching the setpoint value. I prefer to explicitly use the operation mode.

org.openhab.binding.openwebnet.jar.pdf (263.2 KB)

Hi @giacob thank you for you proposal!
Me and @aconte80 ( who is already preparing a fix to WhereThermo to support also 4-zones CU), will look at your code and provide you feedback.

The other fixes you propose to the Thermo pet could be useful: it maybe necessary to split them in different PR/commits so that we can track each change.

Meanwhile : for Thermo discovery it would be useful if you send the following message using the official OWN client and copy here a screen of the output:


is there a way to export every message from the official openwebnet client? I can copy only one row. This command produces tons of events.

unfortunately no

@giacob can you confirm you have in your configuration:

  • one 4-zone CU with id=1 and controlling 4 actuators
  • one zone with id=2 and controlling 2 actuators
  • one zone with id=3 controlling 1 actuator
  • one zone with id=4 controlling 1 actuator

can you confirm this?

@giacob can you also post the output of this command:
(I am looking for how to discovery all 3 cases: 99-z CU, 4-z CU and all standalone)



here the results:

@giacob can you provide also the output of this command?


Command *#*1##===*#1004*#0*7##===

as expected, no events this time.

Hi all,

sorry to hijack the thread. I’m also trying to make a 4 zone central work with Openhab latest stable version 3.4.2 to no avail. I’ve configured a F454 gateway which works fine with the rest of the items. I’ve a Thermo zone configured set as shared:

which correctly handles its items, altough in read only mode only (the change I make there do not replicated physically):

I then configure a thermocu. but I only get communication errors:

This is the output of the discovery command on the OWN client:

What am I missing here? Thanks!

hi @marmata. If you can configure a OH4.0.0 test instance (maybe parallel to your OH3.4.2 production setup), we are testing a new version that provides support for 4-zone systems.
In case you want to test it, send me a PM

@massi sure I can clone my environment and update to 4.0.0 to test! I’m sending you a PM!