Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation related to auto ventilation #10

Open
michaelarnauts opened this issue Dec 20, 2019 · 24 comments
Open

Documentation related to auto ventilation #10

michaelarnauts opened this issue Dec 20, 2019 · 24 comments

Comments

@michaelarnauts
Copy link
Owner

I've noticed 225 and 226 are related to the automatic mode.

My ventilation was running with a low fan speed, and in auto mode with humidity protection active.

Detected a high humidity (SENSOR mode active). The fan started spinning high.
225 = 2
226 = 300

Fell back to normal mode.
225 = 1
226 = 100

@michaelarnauts
Copy link
Owner Author

@decontamin4t0R have you played with these values?

  • Maybe 226 / 100 is the current fan mode? Strange that the value is *100.
  • 225 might be a status mode? 1 = NORMAL, 2 = SENSOR?

@decontamin4t0R
Copy link
Contributor

I think that 225 indicates that one of the protections is active, and 226 is either the protection itself or the sensor which caused the protection to go active... Do you still have the value of 230 handy? They are the ventilation constraints, so the bit 27 should be 1...

@michaelarnauts
Copy link
Owner Author

I wasn't logging 230 unfortunately. How did you get this number, and how did you found out about the bits? Have you perhaps documented this somewhere?

@michaelarnauts
Copy link
Owner Author

230 isn't even in the RPDO_TYPE_MAP, so I don't know the size. I've created that map some time ago by using the app and going trough most menus and capturing what each sensor size was.

@decontamin4t0R
Copy link
Contributor

The App contains the 230 as ventilation config constraints, UINT64, bitfield. The 27 is the bit for either VentConfConstraintHumidityProtectionLong or VentConfConstraintHumidityProtection.
For some more PDOs, you can check the https://github.com/decontamin4t0R/zcan/blob/master/mapping2.py although im sure it does not contain all of them

@decontamin4t0R
Copy link
Contributor

decontamin4t0R commented Dec 20, 2019

oops, just checked my notes again:
225 DISABLED/ACTIVE/OVERRULING
226???, UINT16
227, UINT8, Unsigned Percentage bypass state
228, UINT8, Unsigned Percentage UnitStatus.FrostProtectionUnbalance

@michaelarnauts
Copy link
Owner Author

The App contains the 230 as ventilation config constraints, UINT64, bitfield. The 27 is the bit for either VentConfConstraintHumidityProtectionLong or VentConfConstraintHumidityProtection.
For some more PDOs, you can check the https://github.com/decontamin4t0R/zcan/blob/master/mapping2.py although im sure it does not contain all of them

Did you succeed in decompiling of the app? I've tried this approach, and it gave me the protocol buffers file, but I could never find the PDO ID's.

@decontamin4t0R
Copy link
Contributor

yeah... you can just take the decompiled source, its obfuscated but i was able to give the classes and packages distinguishable names, so you know that the class c072a or so is used there etc.

@decontamin4t0R
Copy link
Contributor

Yes, just confirmed. When you set humidity protection to on or to autoonly and have the ventilation in auto, 225 is 1. 0 if humidity protection = disabled or autoonly and manual.

@HalliHalloSchatz
Copy link

Hello,

I have a "good" deobfuscated set off an older app. My problem ist, that I am not a programmer. I can not find the correct class, where the description is.

@michaelarnauts
Copy link
Owner Author

I've tried a lot of tools to deobfuscate the app, but due to a lot of setters and getters, and passing around of objects, it's not to easy to understand it.

I recently took a new look at it, and there is one class with all the pdo's, but these pdos tend to get replaced with constants from the java libs.

@decontamin4t0R
Copy link
Contributor

If you search for something or have a question, just ask, that is probably easier than looking into the code and getting a hang of it

@HalliHalloSchatz
Copy link

HalliHalloSchatz commented Feb 3, 2020

I can agree to:
225 = 1, when HumProtection is on, 2 when HumProtection overwrite the normal condition
226 = 100 (FanMode 1), 200 (FanMode 2) and 300 (FanMode 3) all value between the hundrets 100-200 and 200-300 are modulated the ventilation. I can follow these with the airflow-sensor.

My Operation Idea:
I use a central vacuum cleaner, that blow out the air from my house. I have a really negativ airpressure. Now I will activate the SupplyOnlyFan Mode to blow in the air. When the FrostProtection function is regulated the ventilation down until 50%, I will power down the vacuum cleaner. The FrostProtection is modulated the ventilator between 0% (Fan have full power) to 100% (Fans power down).
I have test these scenario manual on the display, and that works fine. Now I will do it automatically.

I search for the correct ventilation mode:
Auto / Manual / ManualUntil

SENSOR_OPERATING_MODE_BIS = 49
SENSOR_OPERATING_MODE = 56
shown -1

