[sYfte]

Is anyone else with Victron Lithium and Lynx BMS, seeing Battery temps work over MQTT?
They're all null for me.

I posted this question in the Victron Community.
Is Temperature for Lithium Battery Smart via Lynx BMS available over MQTT? - Victron Community (victronenergy.com)

It's not supported. If you can't find the data in GX gui, you're not going to get it from MQTT/Modbus. None of the data you see in the BT app is exposed except for ATC/ATD. The Victron people I've talked to said it's coming with their new CanBus battery, but that was years ago, and still nothing out yet.

 

[Captadv]

The Victron people I've talked to said it's coming with their new CanBus battery, but that was years ago

Pretty sure I have that battery... I opened a GitHub issue for this.
Add Battery Temperature values to MQTT · Issue #1192 · victronenergy/venus (github.com)

 

[sYfte]

Pretty sure I have that battery... I opened a GitHub issue for this.
Add Battery Temperature values to MQTT · Issue #1192 · victronenergy/venus (github.com)

Victron doesn't make CanBus batteries currently. The 3 wire DIN connections is just to provide continuity for ATC/ATD signals to the VE.Bus BMS.

You can also reference Modbus-TCP-Registers, and you'll note that there's only a single temperature datapoint for batteries, which is when using the special temp. probe+power with BMVs and SmartShunts.

 

[mototreks]

1TB SSD. Because why not. ;-)

After spending the better part of 2 days getting HA Yellow to load the OS I decided to do the "because why not" upgrade to a 1TB SSD too. Turns out the boot/load software couldn't resolve "version.home-assistant.io" so that it could download the latest version of HA. I added a local DNS record to the Pepwave MAX BR1 Pro to resolve the IP address and the HA OS was downloaded and up and running within 15 minutes.

So now I have a "production" system running on the Yellow hardware and a "development" system running on a VM - let the fun begin!

 

[brío]

Ultimately, this document proved most useful in getting it all going. There's some typos in there, so it took me a while to get it all sussed out.

Here's my Mosquitto config:

I've been trying to follow you guys into MQTT world (which I have never tried before), but I am stuck. I am pretty sure I have Mosquitto running with the built-in broker. But, I can't figure out where to put this "Mosquitto config" file that you reference. The file you link to says that I am supposed to use Samba Share to add a file to "/share/mosquitto/". My machine has no such directory. Do I create one, or what? I am running the supervised HASS os, btw.

Any hints would be appreciated.

 

[gregoryx]

I've been trying to follow you guys into MQTT world (which I have never tried before), but I am stuck. I am pretty sure I have Mosquitto running with the built-in broker. But, I can't figure out where to put this "Mosquitto config" file that you reference. The file you link to says that I am supposed to use Samba Share to add a file to "/share/mosquitto/". My machine has no such directory. Do I create one, or what? I am running the supervised HASS os, btw.

Any hints would be appreciated.

I'd make sure MQTT Explorer can "see" the broker first. That's when I was certain it was working. The cool thing with that is you can aim it at the Cerbo and know if that's working. Then aim it at your broker to see if that's working.

I'm not running the HASS OS, so my file locations are probably a little different. My MQTT broker is a Docker container running on the same system as Home Assistant, so I'd think the outcome is the same as using the add-on: it should show up like any MQTT broker on the same IP address as HASS and at port 1883.

All they're trying to say with the Samba Share thing is to get access to the ability to see/write/create files inside the Mosquitto configuration folder. I'm guessing that the add-on creates a share for that? I'm really not sure. Eventually, there should be a file relating to the Mosquitto broker (add-on, presumably) and that's where the config info to connect to Cerbo belongs.


Just realized that I have the other Hass system running HASSOS with Mosquitto installed, so I can check.

Okay... yes, just installing the Mosquitto add-on makes it show up in MQTT Explorer. So, that's a good test.

And... sweet! Yes, it works exactly as described in the article.

