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
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!
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:
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.
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.
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:
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:
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
