Open michaelarnauts opened 4 years ago
@decontamin4t0R have you played with these values?
226
/ 100 is the current fan mode? Strange that the value is *100.225
might be a status mode? 1 = NORMAL, 2 = SENSOR?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...
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?
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.
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
oops, just checked my notes again: 225 DISABLED/ACTIVE/OVERRULING 226???, UINT16 227, UINT8, Unsigned Percentage bypass state 228, UINT8, Unsigned Percentage UnitStatus.FrostProtectionUnbalance
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.
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.
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.
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.
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.
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
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));
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
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
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
Can you tell me more about your implementation? How do you monitor the values?
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
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)
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.
Checkout the following:
416, Temperatur Outdoor air temperature
417, Temperatur Ground temperature ComfoFond
418, UINT8, Unsigned Percentage GHE State
419, BOOL GHE Present?
In relation to https://github.com/michaelarnauts/comfoconnect/issues/10#issuecomment-581585751, 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 (https://github.com/michaelarnauts/comfoconnect/issues/10#issuecomment-581585751):
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?
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?
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.
I've noticed
225
and226
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