Replies: 8 comments 3 replies
-
|
I am having the same error with MQTT connecting to HomeAssistant Mosquitto broker. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @moussa11 & @jmcewen58, |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ai-republic Thanks for follow-up. I spent a fair amount of time trying to get bms-to-inverter MQTT client to connect to Mosquitto with no luck. I believe I have narrowed it down to: the default protocol used by the client is Artemis-core while mosquitto accepts either mqtt or websocket. I didn't manage to force the client to use mqtt protocol. As an example, tcp://localhost:1883?protocols=MQTT in the locator field. The other issue (or designed to operate as such) the mqtt server built into bms-to-inverter requires also the apps client to produce the data. Nevertheless, HomeAssistant mqtt client would only accept one mqtt server, in this case it's only selected to use mosquitto, and it's doesn't permit an additional server. The temperature issue is separate. It's available on the webserver, but it's not be passed through CAN to the register Deye inverter. |
Beta Was this translation helpful? Give feedback.
-
|
No connection.
I don't have a copy of the logs, but the exception was something like
"could not connect, invalid protocol".
I did some investigation, and found that while the Apache Artemis broker
supports MQTT protocols, the client does not - it only supports OpenWire.
Hence the difference in the port numbers. Seems that Eclipse Paho is the
most common MQTT client implementation from what I could find.
I created a fork of your project and have a working implementation with the
Eclipse Paho client at https://github.com/jmcewen58/bms-to-inverter (dev
branch). I also found an issue in the main class, receivedData method
where after checking that mqttExternalProducer isn't null, the code
actually tried to use mqttProducer instead. After correcting, my
HomeAssistant is receiving data. I have some other things I want to do
with this, and had planned to reach out to you when that's done to see what
if anything you wanted to do with this, but I've gotten busy.
TODO:
- Provide ability to supply both clients: I'm thinking that my wrapper
could examine the port and supply the appropriate client (e.g if the port
is below 20000 use Paho, otherwise Artemis. This would work in the
majority of cases but would fail occasionally if somebody was using a
wildly non-standard port. Alternatives would be to include a Home
Assistant checkbox in the configurator, and provide an extra parameter on
the connect method to choose the client based on that which. That approach
could use either the wrapper class or put an iterator in the main code to
find the desired implementation.
- Provide a mechanism to check if the data has changed and only send if it
changed plus maybe once a minute as a heartbeat.
- Clean up the code
- Document usage: Suggested topic, Example HomeAssistant configuration to
consume the data.
…On Tue, Jan 28, 2025 at 10:41 PM Torsten Oltmanns ***@***.***> wrote:
Hi @moussa11 <https://github.com/moussa11> & @jmcewen58
<https://github.com/jmcewen58>,
sorry just came across your message now as it was not listed under issues.
So you get some data from the application via your Mosquitto MQTT broker in
HA already? Just lacking temperatures? Or no connection to the Mosquitto
MQTT in general?
—
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BOIMPNKO3LU7WBDEE4QSJFD2NBZ3JAVCNFSM6AAAAABVBBOHHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJZGIYDKMI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
@jmcewen58 |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I've completed all but the documentation and pushed to my dev branch.
On Wed, Jan 29, 2025 at 9:05 AM Jeff McEwen ***@***.***>
wrote:
… No connection.
I don't have a copy of the logs, but the exception was something like
"could not connect, invalid protocol".
I did some investigation, and found that while the Apache Artemis broker
supports MQTT protocols, the client does not - it only supports OpenWire.
Hence the difference in the port numbers. Seems that Eclipse Paho is the
most common MQTT client implementation from what I could find.
I created a fork of your project and have a working implementation with
the Eclipse Paho client at https://github.com/jmcewen58/bms-to-inverter
(dev branch). I also found an issue in the main class, receivedData method
where after checking that mqttExternalProducer isn't null, the code
actually tried to use mqttProducer instead. After correcting, my
HomeAssistant is receiving data. I have some other things I want to do
with this, and had planned to reach out to you when that's done to see what
if anything you wanted to do with this, but I've gotten busy.
TODO:
- Provide ability to supply both clients: I'm thinking that my wrapper
could examine the port and supply the appropriate client (e.g if the port
is below 20000 use Paho, otherwise Artemis. This would work in the
majority of cases but would fail occasionally if somebody was using a
wildly non-standard port. Alternatives would be to include a Home
Assistant checkbox in the configurator, and provide an extra parameter on
the connect method to choose the client based on that which. That approach
could use either the wrapper class or put an iterator in the main code to
find the desired implementation.
- Provide a mechanism to check if the data has changed and only send if it
changed plus maybe once a minute as a heartbeat.
- Clean up the code
- Document usage: Suggested topic, Example HomeAssistant configuration to
consume the data.
On Tue, Jan 28, 2025 at 10:41 PM Torsten Oltmanns <
***@***.***> wrote:
> Hi @moussa11 <https://github.com/moussa11> & @jmcewen58
> <https://github.com/jmcewen58>,
> sorry just came across your message now as it was not listed under
> issues. So you get some data from the application via your Mosquitto MQTT
> broker in HA already? Just lacking temperatures? Or no connection to the
> Mosquitto MQTT in general?
>
> —
> Reply to this email directly, view it on GitHub
> <#90 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BOIMPNKO3LU7WBDEE4QSJFD2NBZ3JAVCNFSM6AAAAABVBBOHHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJZGIYDKMI>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***
> .com>
>
|
Beta Was this translation helpful? Give feedback.
-
|
@moussa11, I have added a zip file,
https://github.com/jmcewen58/bms-to-inverter/blob/dev/mqtt.zip , to my fork
which contains all of the files which you'll need to test including
instructions, and home assistant configuration.
…On Thu, Jan 30, 2025 at 12:15 AM moussa11 ***@***.***> wrote:
@jmcewen58 <https://github.com/jmcewen58>
This is great. I will spare some time over the weekend to try it out, and
will share the feedback.
—
Reply to this email directly, view it on GitHub
<#90 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BOIMPNKB25NRYP66BCVWOZD2NHNT7AVCNFSM6AAAAABVBBOHHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBQGM4TKMQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
This is excellent. Much appreciated. It would be great though if MQTT auto discovery functionality can be added. [https://www.home-assistant.io/integrations/mqtt/#discovery-topic]. one clarity in the instructions, mqtt.producer.topic must match with state_topic in mqtt-bms.yaml snapshot from homeassistant: |
Beta Was this translation helpful? Give feedback.
-
|
@jmcewen58 thanks a lot. I will see that I will merge your changes to the code base. Do you have by any change a pull request where you added these changes? That would be easier to diff. |
Beta Was this translation helpful? Give feedback.
-
|
I've squashed-merged the dev branch into my main, and opened a pull request
for you. Seems moussa11 has validated functionality. And I'm glad to have
that additional tester. But I strongly suggest you regression test the
wrapper with Artemis client, which I am not able to do, before publishing.
I have a couple of other problems I've been working on, and will create
separate issues for you to track them soon.
…On Sat, Feb 1, 2025 at 10:25 PM Torsten Oltmanns ***@***.***> wrote:
@jmcewen58 <https://github.com/jmcewen58> thanks a lot. I will see that I
will merge your changes to the code base. Do you have by any change a pull
request where you added these changes? That would be easier to diff.
—
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BOIMPNJGFNRLZ2UWN2ARRTT2NW26FAVCNFSM6AAAAABVBBOHHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBTGAYTKNA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
I did consider auto-discovery, and may yet take a further look at it
someday. But for the short-term manual configuration in HA was a lot less
work. One of the biggest issues is that each different BMS provides a
different set of parameters, and the project is designed to handle all of
them. The discovery function is designed to simplify integration, which is
great, but if discovery led to several hundred sensors, the majority of
which have no data, that wouldn't be a good experience. So a mechanism
would need to be in place for each bms supported by the project to be able
to tell the MQTT implementation which elements to send to HA to discover.
This is not impossible, just beyond the scope I'm willing to do right now.
Jeff
…On Sun, Feb 2, 2025 at 12:40 AM moussa11 ***@***.***> wrote:
This is excellent. Much appreciated. It would be great though if MQTT auto
discovery functionality can be added. [
https://www.home-assistant.io/integrations/mqtt/#discovery-topic].
to add some clarify for others in the instructions, mqtt.producer.topic
must match with state_topic in mqtt-bms.yaml
snapshot from homeassistant:
image.png (view on web)
<https://github.com/user-attachments/assets/14815b51-b965-4b1f-8aec-eb9800ac0842>
—
Reply to this email directly, view it on GitHub
<#90 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BOIMPNLW426BXEAGRMILZOT2NXKXZAVCNFSM6AAAAABVBBOHHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBTGA3DIOI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
Hi, excellent work.
The setup:
RPI 4 with waveshare RS485/CAN. RasperianOS
Daly BMS UART to USB dongle (no CAN/RS485 port)
Deye Hybrid Inveter SUN-7.6/8K-SG01LP1-EU using CAN
Have another RPI 4 running Homeassistant OS with Mosquitto broker add-on.
Error from broker:
New connection from 192.168.2.244:48038 on port 1883.
Client disconnected due to protocol error.
Error from bms-to-inverter:
Appreciate the help
Beta Was this translation helpful? Give feedback.
All reactions