I found these in the file UnbalanceDetailFragment_ViewBinding.java:
seekBarUnbalance = ((AppCompatSeekBar)Attribute.getString(paramView, 2131559023, "field 'seekBarUnbalance'", AppCompatSeekBar.class));
unbalanceCurrentValue = ((TextView)Attribute.getString(paramView, 2131559022, "field 'unbalanceCurrentValue'", TextView.class));

I found these in the file VentControlDetailFragment_ViewBinding.java:
View localView = Attribute.getInstance(paramView, 2131558964, "field 'modeRow' and method 'rowModeClicked'");
modeRow = localView;
a = localView;
localView.setOnClickListener(new VentControlDetailFragment_ViewBinding.1(this, paramVentControlDetailFragment));
modeValue = ((TextView)Attribute.getString(paramView, 2131558965, "field 'modeValue'", TextView.class));
modePicker = ((NumberPicker)Attribute.getString(paramView, 2131558966, "field 'modePicker'", NumberPicker.class));

I will show on my central monitor these condition warnings:
I found these in file AlertController.java:
b.put(Integer.valueOf(62), new e(this, "Unbalance_ERR", true, new StringBuilder("Error.ComfoAirQ.Unbalance_ERR")));
b.put(Integer.valueOf(61), new e(this, "T_22_frost_ERR", false, new StringBuilder("Error.ComfoAirQ.T_22_frost_ERR")));
b.put(Integer.valueOf(77), new e(this, "Filter_alarm_flag", false, new StringBuilder("Error.ComfoAirQ.Filter_alarm_flag")));
b.put(Integer.valueOf(78), new e(this, "Filter_ext_ERR", false, new StringBuilder("Error.ComfoAirQ.Filter_ext_ERR")));
b.put(Integer.valueOf(79), new e(this, "Filter_warning_flag", false, new StringBuilder("Error.ComfoAirQ.Filter_warning_flag")));
b.put(Integer.valueOf(80), new e(this, "Standby_ERR", false, new StringBuilder("Error.ComfoAirQ.Standby_ERR")));

I found these lines in the file SensorVentDetailFragment_ViewBindings.java:
tempPassivePicker = ((NumberPicker)Attribute.getString(paramView, 2131558935, "field 'tempPassivePicker'", NumberPicker.class));
tempActivePicker = ((NumberPicker)Attribute.getString(paramView, 2131558938, "field 'tempActivePicker'", NumberPicker.class));
humComfortPicker = ((NumberPicker)Attribute.getString(paramView, 2131558941, "field 'humComfortPicker'", NumberPicker.class));
humProtectionPicker = ((NumberPicker)Attribute.getString(paramView, 2131558944, "field 'humProtectionPicker'", NumberPicker.class));
tempPassiveValue = ((TextView)Attribute.getString(paramView, 2131558934, "field 'tempPassiveValue'", TextView.class));
tempActiveValue = ((TextView)Attribute.getString(paramView, 2131558937, "field 'tempActiveValue'", TextView.class));
humComfortValue = ((TextView)Attribute.getString(paramView, 2131558940, "field 'humComfortValue'", TextView.class));
humProtectionValue = ((TextView)Attribute.getString(paramView, 2131558943, "field 'humProtectionValue'", TextView.class));

@decontamin4t0R
Copy link
Contributor

decontamin4t0R commented Feb 3, 2020

My notes:

deactivate exhaust fan: (RMI: 0x8415 0601 0000 0000 FFFF FFFF 01)
    cansend can1 1F015057#00 84 15 06 01 00 00 00
    cansend can1 1F015057#81 00 FF FF FF FF 01
  remove "deactivate exhaust fan": (RMI: 0x85150601)
    cansend can1 1F011074#85 15 06 01
deactivate supply fan: (RMI: 0x8415 0701 0000 0000 FFFF FFFF 01)
    cansend can1 1F015057#00 84 15 07 01 00 00 00
    cansend can1 1F015057#81 00 FF FF FF FF 01
  remove "deactivate supply fan": (RMI: 0x85150701)
    cansend can1 1F011074#85 15 07 01
