HECO2/doc/260618_내부댐퍼_모드변경시_미동작_수정.md

260618 수정 요약 (핸드오프용)

작업 PC 이전 시점 기준. 아래 상세 항목 (1)~(5) 의 최종 변경 정리.

변경 파일 (커밋 포함)

파일	변경 요지	관련 항목
Source/HECO2/User/MyMotor.c	모드전환 중(Damper_wait_time==5) 팬 강제 0 → 내부댐퍼 이동 게이트 보호	(3)
Source/HECO2/User/My_Homenet.c	모드변경 시 명령경로 즉시 Fan_Speed_Setting 호출 주석(L259/293) — 마스터 정렬	(1)
Source/HECO2/User/My_Hood.c	후드연동 모드변경 시 즉시 Fan_Speed_Setting 주석(L192/207) — 마스터 정렬	(1)
Source/HECO2/User/My_system.c	스마트수면 거실(room1) CO2 무관 항상 CLOSE	(2)
TestProgram/PCDashBoard/MainWindow.xaml.cs	쾌적조리 버튼 강조=ComfortCook(L583), 활성=항상(L587)	(4)(5)
개발사양서/...DL_동작로직_260613.pptx	사양서 갱신(바이너리)	-

빌드 상태

• 펌웨어: cd SOURCE/HECO2 && bash build.sh all → 경고/오류 0.
• 대시보드: dotnet publish ErvDashboard.csproj -c Release → 오류 0 (NU1701 경고만).
• 대시보드 exe: TestProgram/PCDashBoard/bin/Release/net10.0-windows/win-x64/publish/ErvDashboard.exe

실장비/대시보드 확인 필요(테스트 대기)

• 환기→공청 반복 전환 시 내부댐퍼 매번 이동(간헐성 해소). 전환 시 팬이 잠깐 0까지 멈췄다 복귀하는 것이 정상.
• 스마트수면 진입 시 거실 닫힘 + 침실 CO2 개폐.
• 쾌적조리 버튼이 후드 연결/전원 무관하게 항상 토글되는지.

미적용/보류

• (선택) 쾌적조리를 스마트수면/안심회복과의 상호배타에서 분리(사양상 독립 토글) — SubMode_Click L401~406.
• (보류) 펌웨어 쾌적조리를 Ext_Run_Mode==2 상태머신으로 배선(현재 My_system 846/952 dead code). 1차 대시보드 수정으로 충분한지 검증 후 결정.
• 1차 명령경로 주석(My_Homenet/My_Hood)은 (3) 게이트 보호로 중복이나 무해 — 정리 보류.

---

260618 내부댐퍼 — 운전모드 변경 시 미동작 수정 (1차: 명령경로 즉시 팬설정 제거)

증상

• 환기 → 공청 전환 시 팬은 정상 동작하는데 내부댐퍼(본체 6개)가 안 움직임.

원인 (마스터 D:\Project\nuvoton\HERV_DL_MH_2nd\Program 비교로 확정)

• 내부댐퍼 이동 트리거(Fan_Speed_process가 모드변경 시 Damper_Mode() 호출)는 HECO2/마스터 동일하게 존재. 빠진 게 아님.
• 그 트리거는 "팬이 0까지 감속"되어야 발동하도록 게이팅됨(공기 흐름 중 댐퍼 미동작 의도): 모드변경 → 팬타깃0 → 팬=0 도달 → Damper_Mode 호출(댐퍼 이동) → 정렬(Step_Status==0x3F) → 팬 복원
• 마스터: 명령 핸들러가 팬 타깃을 안 건드림 → 팬이 0 도달 → 댐퍼 이동.
• HECO2: 명령 핸들러가 모드변경 즉시 Fan_Speed_Setting() 직접 호출 → 팬 타깃이 곧바로 운전속도로 올라감 → 팬이 0에 도달 못 함 → if(Fan!=0) if(wait==5) goto PASS1 게이트가 Damper_Mode 영원히 스킵 → 댐퍼 미동작, 팬만 정상.
• 마스터엔 없고 HECO2에만 추가된 명령경로 Fan_Speed_Setting 호출이 게이트를 막은 것.

변경 파일/내용 (1차 = 모드 변경 시 호출만 제거, 풍량단수 변경 호출은 유지)

주석 처리(삭제 아님, 복원 용이). 마커: [모드변경댐퍼테스트]

• Source/HECO2/User/My_Homenet.c
  • L259 CTRL_POWER(전원ON→환기) Fan_Speed_Setting 주석
  • L293 CTRL_RUNMODE(운전모드 변경) Fan_Speed_Setting 주석 ← 보고 증상(대시보드 환기→공청)의 직접 경로
  • L306 CTRL_FAN(풍량단수만 변경)은 유지 (댐퍼 무관, 팬 단수 반응 필요)
• Source/HECO2/User/My_Hood.c
  • L192 후드ON(→환기) Fan_Speed_Setting 주석
  • L207 후드OFF(모드 복귀) Fan_Speed_Setting 주석
  • L219 후드 단수변경(풍량만)은 유지

핵심 결정

• 모드 변경 후 팬 복원은 Fan_Speed_process의 wait==1 호출(MyMotor.c 1018/1056/1090/1124, ③)이 담당 → 팬이 꺼진 채 남지 않음.
• RJ2(My_RJ2.c)·분배기(My_bunbaegi.c)는 두 소스 동일 → 미수정.
• 이번엔 "동작모드 변경 트리거 복원(①, 디퓨저 시퀀스 명령트리거)"은 보류 — ②(땜빵) 제거만으로 댐퍼가 움직이는지 먼저 검증.

빌드 결과

• cd SOURCE/HECO2 && bash build.sh all → 성공, 경고/오류 0.
• text 43920 / data 1940 / bss 3388 (HERV.elf). (이전 44008 → 코드 제거로 감소)

미해결 / 후속

• 실장비/시뮬레이터에서 환기→공청 시 내부댐퍼 이동 확인 필요(특히 고풍량 전환 시 팬 감속 대기시간 체감).
• 검증 후: 필요하면 ①(동작모드 변경 트리거 = MyMotor.c 디퓨저/팬복원 타이밍의 명령 트리거)도 마스터 정렬 검토.
• 풍량단수만 바꿀 때(L306/L219) 팬 즉시 반응 정상인지 확인.

---

260618 (2) 스마트수면 모드 — 거실 댐퍼 미닫힘 수정

증상

• 스마트수면 동작 중 거실 댐퍼가 열려 있음. 사양(개발사양서 8p)상 거실은 항상 CLOSE여야 함.

사양 (개발사양서 8p, 스마트수면)

• 환기 수동·풍량 1단 고정.
• 초기상태: 거실 CLOSE, 침실1~3 OPEN.
• 거실 급기(SA)/배기(RA) 모두 X(항상 닫힘) — CO2 무관.
• 침실1~3: CO2 >= 1000 PPM → 해당 침실 OPEN, CO2 <= 800 PPM → CLOSE.

원인

• My_system.c Air_Quality_damper_process() Ext_Run_Mode == 4 블록.
• 진입 1회(L905)는 거실(room1)을 올바르게 CLOSE 하지만, 매 틱 CO2 루프가 Room_Num = 1부터 돌아(L916) 거실까지 CO2 기준으로 다시 OPEN 시킴.
• 룸 인덱스: room1=거실, room24=침실13.

변경 파일/내용

• Source/HECO2/User/My_system.c (스마트수면 매 틱 처리)
  • 거실(room1) 매 틱 강제 CLOSE + LED off 추가.
  • CO2 히스테리시스 루프 시작을 Room_Num = 1 → Room_Num = 2 (침실1~3만 개폐).

빌드 결과

• bash build.sh all → 성공, 경고/오류 0. text 43940 / data 1940 / bss 3388.

후속

• 실장비에서 스마트수면 진입 시 거실 닫힘 + 침실 CO2 개폐 확인.

---

260618 (3) 내부댐퍼 미동작 — 진짜 원인(타이밍 레이스) 수정

추가 진단 (사용자 확인)

• 테스트 경로 = PC 대시보드(My_Homenet 경로).
• 팬 거동 = 0까지 안 내려감, 그리고 간헐적(어쩌다 정상 댐퍼 동작).
• → 전형적 타이밍 레이스. (1)차 수정으로 CTRL_RUNMODE(293)는 막았지만, 대시보드가 모드변경과 함께 보내는 CTRL_FAN(306, 유지됨) 이 모드전환 감속창(팬→0 구간)에 끼어드는 타이밍이면 팬 타깃을 다시 켜서 팬이 0 도달 못 함 → Damper_Mode 게이트 안 열림.
• 끼어드는 타이밍이 아니면 정상 → 간헐성 설명됨.

