Open z-master42 opened 1 year ago
You can view the closed Issue #3, which may solve your problem.Special thanks to @lbouriez for their strong support.
I was able to successfully add the MQTT broker as an external bridge. What irritates me is that, in addition to the values from my own SolarFlow, I also get three other Zendure devices whose values I can now read.
Please check if you have replaced all the appKey with your own in your configuration.
I used the same format as here.
connection external-bridge
address mqtt.zen-iot.com:1883
remote_username APPKEY
remote_password APPSECRET
clientid zendure
topic APPKEY/# both 0 zend/
At the moment, I can see the following devices with the above configuration. Behind zend is my SolarFlow, as the topic was configured.
For the SolarFlow, the following sensors can be accessed via MQTT:
Some values are clear from the terminology, like the power sensors, the limit sensors and electricLevel, but what do the other sensors reflect?
What do hubState and socSet indicate? What does inputLimit indicate?
Since all power sensors are seen from the hub, remainOutTime and remainInputTime should therefore represent the remaining time until the battery is fully charged and the remaining time until it is discharged. Or is it the other way round?
The way your MQTT broker plays out the values, only the change of a value is communicated (state). As a result, Home Assistant fills the log with warnings/errors that a dict_object related to value_json.xxx has no attribute. If this is intercepted by specifying a default value, the last value remains until it is changed. This means that even if, for example, the battery is not being charged at the moment, Home Assistant will still display the last value and not 0 W. If the default value is set to 0, e.g. for the power sensors, the result is that the displayed value jumps back and forth between 0 W and the current value, as the transmission does not take place at such a regular interval as is expected by Home Assistant or the Mosquitto Broker.
Any solutions for this?
Edit: Answered a few questions for myself
There will be more.
As far as it currently works with the anomalies and restrictions described in the issue history, the Mosquitto broker addon log is flooded with messages like this:
2023-07-13 18:11:29: Connecting bridge external-bridge (mqtt.zen-iot.com:1883).
2023-07-13 18:11:29: Client local.zendure closed its connection.
Is this a "normal" behaviour?
To allow HA to auto-detect the sensors without the need to configure them ourselves I suggest to add a mapping rule in the mosquitto.conf like this. Also used the APPKEY as my client id and the multiple other devices were gone!
connection external-bridge
address mqtt.zen-iot.com:1883
remote_username <APPKEY>
remote_password <SECRET>
clientid <APPKEY>
topic <APPKEY>/<DEVICEID>/# both 0
topic # in 0 homeassistant/sensor/APPKEY/ APPKEY/sensor/device/
@z-master42 , did you find a solution for this? _The way your MQTT broker plays out the values, only the change of a value is communicated (state). As a result, Home Assistant fills the log with warnings/errors that a dict_object related to valuejson.xxx has no attribute. If this is intercepted by specifying a default value, the last value remains until it is changed. This means that even if, for example, the battery is not being charged at the moment, Home Assistant will still display the last value and not 0 W. If the default value is set to 0, e.g. for the power sensors, the result is that the displayed value jumps back and forth between 0 W and the current value, as the transmission does not take place at such a regular interval as is expected by Home Assistant or the Mosquitto Broker.
This is especially nasty if one is building automation around the data that goes between a value and 0.
Did you achive with above config a auto discovery?
No not yet, I'm still trying and similar to you, my MQTT knowledge is getting deeper day by day ;-) What I noticed is that with a direct connection to the Zendure broker the update of the data is much faster and more regular than when it is connected as a bridge. So that the normal user should not have the "problem".
Auto discovery seems to work. But you have to implement all modifications via customize in the configuration.yaml. In addition, there will certainly be many warnings in the log for sensors that are not regularly updated. After this morning's forced downtime, the data is definitely coming in much faster and more frequently (see closed issue #22 ).
Isn’t auto discovery in Home Assistant integrating all devices automatically? So why I have to put a configuration into configuration.yaml? Ok, for customising. But this is at the moment not working like a normal! At least yesterday evening!
If it is working for someone (standard way of mqtt auto discovery for ha), it would be nice to see in which way this could happen as external bridge in Mosquitto, the way to configure the complete MQTT to Zendure is not a suitable way.
thx
Use the mosquitto.conf from @reinhard-brandstaedter. Then the sensors are created automatically by HA. As far as I know, there is currently no other way, for this Zendure must adapt the format of its topics.
I tried, but with no result! I get the messages but no auto discovery.
DeviceID : 5 digit numeric number is out of the Pvhub the ID-Number in the app?
This is the alphanumeric value after the AppKey when you retrieve your data via e.g. the program MQTT-Explorer.
So something like above In the picture like “j1qwDJ6c”? I tried this, but will do again!
if we receive status of a specific ID(all) so I could receive even with my credentials your Id, if I could even send some parameters to a foreign Id, may this could be a security reason…
This alphanumeric id is the same as in the sensor state name?
like “j1qwDJ6cpowervalue/…”
j1qwDJ6c is the AppKey if you expand j1qwDJ6c in the picture above you get the next alphanumeric value (let's call it DeviceID) and if you expand it again you get the state which contains the updated values.
Maybe that helps to explain it: #3.
@thecem autodiscovery of sensors doesn't necessarily mean you will get a device as well. If I'm not completely wrong, for HA to create a device you would need a "birth" message in your broker, and that message would have to be sent (persistent) by the device to Zendure's MQTT and then via bridging to your own. My configguration from above with mapping topics into the right tree in the broker, just creates the sensors (as defined by Zendure).
@reinhard-brandstaedter YOU ARE RIGHT!
I expected to have a device and underneath the sensor´s. The sensors and even the switch is as an entity there. thx.
Is the autodiscovery with direct connection from HA to the MQTT-Broker of zendure, better implemented or even the same?
Sorry for my question but I don't get it. Why do I need the Mosquitto broker Add-on in Home Assistant? Is the MQTT integration not enough and is it possible to connect it directly with the Zendure MQTT broker?
Right, you don't need it if you haven't used the MQTT integration yet. But there is nothing in the readme that says you should/must use Mosquitto. So why do you ask?
Because nearly on all issues Mosquitto is shown or mentioned. But in the meantime I got it working :)
Because most of them have the Mosquitto broker addon installed, since they already use MQTT with other devices and Zendure so far only offers the possibility to connect to their broker instead of providing the data locally and therefore you first have to know how to connect two brokers. This is because the MQTT integration can only be used once.
In Home Assistant, you can only have one MQTT broker integration running. This means that if you already have the Mosquitto broker addon installed on your Home Assistant, you cannot add another MQTT broker integration. What is a solution for this not at all unlikely case?