Rather than figure out the exact location in the native file structure through SSH (my tendency... 'cause I always like to see what's actually going on), I just went with the Samba Share add-on to see how it all goes. From Windows, connected to it by typing \\192.168.253.13\ in File Explorer then entering the user/pass I had entered into the Samba Share config and I get this:

Go into the "share" share and created a folder called, "mosquitto," then created a text file inside there called, "bridge-venus.conf," then put the contents into it to connect to my Cerbo:

connection venus-home
address 192.168.8.9
topic # both 0 venus-home/

Restarted the Mosquitto add-on and watched the logs. Nothing. Saw MQTT Explorer lose connection and re-establish it, so pretty sure the add-on restarted. Checked the Mosquitto Config and realized the "Customize" section said, "active: false" and changed it to "true" and restarted the add-on. Came right up in MQTT Explorer. Good to go!

Mine has the "venus-home" in there with it also underneath it (as well as the Shelly) because I have the Shelly aimed at the Cerbo. Brokers upon brokers. 😏

I left my initial thoughts above in case anyone else is curious (and perhaps running a Docker setup).

 

[brío]

Awesome! Beyond the call of duty. Thanks!
I'll give it a try tomorrow.

 

[mototreks]

I've been trying to follow you guys into MQTT world (which I have never tried before), but I am stuck. I am pretty sure I have Mosquitto running with the built-in broker. But, I can't figure out where to put this "Mosquitto config" file that you reference. The file you link to says that I am supposed to use Samba Share to add a file to "/share/mosquitto/". My machine has no such directory. Do I create one, or what? I am running the supervised HASS os, btw.

Any hints would be appreciated.

I'm running the supervised HASS OS too and having gone though the same thing a few weeks ago I found that the mosquitto folder is located under root/share. On my "production" system, which does not have the mosquitto broker installed, I only have the share folder. So, I guess I added the mosquitto folder and the bridge-viltron.config file on my development system.

from my development system with the mosquitto broker up and running.

 

[brío]

All working now. Thanks @gregoryx & @mototreks! For some reason, it wouldn't work with Gregory's device ID in the automation. 🤦‍♂️

BTW: I discovered that instead of using Samba Share, you can just use the "Terminal" add-on, which gives you a shell and the Nano editor.

 

[mototreks]

Back in 2022 after @brio sparked my interest in ESPHome I bought a starter kit with an ESP32 breadboard and a bunch of electrical bits. I did one lesson to blink a LED before packing everything back up in its box at storing it deep in a drawer. With the van buildout becoming a reality, I decide to validate one of my ideas of using Home Assistant and ESPHome to control lighting. I was totally surprised by how easy it was to configure an ESPHome device. @brio you were right 👏 The biggest challenge was discovering that after downloading my configuration I needed to add the new ESPHome device to HA😬 Oh, there was that moment when I needed to switch my browser from Safari to Chrome for the initial ESP32 setup but at least the ESPHome software gave me a hint. And then there was the whole GPIO pulldown issue but I’m guessing an external resistor (I’m not a hardware type of person) may help that. But, I’m setting here having invested less then 4 hours, with a running ESPHome setup controlling my Shelly RGBW2 relay and an LED light.

I can control the light via Home Assistant, a physical button via ESPHome or the Shelly app on my phone. And, each system stays in sync displaying the correct on/off stats of the actual light.

At some point I’ll need to move this setup to the van. So, can I just use the 3.3VDC source on the ESP32 device to hardwire a bunch of buttons? Or do I need to supply an external 3.3VDC source for the buttons and interface that back to a GPIO pin?

 

[chicagoandy]

Yes!

I did my first esphome project to control a fan. Fun and easy.

I am curious, could you not use the Shelly integration to home assistant directly?

 

[brío]

Congrats! Yeah, once you get over the hump, ESPhome really presents unlimited possibilities. As one who mucked with ESP32s for years now, I can attest the ESPhome seems like a miracle in comparison to previous IDEs.

Oh, there was that moment when I needed to switch my browser from Safari to Chrome for the initial ESP32 setup but at least the ESPHome software gave me a hint.