수정 (2차 = 게이트 보호, 단일 지점)

• Source/HECO2/User/MyMotor.c Fan_Speed_process() PASS1 직후(정상운전 분기, VSP 제외):
  • Damper_wait_time == 5(=모드전환 진행중 전용 신호. 4개 모드 진입에서만 set, Step 정렬 전까지 5 유지)일 때 Target_Fan1_Speed = 0; Target_Fan2_Speed = 0; 강제 → 명령경로(CTRL_FAN 등)가 감속창에 끼어들어도 무시하고 팬을 0으로 떨굼 → 댐퍼 이동 보장.
  • 전환 완료(Step_Status==0x3F) 후 wait가 5→1로 감소하며 wait==1에서 Fan_Speed_Setting(③)이 팬 복원.
• 풍량단수만 변경(같은 모드, wait==0)은 force-zero 미적용 → CTRL_FAN(306) 즉시 반응 유지.

동작 변화(주의)

• 이제 환기→공청 전환 시 팬이 잠깐 0까지 멈췄다가(댐퍼 이동) 다시 도는 게 정상(설계상 공기흐름 중 댐퍼 미동작). 기존 "안 멈추던" 거동에서 바뀜.

빌드 결과

• bash build.sh all → 성공, 경고/오류 0. text 43948.

후속

• 실장비에서 환기→공청 반복 전환 시 매번 댐퍼 이동(간헐성 사라짐) 확인.
• 같은 모드 풍량단수 변경 시 팬 즉시 반응 정상 확인.

---

260618 (4) 쾌적조리 재선택 안됨 — 대시보드 버튼 강조 버그

증상

• 쾌적조리 동작 마치고 이전 모드 복귀 후 다시 쾌적조리 버튼 누르면 선택(ON)이 안 됨. 눌러도 토글 반응이 안 보임.

사양 (개발사양서 9p)

• 쾌적조리 = 운전모드가 아닌 '후드 연동 UI 토글 스위치'. 사용자가 켤 때까지 ON 유지.
• 3.1 매트릭스: 토글 ON + 후드꺼짐 = 대기(본래 모드 가동), 토글 ON + 후드켜짐 = 메이크업 강제연동.
• 3.3 Roll-back: 후드 OFF 후 20분 환기 약 후 이전 모드 복귀 — 이는 메이크업 복귀 타이밍이지 토글 OFF가 아님.
• → 토글은 계속 armed가 정상. 펌웨어 Hood_YeunDong_Enable(토글)은 정상.

원인 (순수 대시보드 버그)

• _state.ComfortCook = status byte4 bit1 = 펌웨어 Hood_YeunDong_Enable(토글 Enable).
• 대시보드가 토글 판단은 _state.ComfortCook(L386), 버튼 강조는 _state.HoodRunning(L581, 후드 실제 가동중) 으로 서로 다른 변수 사용.
• 대기/Roll-back 상태(HoodRunning=0, ComfortCook=1)에서 버튼이 꺼져 보이고, 다시 누르면 next=!ComfortCook=false → OFF 전송 → "선택 안됨".

변경 파일/내용

• TestProgram/PCDashBoard/MainWindow.xaml.cs L581:
  • SetActive(ComfortCookBtn, _state.HoodRunning); → SetActive(ComfortCookBtn, _state.ComfortCook);
  • 토글 상태(=Enable)를 강조하도록 일치. (모드/풍량 잠금 subActive는 사양 3.1대로 HoodRunning 유지 — 대기 중 본래 모드 조작 허용.)

빌드 결과

• dotnet build ErvDashboard.csproj → 오류 0 (NU1701 경고 9개는 기존 패키지 호환 경고, 무관).

미해결 / 후속(선택)

• 사양상 쾌적조리는 운전모드 시나리오(스마트수면/안심회복)와 독립인데, 대시보드는 셋을 상호배타 처리(SubMode_Click L401~406, ApplySubModeLocal). 스마트수면/안심회복 켤 때 쾌적조리가 강제 OFF됨 → 사양과 불일치 가능. 필요 시 분리 검토.

---

260618 (5) 쾌적조리 버튼 활성(Enable)이 후드 상태에 묶임 — 독립 토글로 수정

증상

• 쾌적조리 버튼이 디폴트 비활성, 전원 ON/후드 연결 시에야 토글됨. 사양 9p 3.1상 쾌적조리는 후드 연결과 무관한 독립 토글.

원인

• MainWindow.xaml.cs L587 ComfortCookBtn.IsEnabled = !subActive || _state.ComfortCook;
• subActive = SmartSleep || HoodRunning || ReliefRecover 에 HoodRunning(후드 가동중) 포함 → 후드 상태가 쾌적조리 버튼 활성을 좌우.

변경 파일/내용

• TestProgram/PCDashBoard/MainWindow.xaml.cs L587:
  • ComfortCookBtn.IsEnabled = !subActive || _state.ComfortCook; → ComfortCookBtn.IsEnabled = true;
  • 쾌적조리는 독립 토글 → 후드 연결/가동·다른 시나리오와 무관하게 항상 토글 가능. (모드/풍량 버튼은 기존대로 subActive 잠금 유지.)

빌드/배포

• dotnet publish ErvDashboard.csproj -c Release → 오류 0. publish 단일 exe 갱신.

---

260618 (6) 쾌적조리 — 후드 전원 OFF 시 토글 자동 해제

요청 (사장님)

• 쾌적조리 선택 → 후드 동작 → 후드 전원 OFF 했을 때, 대시보드 쾌적조리 버튼이 저절로 꺼지게(자동 해제) 해달라.
• 현재: 후드 OFF 후 이전 모드로 운전은 복귀되나 쾌적조리 토글은 armed 유지 → 수동으로 눌러야 꺼짐.

사양 변경 주의

• 기존 문서화 사양(개발사양서 260613 9p 3.3)은 "후드 OFF는 메이크업 복귀 타이밍이지 토글 OFF가 아님 → 토글 armed 유지". 이번 요청으로 반대로 변경(후드 OFF=토글 자동 해제).

원인/구조 (정적분석)

• 대시보드 _state.ComfortCook ← STATUS byte4 bit1 ← 펌웨어 Hood_YeunDong_Enable. (byte5 bit0 HoodEnable 도 동일 변수)
• Hood_YeunDong_Enable 은 명령(My_Homenet.c CTRL_SUBMODE/CTRL_HOOD)으로만 set/clear, 펌웨어 자동 해제 없음 → 후드 OFF 후에도 1 유지 → 토글 계속 ON.
• 펌웨어 Ext_Run_Mode==2 쾌적조리 상태머신(My_system.c 846/952)은 대시보드 경로에서 dead code.

변경 파일/내용

• Source/HECO2/User/My_Hood.c Hood_process() 후드 OFF 전이 분기(Hood_Status==0, L197~):
  • Hood_YeunDong_Enable = 0; 추가. 마커 [쾌적조리자동해제].
  • 효과: 후드 단수 0 도달(전원 OFF) 시 펌웨어가 토글 해제 → STATUS byte4 bit1/byte5 bit0 모두 0 → 대시보드 버튼 자동 해제. 대시보드 수정 불필요.
• 부작용 없음 확인: 이 시점 Hood_Status=0·Hood_Yeundong_flag=0 이라 댐퍼 메이크업(My_system.c L1117)·룸컨 통지(My_RJ2.c L296) 이미 OFF 조건. 모드/풍량 복귀는 같은 분기에서 그대로 수행.

빌드 결과

• bash build.sh all → 성공, 경고/오류 0. text 43948 → 43952 (+4B), data 1940, bss 3388.

미해결 / 후속

• 실장비: 쾌적조리 ON → 후드 ON → 후드 전원 OFF 시 쾌적조리 버튼이 자동으로 꺼지는지 + 이전 모드 복귀 동시 확인.
• 엣지: 후드를 485 통신 두절(플러그 뽑힘) 로 끄면 Hood_Status 가 마지막 값 유지되어 OFF 전이가 안 뜰 수 있음 → 그 경우 자동해제 미동작. 필요 시 Hood_Conn_Timeout==0(통신두절)에도 해제 추가 검토.

---

260618 (7) 쾌적조리 미선택 + 후드 ON 시 다른 시나리오모드 버튼 잠김 수정

요청 (사장님)

• 쾌적조리를 누르지 않고 후드를 켰는데도 스마트수면/안심회복 등 다른 시나리오모드 버튼이 선택 불가(클릭 안 됨).
• 쾌적조리 미선택 상태에서 후드만 켜도 다른 시나리오모드 버튼은 선택 가능해야 함. (자동 켜짐이 아니라 '클릭 가능'.)

원인 (대시보드)

• MainWindow.xaml.cs L570 subActive 에 _state.HoodRunning 포함.
• HoodRunning = STATUS byte5 bit1 = Hood_Status != 0 = 후드 물리 가동중(쾌적조리 선택 무관, My_Homenet.c:131).
• 그래서 후드만 켜도 subActive=true → 스마트수면/안심회복/운전모드/풍량 버튼이 비활성(클릭 불가).
• 그러나 펌웨어 Hood_process() 는 Hood_YeunDong_Enable==1(쾌적조리 armed) 일 때만 모드/풍량을 건드림 → 쾌적조리 OFF면 후드가 켜져도 ERV 동작에 영향 없음 → 잠글 이유 없음.

변경 파일/내용

• TestProgram/PCDashBoard/MainWindow.xaml.cs L570 부근:
  • bool makeupActive = _state.ComfortCook && _state.HoodRunning; 신설.
  • subActive = _state.SmartSleep || makeupActive || _state.ReliefRecover; (기존 HoodRunning → makeupActive 교체).
  • 효과: 쾌적조리 미선택 + 후드 ON → makeupActive=false → 다른 시나리오모드/운전모드/풍량 버튼 선택 가능. 쾌적조리 ON + 후드 가동(메이크업 실제 연동중)일 때만 잠금 유지.
  • (쾌적조리 ON + 후드 OFF '대기'도 makeupActive=false → 본래 운전모드 조작 가능, 사양 3.1 일치.)

빌드/배포

• dotnet publish ErvDashboard.csproj -c Release → 오류 0 (NU1701 경고만). publish 단일 exe 갱신.

후속

• 실장비: 쾌적조리 미선택 + 후드 ON 시 스마트수면/안심회복 버튼 클릭되는지, 쾌적조리 ON + 후드 가동 시엔 잠기는지 확인.

---

260618 (8) 시나리오모드 버튼 — 항상 선택 가능하게 (상호 비활성 해제)

요청 (사장님)

• 스마트수면을 선택하면 다른 시나리오 버튼이 비활성화됨 → 그냥 모두 선택(클릭) 가능하게.

펌웨어 제약 (참고)

• 시나리오는 단일 Ext_Run_Mode : 스마트수면=4, 안심회복=1 → 동시 ON 물리적 불가(전환만 가능). 쾌적조리는 별도 Hood_YeunDong_Enable → 독립.

변경 파일/내용

• TestProgram/PCDashBoard/MainWindow.xaml.cs L589~592:
  • SmartSleepBtn.IsEnabled/ReliefRecoverBtn.IsEnabled 의 !subActive || _state.xxx 조건 제거 → 세 버튼 모두 IsEnabled = true (쾌적조리는 이미 true).
  • 클릭 시 동작은 기존 SubMode_Click 상호배타(L401~406) 그대로 → 스마트수면↔안심회복은 서로 전환.
• 운전모드/풍량/프리셋 버튼의 subActive 잠금은 유지(시나리오 동작 중엔 모드/풍량 시나리오가 제어).

빌드/배포

• dotnet publish ErvDashboard.csproj -c Release → 오류 0. publish 갱신.

후속/보류

• 현재 상호배타라 쾌적조리 ON 중 스마트수면/안심회복 선택 시 쾌적조리도 꺼짐(SubMode_Click L401~406). 사양상 쾌적조리는 독립이므로, 쾌적조리는 시나리오 전환과 무관하게 유지하길 원하면 별도 분리 필요(추후 결정).
  • → 260618 (9) 에서 상호배타 로직 전체 삭제로 해소.

---

260618 (9) 시나리오 상호배타 로직 삭제 + 데모 루틴 전체 삭제

요청 (사장님)

• 시나리오 상호배타 로직 삭제(어차피 하나만 선택). 데모 루틴도 모두 삭제.

변경 — 상호배타 삭제

