Yes, I change the enthalpy physically regulary. In winter I use the enthalpy and in summer I don’t use the enthalpy to decrease the humidity, like a air conditioner does. Maybe, this is a speccial case. For me, it would be nice if I could change this setting with openhab, like it was possible in the V1-binding.
Hmm…didn’t really think of such a use case. So in the current implementation there is no option to inform the device about the enthalpy switch from within openhab. Only thing you could do is to switch to CCEase control temporarily and change it there.
I will rethink again the implementation of these device options as configuration options of the thing, but I will need to find a way to make this failsafe for the common user. (And I still think that providing these options as channels is not the way to go from a logical openHAB perspective)
Hi Hans, thank you for implementation ComfoAir Binding to OH2.x version. I install 2x version few days ago and it works very smoothly. Really good job.
Sometimes I have problem with take a control under my comfoair when I change bindingControl#activate switch to ON state, but I had the same problem with 1x binding too.
I want to give you few my remarks:
- Protocol gives you possibility to read if the recu is frozen. In 1x version it was freeze_mode command. This state is shown at CCEase and I think it is very usefull for displaying errors in opehHAB.
- Menu 5x group can be usefull. I use it to switch chimney ON/OFF (P50 menu). ie during winter time my chimney state is ON and I can’t use fan-in only or fan-out only (acc. to safety). During summer I don’t use chimney, so I switch it OFF in recu and I can use outlet only. I use EWT switch too (P60 menu). As you can read upper the_elk use it for enthalpy control. So it will be very desirable to give users the ability to use these options as a switch channels.
Of course these options are critical for ComfoAir work and you are right that they should be used carefully. But I think we are advanced users
- Binding properties show me that my ComfoAir has heater Installed. But it is not true. My P55 menu is 0, so it means heater is not installed. It must be a bug in binding.
- The same is with cookerhood property. Binding shows Installed, but P53 menu is 0 at CCEase = not installed. It is bug too.
- You didn’t implement analog control property at all (P58 menu). I don’t use it, but maybe someone else…
- Now you combine errors to four types: current, last, prelast and preprelast. Maybe it is good idea. With 1x binding I could use map transformation to translate each type of errors - it was simply. With 2x binding I can do it by rule - more complicated but works. However I chose to keep all type of protocol errors because it is more clear to read for me.
Thank you once again for your effort.
Hi Grzegorz, thanks for your feedback. Seems that some issues show up now that the number of users rises 
.
- If you mean the “snowflake” symbol on the CCEase, I couldn’t find a clear mention in any manual what that actually means, but I’m pretty sure that it just shows if the frost protection (preheater) is active. So this functionality should be covered by the
menuP9#frostStatechannel (or more detailed by the channels of thepreheater#channel group) - Seems that such use cases are more used than I could think of. As mentioned above I will try to implement them as device configuration options. The issue with this is that I’m not yet sure how to implement this without having every user to set this to the right settings on their own (but I’m sure I’ll find a solution). I still prefer this over an implementation as items/channels.
- You are right. This is indeed a bug (or rather bad coding
). Actually, chimney, cookerhood and heater are all shown as installed if at least one of them is present. Will fix this ASAP. - see 3.
- Actually, this is implemented, but a but hidden under
analogRF#analogPriority. Not sure why I didn’t handle this as property as well, but I will add it to configuration when changing the other properties. - Yes, thought a while about this and found the current solution to be most useable, though this is for sure depends on personal preferences. Sure, you will need a rule to split this up in individual errors and translate to something descriptive. However, with the old implementation you would have to add 17 individual items to cover all errors, which you have to check individually in case of an error. Additionally, I considered it as highly unlikely, that different errors are coming up simultanuously (I can’t remember my device showing any single error in the last 4 years).
So again, thanks for your feedback. I will work on the mentioned TODOs ASAP.
You are right. Your errors look elegant.
Yes, frost = snowflake symbol on the CCEase.
But it is not the same as active preheater, but of course this two settings could work at the same time. Frost symbol means that ComfoAir is frozen (fans are stoped at this time). So frost means “you don’t have ventilation” - thats why it is good to have this report. Preheater starts work earlier and ComfoAir could still work at this time (fans are still rotate). Preheater is to protect the ComfoAir against freezing.
If the ComfoAir doesn’t have preheater its active property doesn’t work, but it has frozen state quite often in winter.
When I change the ComfoAir Binding 1x my idea was: get openHAB full functionality of CCEase. That’s what I would expect from.
Frost symbol means that ComfoAir is frozen (fans are stoped at this time). So frost means “ you don’t have ventilation ” - thats why it is good to have this report. Preheater starts work earlier and ComfoAir could still work at this time (fans are still rotate).
As said, I couldn’t find any official document that describes the meaning of the symbol (do you have any source?). It seems reasonable to me that this indicates a frozen device (or rather the device being in a certain “frost mode”), but I can’t imagine that this is only indicated by a symbol on the CCEase (thats how it was implemented in v1) rather than a certain device state. However, I can only roughly guess which value this would be, but I could think of the frost state channel: menuP9#frostState
When I change the ComfoAir Binding 1x my idea was: get openHAB full functionality of CCEase . That’s what I would expect from.
Definitely makes sense, but I made the experience myself during testing, how easy these values are changed and how less I actually know about my own device (it’s a rented apartment, so I didn’t buy or install it myself). I just didn’t want to force each user having to set their exact configuration for the thing. However, though suggested otherwise during the initial binding PR review, after the discussion in the other thread I will reimplement these device options as channels again.
You have this information in manual:
“2.1.4 Frost protection
The ComfoAir is also fitted with a frost protection device. This is an automatic protective system that
temporarily reduces (or even briefly stops) the supply of outdoor air to the ComfoAir if there is a risk
of freezing in the ComfoAir. This can occur in the event of moderate to sharp frost during the winter
months.”
That’s clear and according to that I suppose that this should be covered by menuP9#frostState. But I couldn’t find any definitive statement that this is what the snowflake symbol indicates. That symbol, as well as the water drop symbol, which I assume shows the enthalpy state, is nowhere referenced in any documentation.
Yes, you are right, I didn’t find any description what CCEase icons exactly means. I thought earlier that P95 menu is preheater state, but now I think I was wrong. It looks like P9 menus are what CCEase shows. I am sure P91 and P92 are the same as CCEase icons - I checked it. Other options I’m not sure.
If P95 menu is frozen state (snowflake icon) it should not be dynamic switch in your binding.
I submitted a PR that re-implements the device options as channels. Since I’m not sure, if this gets backported to OH 2.5.x as it is a little more than a bug fix, here is an appropriate jar file.
NOTE: I changed the channel names of the ewt-channels from --> to omit breaking changes this renaming was reverted (JAR updated).ewt... to ghx... So you maybe have to adapt your items accordingly.
Gents,
I’m now on OH3 M2 and on progress to finalize Comfoair setup. I’m pretty sure we get more out of it in the future. Currently still need to adjust some configs after migration.
If I can test something specific let me know.
BTW: I would still love to keep the CC Sense connected. but for the moment it is detatched showing Comm Error on the display.
I don’t know if you had this working in the v1 binding, but from my knowledge nothing should hve changed regarding the connection. However, from the discussions above it seems to also be depending on the individual devices, if this is possible or not. Maybe anyone who has both options working in parallel could post a wiring scheme of their setup.
Personally, I use a physical switch to manually switch the connection of the data wires between OH and CCEase on demand.
Dear Hans
It was working in v1 (Grzegorz variant) more or less smoothly with the CC Sense active. So yes.
As I have it decoupled now I would have expected the earlier shaky status to disapear. But grepping for FanLevel shows:
2020-11-15 08:40:29.683 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 08:41:24.384 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 08:54:29.704 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 08:56:24.399 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:11:29.725 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:12:24.627 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:23:29.938 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:24:26.938 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:28:29.740 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:29:28.048 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:35:29.949 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:36:26.950 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:38:29.854 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:40:24.756 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:45:30.267 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:46:24.460 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 09:54:29.881 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 09:56:24.482 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 10:13:30.008 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 10:14:24.608 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
2020-11-15 10:17:29.820 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from 1 to UNDEF
2020-11-15 10:18:25.719 [vent.ItemStateChangedEvent] - Item ‘AiringFanLevel’ changed from UNDEF to 1
The same appears for the TargetTemperature setting:
2020-11-15 07:09:24.675 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from UNDEF to 21.0 °C
2020-11-15 07:25:37.705 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from 21.0 °C to UNDEF
2020-11-15 07:26:23.492 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from UNDEF to 21.0 °C
2020-11-15 07:36:31.210 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from 21.0 °C to UNDEF
2020-11-15 07:37:27.013 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from UNDEF to 21.0 °C
2020-11-15 08:00:32.038 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from 21.0 °C to UNDEF
2020-11-15 08:01:24.940 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from UNDEF to 21.0 °C
2020-11-15 08:19:31.259 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from 21.0 °C to UNDEF
2020-11-15 08:20:24.962 [vent.ItemStateChangedEvent] - Item ‘AiringTargetTemperature’ changed from UNDEF to 21.0 °C
Which doesn’t make sense to me. And I think it should not be this way.
|_| 3.0.0.M2 - Milestone Build
openhab> bundle:list | grep -i comf
228 │ Active │ 80 │ 3.0.0.M2 │ openHAB Add-ons :: Bundles :: ComfoAir Binding
Cheers
Stefan
@smhaller is this only happening for those two items? Does this effect changes/commands from rules only or also from manual interaction? The timestamps suggest that this is not happening on periodical refreshes, so the basic communication between OH and ComfoAir seems to work correctly.
Would you mind posting your current items and rules (again)?
@boehan - Hans
No these are not the only two. Following is a list of events for just Nov. 16th
events.log (18.4 KB)
I haven’t found out yet, what the trigger for it is. But it appears not only when a manual interaction is set, change of fan level. It might be also related to a rule based change.
But enthalpy mode for instance is never changed at all and still get’s set to UNDEF
FanLevel should also not be changed in the middle of the night even through rule.
I’m currently in the progress to migrate from manual rules file to define them through UI.
But that should also not be the source of the problem here.
current items: Airing_items.txt (7.2 KB)
current rules: airing_rules.txt (2.2 KB)
You have some non-existent channels configured:
ewt_temperatur --> temperatures#ewtTemperature (as Number:Temperature)
is_ewt --> options#isEWT (as Switch; since OH3 M2 only)
ewt#TemperaturLow --> ewt#ewtTemperatureLow (as Number:Temperature)
ewt#TemperaturHigh --> ewt#ewtTemperatureHigh (as Number:Temperature)
filter_error_intern and filter_error_extern don’t exist in the new binding, but those are commented out anyway.
Not sure if these misconfigured items could be causing these issues and fixing them helps. If not, could you set loglevel to TRACE for a few minutes and provide a log?
Meanwhile I’ve adjusted those settings. Installed the Snapshot version and restarted the binding.
full trace log: comfoair.log (347.4 KB)
The issue still persists.
Do you have the event log for the same timeframe? From the trace log I can’t tell when the issues occur.
No problem.
events log from same timeframe: events.log (29.5 KB)
openhab.log from the same timeframe: openhab.log (45.5 KB)