I generally just plug it into the RPI. As long as you have access, it is easier and more robust than the browser method.

And then there was the whole GPIO pulldown issue but I’m guessing an external resistor (I’m not a hardware type of person) may help that.

Not sure what your issue is. ESP32s have programmable pull-ups and pull-downs built into most IO pins. ESPhome has commands to activate them. You rarely need external resistors.

So, can I just use the 3.3VDC source on the ESP32 device to hardwire a bunch of buttons? Or do I need to supply an external 3.3VDC source for the buttons and interface that back to a GPIO pin?

Using the internal 3.3V supply will work, but there is a better choice: Turn on the pull-up resistor of the input pin, and set the logic to "inverted". That way, an open circuit on the pin will float "high", which will be "off". To assert the pin, have your switch just ground the input. This has several advantages: (1) It is safer, since a short on the wire to the switch would simply turn on the pin, whereas if you put 3.3V on it, it would likely fry your chip; (2) It may be more robust, since a floating input is susceptible to induced noise on the lines; and (3) You can "wire-or" multiple switches to control the same pin, without having to run power wires all over the place.

I am curious, could you not use the Shelly integration to home assistant directly?

I was wondering the same thing. Is it that you are really using the ESP to monitor multiple switches, rather than the Shelly itself? Or, do you intend to turn off the HA machine and still have the lights run via the ESP32?

 

[mototreks]

I am curious, could you not use the Shelly integration to home assistant directly?

On, I do use the Shelly integration - works great too.

I guess I didn't really explain the end-game. One of my main goals in automating the van is to have all the lights configurable. I tested the Shelly RGBW2 relay here as a learning experience. In that test I used a physical switch (momentary button so that it doesn't hold state) wired to the relay to turn the lights on/off/dim. But, I may also like a physical switch to be "virtual" so that it too can be configured as needed. What I was playing with above was having a physical switch do nothing more than send a signal to HA so that I can configure it. In the setup above the switch (in this case a momentary button) is connected to ESPHome which triggers a HA automation to 1) turn on one of the lights connected the the Shelly relay via the Shelly integration and 2) toggle an ESPHome GPIO Switch which lights a little LED on the breadboard (just for fun).

So, now I have two ways to implement physical switches. One is with a hardwired switch to the Shelly relay that is not dependent on HA, Wifi or anything other than the Shelly relay. This could be used as a default method to insure one can always turn on a light even when the whole automation system fails. The second method is through a "virtual" physical switch that triggers an automation script in HA. What that script does is up to you

 

[mototreks]

Not sure what your issue is. ESP32s have programmable pull-ups and pull-downs built into most IO pins. ESPhome has commands to activate them. You rarely need external resistors.

Having never used an ESP32 device before I did finally find the pull-down option and that made the switch work a lot better.

..., but there is a better choice: Turn on the pull-up resistor of the input pin, and set the logic to "inverted". That way, an open circuit on the pin will float "high", which will be "off". To assert the pin, have your switch just ground the input. This has several advantages: (1) It is safer, since a short on the wire to the switch would simply turn on the pin, whereas if you put 3.3V on it, it would likely fry your chip; (2) It may be more robust, since a floating input is susceptible to induced noise on the lines; and (3) You can "wire-or" multiple switches to control the same pin, without having to run power wires all over the place.

I should have known you would have the way better way 👍 This sounds great. Now I just need to translate that technical electrical talk into physical wires 😜

I was wondering the same thing. Is it that you are really using the ESP to monitor multiple switches, rather than the Shelly itself? Or, do you intend to turn off the HA machine and still have the lights run via the ESP32?

Just playing around. But yes, multiple "virtual" physical switches that can be monitored in HA.

 

[mototreks]

Using the internal 3.3V supply will work, but there is a better choice: Turn on the pull-up resistor of the input pin, and set the logic to "inverted". That way, an open circuit on the pin will float "high", which will be "off". To assert the pin, have your switch just ground the input. This has several advantages: (1) It is safer, since a short on the wire to the switch would simply turn on the pin, whereas if you put 3.3V on it, it would likely fry your chip; (2) It may be more robust, since a floating input is susceptible to induced noise on the lines; and (3) You can "wire-or" multiple switches to control the same pin, without having to run power wires all over the place.

Well, that was easy and a bit scary that I actually understood what you wrote 😉 My ESPHome device is reconfigured and up and running the "better choice" - Thanks again @brío 👍

 

[mototreks]

Home Assistant and Siri

Another way of accessing Home Assistant entities (and my lights) is via Apple HomeKit. I had wanted to try this integration out so I installed the HomeKit Bridge integration. I just followed the default installation instructions on the HASS HomeKit Bridge site and a few mouse clicks later Siri was turning on/off and even dimming the lights I had attached to the Shelly relay.

I guess I better put in an order for some ESP32 hardware and more Shelly devices..

 

[chicagoandy]

Home Assistant and Siri

View attachment 202249



I guess I better put in an order for some ESP32 hardware and more Shelly devices..

Fyi, Shelly devices pretty much are Esp32, people typically don't run both.

I think you probably could have used the sensor inputs on your Shelly instead of the Esp32, or you could have wired your lights directly to the Esp32 instead of Shelly. There is no need for both of them.

Shelly literally had a esp device inside it. Sadly it can be tricky to get esphome flashed into them, but the integrations work great.

I'd recommend you try to solve this with just the ESP device.

 

[gregoryx]

Fyi, Shelly devices pretty much are Esp32, people typically don't run both.

I think you probably could have used the sensor inputs on your Shelly instead of the Esp32, or you could have wired your lights directly to the Esp32 instead of Shelly. There is no need for both of them.

Shelly literally had a esp device inside it. Sadly it can be tricky to get esphome flashed into them, but the integrations work great.

I'd recommend you try to solve this with just the ESP device.

I've wondered about this as well. I have tried a handful of integrations and the Shelley is super reliable; but so is the ESPHome stuff. I really like the clean little "device" aspect of the Shelleys (in spite of the cost) but it seems like it'd be nice to just make them ESP devices... 🤔

I'm probably only leaning this way because once I start a breadboard project, it remains a rat's nest of wires forever.

 

[mototreks]

Fyi, Shelly devices pretty much are Esp32, people typically don't run both.

Yeah, I had head that.

I think you probably could have used the sensor inputs on your Shelly instead of the Esp32, or you could have wired your lights directly to the Esp32 instead of Shelly. There is no need for both of them.

Shelly literally had a esp device inside it. Sadly it can be tricky to get esphome flashed into them, but the integrations work great.

I'd recommend you try to solve this with just the ESP device.

I can see your point, especially if all I wanted to do was turn lights on/off with ESPHome. Actually, one can attach a switch to the RGBW2 relay and setup it up to turn the lights on/off/dim or be completely detached from the relay - sort of what I did with ESPHome. However, I'll be using ESPHome to interact with other non-light devices too. BTW, the RBGW2 relay provides a lot of functionality like power monitoring of each of the 4 channels, power-on options, auto on/off timers etc. OOTB, it's a pretty nice little device.

 

[chicagoandy]

I've wondered about this as well. I have tried a handful of integrations and the Shelley is super reliable; but so is the ESPHome stuff. I really like the clean little "device" aspect of the Shelleys (in spite of the cost) but it seems like it'd be nice to just make them ESP devices... 🤔

I'm probably only leaning this way because once I start a breadboard project, it remains a rat's nest of wires forever.

It sounds like you're ready for flashing esphome to the Shelly.

(I haven't tried this yet)

Shelly Plus 1 flashing and setup guide/ tutorial

As I found no real instructions on flashing the Shelly Plus 1 (not PM) with esphome I decided to write a small guide for everyone also being lost. First of all i got these shellys just for visual reference: There is unfortunately not OTA- flashing method (as of now:17.11.22) so dont just...

community.home-assistant.io