• TestProgram/PCDashBoard/MainWindow.xaml.cs
  • SubMode_Click : 새 모드 켤 때 기존 모드 OFF 전송하던 블록(구 L399~406) 삭제.
  • ApplySubModeLocal : on 시 나머지 해제하던 로직 → 클릭한 태그만 on/off 로 단순화.
• 동작: 시나리오 버튼은 서로 영향 없이 각각 토글. (스마트수면↔안심회복은 펌웨어 단일 Ext_Run_Mode 라 장치단에서 전환되고 STATUS 로 재동기.)

변경 — 데모 루틴 전체 삭제

• MainWindow.xaml.cs : _demoTimer/_demoTick 필드, 생성자 타이머 초기화, DemoTick(), OnClosed _demoTimer.Stop(), 그리고 제어 핸들러 곳곳의 if(_demoTimer.IsEnabled){...} 분기(전원/모드/풍량/시나리오/후드/리셋/댐퍼/LED/예약/프리셋) 전부 제거. CanSend() 의 데모 가드도 제거.
• Api/IErvApi.cs : InjectDemoStatus 선언 삭제.
• Api/SerialErvApi.cs : InjectDemoStatus 구현 삭제.
• ErvProtocol/DemoStatus.cs : 파일 삭제(타 프로젝트 참조 없음 확인).

빌드/배포

• dotnet publish ErvDashboard.csproj -c Release → 오류 0. publish 갱신.

(10) 안심회복 기본 선택 표시 — 해결됨(대시보드 버그 아님)

• 증상: 대시보드 실행 시 안심회복이 선택된 것으로 표시.
• 정적분석: 대시보드는 기본 미선택이 맞음(_state 전부 false, RefreshControls 가 _state 값으로만 강조). 안심회복 강조는 오직 STATUS byte4 bit2(=펌웨어 Ext_Run_Mode==1) 수신 시에만 켜짐.
• 펌웨어 Ext_Run_Mode 기본값 0(My_bunbaegi.c:984), 1로 설정되는 곳은 명령(My_Homenet.c:319, ReliefRecover ON)뿐 → 펌웨어 자가진입 없음.
• 원인 확정: 연결된 ERV가 이전 테스트에서 안심회복 켠 상태로 RAM에 남아있었고(전원 미재투입), 대시보드만 재실행해 그 상태를 그대로 표시한 것.
• 검증 완료: ERV 전원 OFF→ON(콜드부트) 후 대시보드 실행 시 안심회복 버튼 해제됨(사장님 확인 2026-06-18). 코드 수정 불필요.

---

260618 (11) 대시보드 전원 ON 시 룸컨 간헐적 미동작 (타이밍 레이스) 수정

증상

• 대시보드에서 전원 ON 하면 ERV에 연결된 룸컨이 간헐적으로 안 켜짐.

원인 (룸컨 echo ↔ 푸시 레이스)

• 룸컨(RJ2)은 마스터로 폴링, ERV는 응답(slave). 전원/모드/풍량 변경은 ERV가 Command_request_type의 TYPE_MODE|TYPE_FAN_SPEED 플래그를 보고 RX_DATA_MODE_NORMAL 응답에 COMMAND_CONTROLL(Set_Run/Set_Fan)을 실어 푸시.
• CTRL_POWER ON 핸들러(My_Homenet.c)가 Set_Fan_Mode = Fan_Mode = 1 로 Set==현재로 만듦.
• 푸시(NORMAL)보다 룸컨 상태 echo RX_DATA_CONTROLL(My_RJ2.c L698 else)/RX_DATA_MODE_EVENT(L409 else)가 먼저 도착하면:
  • else가 Set_Fan_Mode = Fan_Mode = Rx[3]로 룸컨 현재(OFF=0) 상태를 Set_ 에 덮음*,
  • 이어 L715~716이 Set==현재라 TYPE_FAN_SPEED를 조기 클리어 → 푸시가 영영 안 나감 → 룸컨 미동작.
• 도착 순서(NORMAL vs CONTROLL/EVENT)에 따라 간헐적.

수정 (2파일 3곳)