(you need to remove the spaces in the commands after #)
0x84: activate timer, 0x85: deactivate timer
0x15: Scheduling unit
0x06: Exhaustfan, 0x07: Supplyfan

for the unbalance bit, check pdo 230 at bit 62
and for the frost disbalance percentage, check PDO 228

@HalliHalloSchatz
Copy link

thank you.
I will add PDO 228. I have no idea, where I can check PDO 230... I am not a programmer, sorry. I will use the openhab_gw code for my tests.

I found in the file DescriptorProtos.java:
public static final class DescriptorProto
extends GeneratedMessage
implements DescriptorProtos.DescriptorProtoOrBuilder
{
public static final int ENUM_TYPE_FIELD_NUMBER = 4;
public static final int EXTENSION_FIELD_NUMBER = 6;
public static final int EXTENSION_RANGE_FIELD_NUMBER = 5;
public static final int FIELD_FIELD_NUMBER = 2;
public static final int NAME_FIELD_NUMBER = 1;
public static final int NESTED_TYPE_FIELD_NUMBER = 3;
public static final int ONEOF_DECL_FIELD_NUMBER = 8;
public static final int OPTIONS_FIELD_NUMBER = 7;
public static Parser PARSER = new AbstractParser()

@HalliHalloSchatz
Copy link

Frost protection unbalanced not working.
I have the condition, that the supply fan power down, because frost protection unbalanced get to 100% in the official app. The value in this implementation have no reaction shown

@decontamin4t0R
Copy link
Contributor

Can you tell me more about your implementation? How do you monitor the values?

@hme0354
Copy link

hme0354 commented Apr 12, 2020

I found out some new values (I hope they are correct ;) ):

SENSOR_PROFILE_TEMPERATURE = 67 ==> temperatureprofile (0=normal; 1=cold; 2 = warm)
SENSOR_FAN_MODE_SUPPLY = 70 ==> fan supply (only supply = 1; only exhaust = 0; supply & exhaust = 0)
SENSOR_FAN_MODE_EXHAUST = 71 ==> fan exhaust (only exhaust = 1; only supply = 0; supply & exhaust = 0)
SENSOR_AWAY = 16 ==> if LOW, MEDIUM or HIGH = 1; if AWAY = 7
SENSOR_BYPASS_ACTIVATIONSTATE = 66 ==> active 1; auto 0; deactivated 2

jonesPD added a commit to jonesPD/comfoconnect that referenced this issue Jun 7, 2020
Added some of the PDOs (those I also tried) indicated by hme0354 in post michaelarnauts#10 (comment)
jonesPD added a commit to jonesPD/comfoconnect that referenced this issue Jun 7, 2020
Added some of the PDOs (those I also tried) indicated by hme0354 in michaelarnauts#10 (comment)
@jonesPD jonesPD mentioned this issue Jun 7, 2020
michaelarnauts pushed a commit that referenced this issue Jun 7, 2020
Added some of the PDOs (those I also tried) indicated by hme0354 in post #10 (comment)
michaelarnauts pushed a commit that referenced this issue Jun 7, 2020
Added some of the PDOs (those I also tried) indicated by hme0354 in #10 (comment)
@pesmi30
Copy link

pesmi30 commented Jun 9, 2020

My ComfoAirQ has a 'Comfofond' (https://tinyurl.com/y9ug34ao) attached.
I would love to read the status of the terrestrial heat collector and the temperature of the brine.
Both aare visible in the Zehnder app, but I don't know the sensor-numbers, so I don't know how I can change the program I use (I use an adapted version of the example.py)

@michaelarnauts
Copy link
Owner Author

I think the best way is to just try out some sensors id's and compare the values with what you see in the app. That's how I found out the existing sensors.

@decontamin4t0R
Copy link
Contributor

Checkout the following:

416, Temperatur Outdoor air temperature
417, Temperatur Ground temperature ComfoFond
418, UINT8, Unsigned Percentage GHE State
419, BOOL GHE Present?

@jonesPD
Copy link
Contributor

jonesPD commented Jun 10, 2020

In relation to #10 (comment), I've monitored PDO 225, 226 and 230 over the past days, because I know my system increases fan speed every time we take a shower (after the manual boost mode period has passed). And indeed, I see the same behavior as HalliHalloSchatz describes in his earlier post (#10 (comment)):

225 = 1, when HumProtection is on, 2 when HumProtection overwrite the normal condition
226 = 100 (FanMode 1), 200 (FanMode 2) and 300 (FanMode 3) all value between the hundrets 100-200 and 200-300 are modulated the ventilation. I can follow these with the airflow-sensor.

I'll continue monitoring PDO 225 and 226 to see if HumidityComfort or TemperaturePassive triggers different behavior.

Monitoring PDO 230 did NOT result in any messages pushed. Perhaps I haven't configured it properly, since it is not in the RPDO map, I needed to guess its type and set it to 3. But I'm not even sure UINT64 as indicated by decontamin4t0R is supported in the present release.
@michaelarnauts, any suggestions?

@decontamin4t0R
Copy link
Contributor

decontamin4t0R commented Jun 11, 2020

PDO 230 should in fact be pushed regularly - everytime you have a ventilation constraint affecting the current airflow. My ventilation pushes 230 when I manually select level 3 as 0x600000000402, it limits the airflow because my bypass is active. (Bit 1 = general constraint? and Bit 10 = VentConfConstraintBypass, or Bit 45 = general long constraint? and Bit 10 = VentConfConstraintBypassLong).

PS: I could not find where comfoconnect should not work with UINT64. Maybe try INT64?

@jonesPD
Copy link
Contributor

jonesPD commented Jun 11, 2020

Changing the RPDO type to 4 now results in 64 bit values being pushed, just 0s so far, but i'll keep monitoring it and see what follows. Thx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants