Common LoT mistakes
These are the most frequent mistakes in LoT development. Avoid them whether you’re writing new code or reviewing existing output.| Anti-Pattern | Why It’s Bad | Do This Instead |
|---|---|---|
| Omitting type casts in math | Implicit type handling leads to silent errors | Always cast: PAYLOAD AS DOUBLE, GET TOPIC ... AS DOUBLE — see Operations |
| Triggering models on timestamps | Timestamps update every tick — model fires constantly | Trigger on the primary data field: AS TRIGGER on value, not timestamp — see Schema definition |
| Inconsistent naming across models | sensorID in one model, sensor_id in another | Standardize on snake_case for all field names — see Naming conventions |
| Using Python for native LoT tasks | Python adds overhead for simple publish/get/if operations | Use Python only for math libraries, ML, API calls, or complex parsing |
Leaving $SYS/# topics unrestricted | System topics contain broker commands and sensitive data | Create a priority-10 Rule restricting PublishSys and SubscribeSys — see Rules syntax |
| Generic entity names | Action1, Rule1, MyRoute are meaningless in a system with 50 entities | Name by purpose: MonitorPressure, ProtectSysTopics, SensorDatabase |
PUBLISH for internal state | Broadcasts data that only your own Actions need | Use KEEP TOPIC for internal state; PUBLISH for external subscribers — see Writing reusable logic |
| Monolithic Actions | One Action doing 15 things is hard to test and debug | Split into callable Actions with INPUT/OUTPUT — see One Action, One Job |
Next Steps
Naming conventions
Entity, variable, and topic naming standards.
Writing reusable logic
Callables, wildcards, and KEEP vs PUBLISH patterns.