jblance
Input asynchronous commands from mqtt to the inverter
This PR add the ability to receive asynchronous commands from mqtt borker and forward them to the inverter.
For now only configuration file in daemon mode is supported.
All section with option direction set to the value in will be considered inputs and not will not be sent in the periodically. But if a mqtt topic "{TAG}/command" is received and the payload of this topic is one of input commands the commands is immediately sent to the inverter.
TODO: A method to acknowledge the command has been executed.
Follow is an example to send a asynchronous command (POP02) to inverter with tag "Inverter"
mosquitto_pub -h 127.0.0.1 -t "Inverter/command" -u <MQTTUSER> -P <MQTTPASSWORD> -m POP02
[SETUP]
pause=5
mqtt_broker=192.168.75.105
mqtt_user=<MQTTUSER>
mqtt_pass=<MQTTPASSWORD>
[Inverter_1]
protocol=PI30
port=/dev/hidraw0
baud=2400
command=QPIGS
tag=Inverter
outputs=mqtt
[Inverter_2]
protocol=PI30
port=/dev/hidraw0
baud=2400
command=QPIRI
tag=InverterConf
outputs=mqtt
[set_mode_solar]
protocol=PI30
port=/dev/hidraw0
baud=2400
command=POP01
tag=Inverter
outputs=mqtt
direction=in
[set_mode_sbu]
protocol=PI30
port=/dev/hidraw0
baud=2400
command=POP02
tag=Inverter
outputs=mqtt
direction=in
[get_configuration]
protocol=PI30
port=/dev/hidraw0
baud=2400
command=QPIRI
tag=Inverter
outputs=mqtt
direction=in
why configure each command? i was thinking more of an async/adhoc command approach, with a config similar to:
[async_command]
topic=Inverter1/command
result_topic=Inverter1/results
allowed_commands=['POP02', 'POP00']
protocol=PI30
port=/dev/hidraw0
baud=2400
tag=Inverter
outputs=mqtt
this simplifies config while allowing adhoc commands any thoughts?
Yes I forgot to mention that the command key is working like other commands in mpp-solar and can be provided multiple input commands on a single line separating it with the # character.
So the following configuration can work as well:
[set_mode_sol_or_sbu]
protocol=PI30
port=/dev/hidraw0
baud=2400
command=POP01#POP02
tag=Inverter
outputs=mqtt
direction=in
To better understand your thoughts about the following line:
[async_command]
are you proposing to remove the direction option and to consider as input commands the ones in configuration sections that starts with "async_"?
I think add this to options is a good idea. I will try to work on it.
topic=Inverter1/command
result_topic=Inverter1/results
To better understand your thoughts about the following line:
[async_command]are you proposing to remove the direction option and to consider as input commands the ones in configuration sections that starts with "async_"?
I think add this to options is a good idea. I will try to work on it.
topic=Inverter1/command result_topic=Inverter1/results
Its to have only one config section (per inverter) that defines a topic to 'listen' to, and then runs any commands found (and optionally sends the results to the result_topic) - also optionally restricting the commands allowed so instead of defining each 'in' command effectivetly an 'in' topic is setup
in powermon (which is the evolution of mppsolar), I define adhoc commands topic as an optional part of the mqtt broker
mqttbroker:
name: localhost
port: 1883
username: null
password: null
adhoc_topic: powermon/adhoc_commands
adhoc_result_topic: powermon/adhoc_commands/results
The callback for the adhoc commands topic, parses and adds any commands to a list, that is then processed as part of the main run loop
I would add a filter of either inclusion or exclusion of allowed commands just for a layer of security and prevent any accident potential. Some of the available commands someone might desire some scrutiny at the final layer (mpp-solar).
I tried the three concepts proposed by Cordelster, Powermon, and Persuader72. The only one that works really well with my Voltronic is Persuader72’s. With it, I can switch between POP01 and POP02 and adjust the charging current. The other two don’t seem to work. I know Powermon is still a work in progress, but it behaves a bit strangely in my setup.
@NextWork123 Mine is currently in flux. as I'm trying a few different approaches, learning a few lessons about mqtt, as I have never developed anything with it before, though there is a working version in one of my earlier commits. I should have my final approach up within the week now that I have a better grasp on mqtt and I want to make sure it has good support functions to provide a solid forward path complete with error and connection recovery, timeouts, and the ability for persistence on the command and response topics. I'm hoping the latter addition will actually allow command/response persistence outside of running a daemon is the goal and it appears mqtt has the ability to accomplish this.
@NextWork123 Mine is currently in flux. as I'm trying a few different approaches, learning a few lessons about mqtt, as I have never developed anything with it before, though there is a working version in one of my earlier commits. I should have my final approach up within the week now that I have a better grasp on mqtt and I want to make sure it has good support functions to provide a solid forward path complete with error and connection recovery, timeouts, and the ability for persistence on the command and response topics. I'm hoping the latter addition will actually allow command/response persistence outside of running a daemon is the goal and it appears mqtt has the ability to accomplish this.
Thanks! By the way, I’m not sure if you’ve noticed something strange — I reported it in my issue, but I’m not sure if it’s a general behavior of mpp-solar. The "AC Output Power Apparent" entity in Home Assistant sometimes shows odd values. For example, it might correctly show 300W, then suddenly jump to 3000W, and then update again with the correct data. If you could take a look at that as well, it would be great.
anyway great work for all contributor :)! keep up all the work guys
Thanks! By the way, I’m not sure if you’ve noticed something strange — I reported it in my issue, but I’m not sure if it’s a general behavior of mpp-solar. The "AC Output Power Apparent" entity in Home Assistant sometimes shows odd values. For example, it might correctly show 300W, then suddenly jump to 3000W, and then update again with the correct data. If you could take a look at that as well, it would be great.
anyway great work for all contributor :)! keep up all the work guys
I think that is related possibly to this discussion #534 where values in PI30 QPIRI I assume you using are causing this in conjunction mqtt and homeassistant it becomes very previlent. I made a spreadsheet and started listing some suggested naming as it could be a breaking change for those that leverage QPIRI as I do. So I want to make sure it's thought out well. Most likely create a subclass that maintains the current field names, so others have plenty of time to adjust before phasing it out is my thought.
Thanks! By the way, I’m not sure if you’ve noticed something strange — I reported it in my issue, but I’m not sure if it’s a general behavior of mpp-solar. The "AC Output Power Apparent" entity in Home Assistant sometimes shows odd values. For example, it might correctly show 300W, then suddenly jump to 3000W, and then update again with the correct data. If you could take a look at that as well, it would be great. anyway great work for all contributor :)! keep up all the work guys
I think that is related possibly to this discussion #534 where values in PI30 QPIRI I assume you using are causing this in conjunction mqtt and homeassistant it becomes very previlent. I made a spreadsheet and started listing some suggested naming as it could be a breaking change for those that leverage QPIRI as I do. So I want to make sure it's thought out well. Most likely create a subclass that maintains the current field names, so others have plenty of time to adjust before phasing it out is my thought.
oh ok nice! love that i hope all gonna be fantastic :) thanks for your time anyway
@jblance @NextWork123 I'm testing what I can right now. Make sure you read and understand the mqtt _configuration in the docs folder, as I have given this allot of functionality and I may need to elaborate on it. This isn't exactly PR ready, some files can be removed now I believe, though commands are working, and work with persistence if set by the sending host to retain, and responses are set to retain and qos=1
https://github.com/cordelster/mpp-solar/tree/mqtt-cmdr2
@jblance @NextWork123 I'm testing what I can right now. Make sure you read and understand the mqtt _configuration in the docs folder, as I have given this allot of functionality and I may need to elaborate on it. This isn't exactly PR ready, some files can be removed now I believe, though commands are working, and work with persistence if set by the sending host to retain, and responses are set to retain and qos=1
https://github.com/cordelster/mpp-solar/tree/mqtt-cmdr2
i tried that and is perfect! i merged all on my fork because i'm not pro on mqtt side what is used retain?
@jblance @NextWork123 I'm testing what I can right now. Make sure you read and understand the mqtt _configuration in the docs folder, as I have given this allot of functionality and I may need to elaborate on it. This isn't exactly PR ready, some files can be removed now I believe, though commands are working, and work with persistence if set by the sending host to retain, and responses are set to retain and qos=1 https://github.com/cordelster/mpp-solar/tree/mqtt-cmdr2
i tried that and is perfect! i merged all on my fork because i'm not pro on mqtt side what is used retain?
Starts with QOS, here is the resource I used to learn more about mqtt at the bottom it links into retain. https://www.emqx.com/en/blog/introduction-to-mqtt-qos
@jblance @NextWork123 I'm testing what I can right now. Make sure you read and understand the mqtt _configuration in the docs folder, as I have given this allot of functionality and I may need to elaborate on it. This isn't exactly PR ready, some files can be removed now I believe, though commands are working, and work with persistence if set by the sending host to retain, and responses are set to retain and qos=1 https://github.com/cordelster/mpp-solar/tree/mqtt-cmdr2
i tried that and is perfect! i merged all on my fork because i'm not pro on mqtt side what is used retain?
Starts with QOS, here is the resource I used to learn more about mqtt at the bottom it links into retain. https://www.emqx.com/en/blog/introduction-to-mqtt-qos
not bad at all anyway checkout for mqtt broker flashmq is much better than emqx nanomq or other anyway if you have discord we can do something together because i gonna touch a bit too the code for improve things