Implement dynamic energy data collections per building

- Store energy data in separate MongoDB collections for each
SLGs/Community/Building directory - Update FTP monitor and database
manager to track directory paths and select appropriate collections -
Add collection stats to database statistics API - Update sensor and
token services for improved API consistency - Add 'rb' (rebuild and
restart) option to deploy.sh script

microservices/tasks

@@ -0,0 +1,47 @@
+api-gateway
+- Critical: Extend `SERVICES` and `service_requests` to include every routed microservice so proxy endpoints stop returning 404/KeyError for battery/demand-response/p2p/forecasting/iot routes (api-gateway/main.py:70-169).
+- High: Guard `request_stats` updates against unknown services or look up configs dynamically before incrementing counters to avoid crashes (api-gateway/main.py:88-169).
+- Possible Feature: Add per-service rate limiting and fallback routing with circuit breakers to keep the gateway responsive during downstream outages.
+- Data to Store: Persist rolling latency/throughput metrics per backend plus authentication decision logs for audit and tuning.
+
+battery-service
+- High: Handle zero or missing max charge/discharge power before dividing when optimising SOC to prevent ZeroDivisionError (battery-service/battery_service.py:205-213).
+- Medium: Use the stored `capacity_kwh`/`stored_energy_kwh` fields when computing fleet totals so analytics reflect real values (battery-service/main.py:95-96).
+- Possible Feature: Expose predictive maintenance recommendations based on usage profiles and integrate battery grouping/aggregation endpoints.
+- Data to Store: Track per-cycle metadata (depth of discharge, temperatures) and maintenance events to support lifecycle analytics.
+
+data-ingestion-service
+- High: Wrap the initial `wait_for(check_for_new_files)` call in error handling so startup connection/timeout issues don't kill the monitoring task (data-ingestion-service/src/ftp_monitor.py:62-100).
+- Possible Feature: Provide a dashboard/REST endpoint for real-time ingestion status with manual retry controls and support for additional protocols (SFTP/HTTPS).
+- Data to Store: Record per-file ingestion outcomes, error traces, and FTP scan history to analyse gaps and retry logic effectiveness.
+
+demand-response-service
+- Critical: Restore the missing `models`, `database`, and `demand_response_service` modules referenced during import so the app can boot (demand-response-service/main.py:15-20).
+- Possible Feature: Implement participant opt-in/opt-out scheduling, incentive tracking, and automated curtailment verification reports.
+- Data to Store: Persist device participation history, response accuracy, and incentive payouts to evaluate program efficiency.
+
+forecasting-service
+- Critical: Recreate the forecasting microservice implementation; the directory is empty so nothing can start (forecasting-service/).
+- Possible Feature: Offer multiple forecast horizons with confidence intervals and expose model version management APIs.
+- Data to Store: Keep training dataset metadata, forecast error metrics, and model artefacts to support retraining and auditing.
+
+iot-control-service
+- Critical: Recreate the IoT control microservice implementation; the directory is empty so nothing can start (iot-control-service/).
+- Possible Feature: Add device scheduling/policy engines with rules-based automation and rollback support for failed commands.
+- Data to Store: Log all device capabilities, issued commands, acknowledgements, and firmware status to manage the fleet safely.
+
+p2p-trading-service
+- Critical: Recreate the P2P trading microservice implementation; the directory is empty so nothing can start (p2p-trading-service/).
+- Possible Feature: Build order-book style trading with price discovery, bidding windows, and settlement workflows.
+- Data to Store: Capture trade offers, matched transactions, settlement receipts, and participant credit balances for compliance.
+
+sensor-service
+- High: Fix the aggregation pipeline so sensor types are grouped correctly and room metrics use real readings instead of the constant "energy" fallback (sensor-service/room_service.py:408-420).
+- Medium: Filter system events using comparable types (e.g., `created_at` or int timestamps) so queries return results (sensor-service/sensor_service.py:218-227).
+- Possible Feature: Add anomaly detection on sensor streams and configurable alerting thresholds surfaced via dashboards/WebSockets.
+- Data to Store: Maintain sensor calibration history, room occupancy patterns, and WebSocket subscription metrics for optimisation.
+
+token-service
+- Medium: Stop forcibly overriding client-provided expiry/embargo values so custom lifetimes survive token generation (token-service/main.py:99-108).
+- Possible Feature: Support role/permission templates with bulk token provisioning and self-service revocation flows.
+- Data to Store: Persist token usage logs (IP, endpoint, timestamp) and refresh token metadata to improve security monitoring.