- Changed FIREBASE_PATHS.kontrol from 'kontrol' to 'kontrol_1'
- Worker now reads/writes from correct path (app uses /kontrol_1)
- Fixes issue where kontrol config was always NULL
- Schedule triggers should now work correctly
- Added migration helper script (migrate-history-source.js)
This aligns worker with current app structure after schema update.
- Add retry logic (3x attempts) to updateFirebaseSmart() for better stability
- Add Firebase verification to confirm mosvet updates actually wrote to database
- Add exponential backoff (1s, 2s, 3s) between retry attempts
- Improve error logging with full error stack traces
- Add critical alerts when safety OFF fails (potential stuck mosvet)
- Better validation of kontrol config with NULL checks
- Enhanced diagnostics for all updateFirebaseSmart calls
- Ensure pump stops are retried if initial attempt fails
This fixes issues where mosvet would not trigger despite logs showing 'success'
- Worker was reading from /kontrol_1 but data stored at /kontrol
- This caused worker to not find any scheduled watering jadwal
- Fixed to match Flutter app which uses /kontrol path
- Result: Scheduled watering notifications will now trigger correctly
Features implemented:
- Dashboard with real-time sensor monitoring (temp, humidity, light, soil moisture)
- Water flow status indicator with color coding
- Time-based scheduling (Kontrol Waktu/Jadwal)
- Sensor-based threshold control (Kontrol Sensor/Threshold)
- Smart mode with auto-stop when target reached
- Three pump controls: Air, Larutan Nutrisi, Pengaduk
- Manual control for all actuators
- History/logging system
- Firebase Realtime Database integration
- Railway worker backend service
UI/UX improvements:
- Material Design 3 components
- Badge indicators for active pumps
- Conditional rendering (show only when active)
- Responsive layouts with Wrap widgets
- Color-coded status indicators
Backend fixes:
- Fixed water_flow reading from Firebase
- Fixed threshold model copyWith method
- Added pompa_pengaduk support across all models
- Smart mode with per-pot independent monitoring
- Cooldown per-threshold (not per-pot)
- Valves stop together when targets reached
Renamed: All 'Pupuk' references to 'Larutan Nutrisi Cair'
Problem:
- Firebase SDK listener not triggering (SDK timeout)
- No sensor data being checked despite sensor=true
- Log shows no SENSOR CHECK output
Solution:
- Add polling every 30 seconds using REST API (reliable)
- Keep Firebase listener as backup if SDK recovers
- Check kontrolConfig.sensor flag before processing
- Shared checkSensorThresholds() function for both methods
This ensures sensor mode works even when Firebase SDK fails
- Log every sensor check with full sensor data
- Display threshold config for each check
- Show detailed evaluation for each pot
- Log cooldown status and trigger events
- Help debug why mosfet not triggering
- Detect all threshold_* nodes from kontrol_1
- Support unlimited threshold configurations
- Each threshold: batas_bawah, batas_atas, smart_mode, pot_aktif[], pompa settings
- Smart mode: water until batas_atas reached
- Fixed mode: water for fixed duration
- Setup script: setup-firebase-threshold.js for auto Firebase initialization
- Improved logging: show threshold ID, mode, and pot info on trigger
- NEW: Flexible threshold system (threshold_1, threshold_2, ... unlimited)
- Each threshold: batas_bawah, batas_atas, durasi, smart_mode, pot_aktif[]
- Smart mode: siram sampai batas_atas tercapai
- Fixed mode: siram sesuai durasi tetap
- ThresholdModel: Complete model with validation
- ThresholdService: CRUD operations for threshold management
- ThresholdManagementPage: UI untuk list dan manage threshold
- ThresholdFormPage: Add/edit form dengan slider dan pot selection
- Worker.js: Dynamic threshold_* detection and processing
- Navigation: Sensor button now goes to ThresholdManagementPage
- Firebase: Auto-setup script with example threshold data (threshold_1, threshold_2, threshold_3)
- Path: All threshold data stored in /kontrol_1
- Real-time scheduling system working with 20s delay per section
- 1 schedule time controls multiple pumps simultaneously
- Railway Worker with Firebase SDK + REST API fallback
- Timeout handling and job queue management
- Comprehensive documentation and troubleshooting guides
- Flutter mobile app with dual mode (manual + auto scheduling)
Fixed Railway deployment error:
'invalid character ï looking for beginning of value'
Cause: UTF-8 BOM (Byte Order Mark) at file start
Solution: Recreated file with UTF-8 without BOM
Railway JSON parser now reads correctly
Added production-ready Dockerfile:
- Node.js 18 Alpine (lightweight)
- Multi-stage dependency installation
- Health check monitoring
- Non-root user for security
- Production optimizations
Added .dockerignore:
- Exclude node_modules (reinstalled in Docker)
- Exclude .env files (Railway injects env vars)
- Reduce image size
- Faster build times
Railway will now detect project type via Dockerfile instead of guessing from package.json.
This ensures proper build configuration for BullMQ worker.
Wizznu
hitproject996-dev
qiizwww