• Source/HECO2/User/My_Homenet.c CTRL_POWER ON: Set_Fan_Mode = Fan_Mode = 1; → Set_Fan_Mode = 1; (Fan_Mode 즉시 1로 안 올림). Set_Fan(1)!=Fan(0) 유지 → echo가 먼저 와도(아래 가드와 함께) TYPE_FAN_SPEED 가 살아 NORMAL 푸시 보장. 팬은 룸컨 echo가 Fan_Mode=1 로 갱신하면 켜짐. 마커 [전원ON룸컨레이스].
• Source/HECO2/User/My_RJ2.c 룸컨 echo else 2곳을 가드 :
  • L409 RX_DATA_MODE_EVENT else → else if(!(Command_request_type & (TYPE_MODE|TYPE_FAN_SPEED)))
  • L698 RX_DATA_CONTROLL else → 동일 가드
  • 효과: 대시보드 명령(전원/모드/풍량)이 푸시 대기중이면 룸컨 자기보고로 Set_* 를 덮지 않음 → 명령 유실/조기 클리어 방지. ack(SEND_FLAG) 경로는 if-branch라 가드 영향 없음. 평상시(명령 없음) 룸컨 패널 조작 반영은 그대로(가드 통과).

빌드 결과

• bash build.sh all → 성공, 경고/오류 0. text 43952 → 43972.

후속 / 참고

• 실장비: 대시보드 전원 ON 반복 시 룸컨이 매번 켜지는지 확인.
• 동일 패턴 잠재: CTRL_RUNMODE(L287/292)·CTRL_FAN(L308)도 Set==현재로 equalize → 같은 716 조기클리어 레이스 소지. else 가드(L409/698)로 클로버는 막히나, 모드/풍량 변경 시에도 룸컨 푸시 누락이 보이면 동일하게 de-equalize 적용 검토. (이번엔 보고된 전원 ON 만 수정.)
  • → 260618 (12) 에서 룸컨 전용 pending(RoomCtrl_Push)으로 전원 ON/OFF 모두 견고화. (11)의 de-equalize 는 원복(불필요).

---

260618 (12) 전원 OFF 시 룸컨이 옛 모드(공청) 계속 표시 + (11) 통합 — 룸컨 전용 푸시 플래그

증상

• 공청에서 대시보드 전원 OFF → ERV(모터)는 정지하는데 룸컨은 계속 "공청" 표시. (전원 ON 간헐 미동작과 같은 계열)

근본 원인 (공유 플래그 레이스)

• Command_request_type 을 룸컨(RJ2)·각실분배기(bunbagi) 두 소비자가 공유.
  • My_bunbaegi.c:522 가 프레임 송신 후 Command_request_type = 0; 로 전체를 wipe → 분배기가 먼저 처리하면 RJ2가 플래그를 못 봐 룸컨 푸시 유실.
  • 전원 OFF는 모터 정지를 위해 Set_Run=Run=VENT, Set_Fan=Fan=0 equalize 강제(주석 250~253) → My_RJ2.c:715~716(Set==현재 → TYPE_MODE/FAN 클리어)가 NORMAL 푸시 전에 플래그 제거 → 룸컨 푸시 유실.
  • 둘 다 도착순서 의존 → 간헐/상황적.
• (부수발견) TYPE_POWER(0x40) == TYPE_HOOD_STATE(0x40) 비트 충돌(My_define.h). 전원명령↔후드상태가 서로 오인될 잠재 버그. 이번 수정은 별도 변수를 써서 이 충돌을 우회(미해결로 남김 — 후속 정리 권장).

수정 — 룸컨 전용 pending 플래그 RoomCtrl_Push

• My_define.h : extern uint8_t RoomCtrl_Push; 추가.
• My_RJ2.c :
  • 전역 uint8_t RoomCtrl_Push = 0; 정의.
  • NORMAL 푸시 조건(L332)에 || RoomCtrl_Push 추가 → 분배기 wipe·716 클리어와 무관하게 룸컨에 푸시.
  • echo else 가드(L409/698) : !RoomCtrl_Push && !(...) → pending 중 룸컨 자기보고로 Set_* 안 덮음.
  • ack(SEND_FLAG) 경로(EVENT L399 / CONTROLL L691) : RoomCtrl_Push = 0; → 룸컨이 명령 수신·확인하면 해제.
