I've cleaned up and moved the core code of controller v2 into v3:
Deployment of controller.xml and rules is working in tests:
My main goal was to get the "Climate Control" demo setup working (still looking for a better name). Currently the rules compile and we are ready for writing tests:
Rule definitions are 99% compatible with v2, it's mostly package renaming and introducing more Java utilities for writing rules.
Other major tasks moving forward, also see the TODOs in code:
1. Every PullCommand (previously ReadCommand/StatusCommand) needs a new thread, any PushCommand (previously EventListener) might also start its own thread. The Climate Control demo starts more than 100 threads. The current event processing chain is the same as a Camel route, the event processing context is the same as a Camel exchange. Replacing these bits with Camel will also resolve the issues with Pull/PushCommand scaling.
2. More commands and especially Velbus need to be ported to v3. I've done VirtualCommand and DateTimeCommand. The API is still 99% compatible with v2, only how commands are build has changed. The VirtualCommand is a bit of a mystery for me, especially how its arguments/parameters are used/not used, some cleanup and better docs should be done. On the southbound side we also need a simulator, probably implemented as a command?
3. There is no proper data type handling for sensor values. We have from/to string conversions all over the place. Value range checks for min/max constraints are inconsistent. We have rules logic based on whether a value is "OFF" or "off". Not sure how this can be fixed without breaking backwards compatibility, maybe we want to rethink the Sensor model. Then we could also resolve the ambiguities in unique device/sensor/command IDs and names.
4. The StatusCache is now the DataContext, where the current state of sensors is stored. I've dropped the old change polling mechanism. We need a (messaging) solution for sharing state updates with in-process and external services. This also has to handle ExecutableCommands and later device discovery. I'm working on this task and how the in-process and remote API of the controller will look like northbound.
My proposal would be to get more tests working first. Especially Climate Control should be extensively tested from a business logic perspective. This gives us stability when we introduce Camel, improve models and data type handling, etc.