Getting Started
Brings a stopped gateway back up. It leaves the data(/data1), configuration(/etc/kopens), and images
untouched and only starts the containers.
sudo /opt/kopens/plantpulse-edge-docker/bin/start.sh
What it does is one line — systemctl start plantpulse-edge.service. If it is already running,
it does nothing and lets you know.
sudo systemctl start plantpulse-edge.service
sudo systemctl status plantpulse-edge.service
The reason to use the script is to handle the surrounding steps, like verifying TLS certificates.
What Starts in Order Inside the Container
The container's entrypoint starts the modules in order. The next module only starts once the previous one is ready.
The engine is Valkey (version 8.1.10 is built from source in the image), but the log file is
cache/log/redis.log, the data is in /data1/pp-data/redis, and the way to view the logs is logs.sh redis.
If you search with valkey, you'll find nothing, so search with redis.
| Order | Module | Port | Check |
|---|---|---|---|
| 1 | Cache (Valkey) | 6379 | nc -z 127.0.0.1 6379 |
| 2 | MQTT (HiveMQ) | 1883 | nc -z 127.0.0.1 1883 |
| 3 | Database (Cassandra) | 9042 | nc -z 127.0.0.1 9042 |
| 4 | Time Series Engine | 7800 | nc -z 127.0.0.1 7800 |
| 5 | Time Series Dashboard | 3000 | nc -z 127.0.0.1 3000 |
| 6 | Server (Web UI · API) | 80 · 443 | curl -ks https://127.0.0.1/api/v1/system/ready |
| 7 | Flow Tool | 1880 | nc -z 127.0.0.1 1880 |
Each module has a timeout (default 300 seconds). If one doesn't finish within that time,
it logs TIMEOUT and moves on to the next module. This is to structurally prevent one module
from waiting forever and blocking the entire startup — so there can be a state where "it's
up, but some parts are missing." In that case, check status.sh and the logs to see which module it is.
Verification
cd /opt/kopens/plantpulse-edge-docker/bin
./status.sh # 컨테이너 · 헬스 · 볼륨 요약
./health.sh # 애플리케이션 준비 상태
./logs.sh # 부팅 로그 (모듈별 [n] 표시로 나뉜다)