• My_Homenet.c CTRL_POWER : Command_request_type |= (TYPE_POWER|TYPE_MODE|TYPE_FAN_SPEED); 직후 RoomCtrl_Push = 1;. (11)의 ON de-equalize 는 원복(Set_Fan_Mode = Fan_Mode = 1;) — RoomCtrl_Push 가 푸시를 보장하므로 불필요, 모터는 즉시 ON.

효과

• 전원 ON/OFF 시 분배기·716 타이밍과 무관하게 룸컨에 Set_Run/Set_Fan(전원 OFF=VENT/0) 이 반드시 푸시 → 룸컨이 즉시 OFF(또는 ON) 동기. ack 시 pending 해제로 평상시 룸컨 패널 조작 반영은 그대로.

빌드 결과

• bash build.sh all → 성공, 경고/오류 0. text 43972 → 44024.

후속 / 주의

• 실장비 검증 필수 : 핵심 통신 상태머신(RJ2) 변경. 전원 ON/OFF 반복 시 룸컨이 매번 동기되는지, 룸컨 패널 직접 조작·후드연동·분배기 동작에 회귀 없는지 확인.
• TYPE_POWER/TYPE_HOOD_STATE 0x40 비트 충돌은 미해결(빈 비트 0x08 로 분리 권장). 이번 수정과 독립.
• 모드/풍량 변경(CTRL_RUNMODE/CTRL_FAN)도 룸컨 동기 누락이 보이면 동일하게 RoomCtrl_Push = 1; 적용 가능.
• 검증 완료: 전원 ON/OFF 시 룸컨 동기 정상(사장님 확인 2026-06-18).

---

260618 (13) 전원 OFF 시 풍량 버튼(0 포함) 비활성화

요청

• 전원 OFF 하면 풍량 0 버튼도 비활성화.

변경

• TestProgram/PCDashBoard/MainWindow.xaml.cs 풍량 버튼 활성 조건:
  • fb.IsEnabled = !subActive && !_state.IsAuto && sp <= fanMax;
  • → fb.IsEnabled = _state.PowerOn && !subActive && !_state.IsAuto && sp <= fanMax;
  • 전원 OFF면 0~4 전 단 비활성(풍량 조절 불가). 운전모드 버튼은 그대로(전원 OFF에서 모드 누르면 전원 ON).

빌드/배포

• dotnet publish ErvDashboard.csproj -c Release → 오류 0. (BAML stale 캐시로 1회 실패 → obj/bin clean 후 성공.) publish 갱신.

---

260618 (14) 그래프 로그 DB(HERV_Log.db)가 publish 폴더에 안 생기던 문제

증상

• 그래프 시계열 DB HERV_Log.db 가 publish 폴더에 안 보임. 재실행 간 그래프 이력도 이어지지 않음.

원인

• DB 경로가 AppContext.BaseDirectory 기준이었음(MainWindow.xaml.cs).
• csproj 가 PublishSingleFile=true + IncludeAllContentForSelfExtract=true → 단일 exe 실행 시 매번 %TEMP%\.net\ErvDashboard\<랜덤해시>\ 로 추출해 실행 → AppContext.BaseDirectory 가 그 임시폴더를 가리킴.
• 결과: DB 가 임시폴더에 생기고(publish 폴더엔 없음), 실행마다 추출 해시가 달라 DB 가 매번 새로 생겨 데이터가 흩어짐(이력 유실). (디스크 검색으로 %TEMP%\.net\ErvDashboard\*\HERV_Log.db 다수 확인.)

변경

• TestProgram/PCDashBoard/MainWindow.xaml.cs : DB 경로를 실제 exe 위치 기준으로.
  • AppContext.BaseDirectory → Path.GetDirectoryName(Environment.ProcessPath) ?? AppContext.BaseDirectory
  • 이제 HERV_Log.db 가 exe 와 같은 publish 폴더에 고정 생성 → 재실행해도 같은 파일에 누적.

빌드/배포

• dotnet publish → 오류 0 (clean 후). publish 갱신.

참고

• 임시폴더에 흩어진 옛 DB 는 고아. 보존하려면 최신 것을 publish 폴더 HERV_Log.db 로 복사하면 이력 이어짐.
• 그래프 '불러오기'→'엑셀저장' 은 _selectedDate 로 DB 재조회(LoadByDate)하므로 과거 날짜 데이터가 정상 저장됨(코드 확인, 수정 불필요). 단 위 DB 경로 수정 이후 기록분부터 누적.