Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: will it future work with dbus-flashmq? #55

Closed
mdkeil opened this issue Jun 26, 2023 · 23 comments
Closed

Q: will it future work with dbus-flashmq? #55

mdkeil opened this issue Jun 26, 2023 · 23 comments

Comments

@mdkeil
Copy link

mdkeil commented Jun 26, 2023

#1098

@freakent
Copy link
Owner

Thanks for sharing this. This will have implications for the driver as it is uses the Victron MQTT libraries. I will monitor Victron's project and plan accordingly. Watch this space.

@mdkeil
Copy link
Author

mdkeil commented Jul 6, 2023

Thanks, because the driver doesnt work with VenusOS 3.10 anymore.

@freakent
Copy link
Owner

freakent commented Jul 6, 2023

Please provide a log file showing any errors.

@mpvader
Copy link

mpvader commented Jul 7, 2023

Hi guys, the change from Mosquitto to FlashMQ includes deprecating removing dbus-mqtt. See our issue linked above 1098, for details.

@freakent
Copy link
Owner

freakent commented Jul 7, 2023

@mpvader, Thanks for confirmation but are you Deprecating or removing? Deprecating would mean it should continue to work for a while longer.

@mpvader
Copy link

mpvader commented Jul 7, 2023

ah thanks. Removing.

There only one service can listen to a port. So what we did per v3.10~12, which is change who listens to the local websockets port from mosquitto to flashmq, is what we'll be doing more coming time.

@mpvader
Copy link

mpvader commented Jul 7, 2023

ps. note that our MQTT API doesn't change much. There are some very nice improvements, especially related to the keepalive and supressing a resend of all topics; and otherwise all stays the same. Its just faster, and causes less CPU load on the GX device.

And is done via FlashMQ, which is developed by one of our own core team members in his spare time - which is maybe business wise not that important but personally I'm quite proud of that/him.!

@mdkeil
Copy link
Author

mdkeil commented Jul 16, 2023

Any new progess-info for an separate flashMQ-version?

@freakent
Copy link
Owner

freakent commented Jul 16, 2023

It's unlikely I'll be able to make any significant updates for a few months. If you have already experienced an error please share log file, as requested previously.

@mdkeil
Copy link
Author

mdkeil commented Aug 16, 2023

If you have already experienced an error please share log file, as requested previously.

v. 3.10 ~27

@4000000064dd15ca36b691a4 *** starting dbus-mqtt-devices ***
@4000000064dd15cd065e0eec Traceback (most recent call last):
@4000000064dd15cd065e35fc   File "/data/drivers/dbus-mqtt-devices-0.6.2/dbus_mqtt_devices.py", line 34, in <module>
@4000000064dd15cd065e5154     from device_manager import MQTTDeviceManager
@4000000064dd15cd065e60f4   File "/data/drivers/dbus-mqtt-devices-0.6.2/device_manager.py", line 17, in <module>
@4000000064dd15cd065e747c     import yaml

@freakent
Copy link
Owner

That error appears to be the problem related to the missing YAML library and not specifically the new version of Venus OS.

@mdkeil
Copy link
Author

mdkeil commented Aug 16, 2023

with VenusOS v3.0 it works without any error.

Edit: reinstalling dbus-mqtt-devices does the trick! 👍🏻

@freakent
Copy link
Owner

That's as maybe but others are also reporting this issue with the missing PYYaml library on Venus 3.0. PYYaml is not included by Victron in any version.

@mdkeil
Copy link
Author

mdkeil commented Aug 28, 2023

We're preparing v3.10 for release within a few weeks. In that release, we'll be shipping Mosquitto, not FlashMQ. In other words, all changes so far will be taken out for that release.

FlashMQ will be included again in v3.20.

@mpvader
Copy link

mpvader commented Sep 21, 2023

Hi all, there are now people thinking that there are issues with running this code (dbus-mqtt-devices) in combination with FlashMQ.

See above link by disaster123 for an example.

Having read the thread above, this is all just a suspicion and vague.

