…lOpenEms

…IntelliJ

…lOpenEms

…fficialOpenEms

…fficialOpenEms

…fficialOpenEms

…fficialOpenEms

…fficialOpenEms

…fficialOpenEms

…fficialOpenEms

…fficialOpenEms

-This Implementation allows the use of MQTT v. 3.1.1
- Configure a Broker with URL xor a Combination of IP, Port, Basepath, ConnectionType
- Add an optional Last Will
- Use TelemetryComponent to configure on the fly your openems components with differenty payloads and topics to publish and subscribe values depending on a key:Value pair
- Publish: set up a Key:value concatination to publish channel values mapped to a key
- Subscribe: Subscribe a Key within a topic and write the Value to the mapped Channel
- Within every configuration it is possible to set multiple payloads and topics where each topic gets 1 payload
- map the same payload to different topics
- each configuration entry of publish/subscribe -> set up priority, QoS, RetainFlag, Payload, TimeInterval for push / refresh subscription
- add an optional timestamp to the payload of each publish / subscribe config entry

…QTT_v_3

When the "OtherComponent" is configured, telemetry/Command component will sort the Channels of the other component by ne id and display them in the Configuration

At the beginning of developing the MqttBridge I wanted to do something with the different connections
But since this feature is not needed within the Publish/Subscribe Manager, different Connections can be removed -> only 2 instead of 6 Connections are now needed by the MqttManager.
Since there will be only 2 connections now instead of 6 -> Executor Max Time could be reduced

We noticed, that some OpenEMS Components add some of their channel later on, after instatiation (SMA PV Invert for example)
That's why we added a method to check for that