I don't see any problem related to FlashMQ. And, note that I also don't expect any problem.

@mpvader
Copy link

mpvader commented Sep 21, 2023

@freakent , am I right in concluding that this repo is expected to keep working fine as long as our dbus-mqtt project is installed?

What/where is the depedency of dbus-mqtt-devices on dbus-mqtt?

@freakent
Copy link
Owner

freakent commented Sep 21, 2023

Hi @mpvader , thanks for keeping an eye on this project :-)

I am not aware of any issue using this driver with FlashMQ, although I intend to do more testing. To be clear, from what I know of FlashMQ I do NOT currently see the need to create a seperate or new version of this driver as a result.

This driver has had an issue recently with a PyYaml dependency that started roughly the same time as the Venus 3.10 Beta. Some users wrongly assumed the issue was caused by Venus 3.10, when in fact it was an outdated dependency on PyYaml. This issue has now been addressed in the latest relesse. In the longer term I am working on a new version that removes the PyYaml dependency completely.

The driver does today have a minor dependency on dbus-mqtt. To simplify coding my MQTTDeviceManager class extends the MqttGObjectBridge class in the dbus-mqtt module. During installation, the setup script creates a soft link from /opt/victronenergy/dbus-mqtt to include this module in the python module search path for the driver. In the future I could either just include the source for this class directly in my own source tree or write my own version.

Would you consider including the functionality of this driver in VenusOS directly? It would be more efficient to have a single driver for any external MQTT devices instead of one for each, when each driver more or less does the same thing?

Thanks again.

@gharshaw
Copy link

gharshaw commented Nov 3, 2023

@freakent , Curious if you will be testing against 3.20~17 now that it is released with the new html5 app and flashmq? I have it installed and tanks do not show up correctly in flashmq on port 1884 but they appear correctly in mosquito mqtt on port 1883. The tanks do not show up in the new html5 app. The new html5
app is using local port 9001 which I believe is for flashmq. The tanks appear correct in dbus when viewing with dbus-spy.
I'm using your 0.6.2 driver on a CCGX.
Best Regards,
Gene

@freakent
Copy link
Owner

freakent commented Nov 3, 2023

Thanks for the heads up. I'm juggling lots of projects at the moment, but I'll try to take a look next week.

It's strange that you don't see it in the new HTML app. Does it appear in VRM?

@gharshaw
Copy link

gharshaw commented Nov 3, 2023

Yes. Tanks and Temps show correctly in VRM

Thanks!!

@gharshaw
Copy link

gharshaw commented Nov 8, 2023

@freakent I believe I discovered the issue. In short, the device_service.py was setting the dbus path "/DeviceInstance as a string value. I edited your code to cast it as an integer -- dbus_service.add_path('/DeviceInstance', int(self.device_instance))
and now all my devices appear correctly in flashmq and subsequently appeared in the html5 app and the new gui-beta app.
The following screenshots show how I discovered it.
The 1st screenshot is when I was running my CCGX in demo mode. Tanks where populating correctly. The 2nd screenshot is with my tanks via the dbus-mqtt-devices driver. I noticed that the DeviceInstance was encapsulated in quotes when using the dbus-mqtt-devices driver

image

image

And while browsing flashmq on port 1884. dbus-flashmq was indexing the devices incorrectly as it would only publish one of the devices with an mqqt path of 0 when the DeviceInstance was 4 as seen in this screenshot.

image

Gui-Beta
image

HTML5
image

Hope this helps

All the best
Gene

@freakent
Copy link
Owner

freakent commented Nov 8, 2023

@gharshaw Gene, thanks for the info but what version of the code is this in? Please can you post the block of code you changed?

If this against the Beta version please can you post feedback there?

@gharshaw
Copy link

gharshaw commented Nov 8, 2023

@freakent I'm using your 0.6.2 driver on CCGX v3.20~17. Edited file device_service.py line 82
image

Repository owner locked and limited conversation to collaborators Feb 2, 2024
@freakent freakent converted this issue into discussion #81 Feb 2, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants