Shelly Uni - to monitor batteries

I have Shelly Uni coming in the mail, should be any day now!

My thoughts to using this would be to tell hubitat ( rule machine ) when my 12v 400ah lifepo4 batteries get low to 12.8 volts.. and hopefully I can program Shelly to turn on a smart plug that's working with hubitat. This smart plug has a charger on it to charge the batteries back up.
I want to program Shelly to only turn the smart plug on based on time of day and voltage of batteries, and turn the plug off when the battery reaches 14.2 volts.
If anyone has any experience with this device please let me know it's capabilities :slight_smile:
I would like some information on how to hook it up to the battery to read volts and how to program everything to work.

I’ve been using the Shelly Uni to measure a battery voltage and it works great!

There is a good thread with a driver here:

In case you’re interested, here’s a copy of a rule I have setup to do something similar:

Thank you for that, are you using the exact same device?

I can't wait to get it.

I always thought the driver was part of hubitat.

Yes, the exact same one. It is a really great device!

I am not aware of a driver in Hubitat, but haven’t checked recently!

Is there away for you to point me to the driver for hubitat? Looks a little confusing with all the links. I don't see any link that says driver ?

It is in message #16.

3 Likes

i got it installed, how do I program hubitat so I can see battery voltage ?

What do you mean by this? Did you decide to use my driver (from the thread that @BiGs linked to), and do you have a virtual device configured and working in Hubitat? Or are you at some earlier step in the process?

I've had the Shelly Uni working to monitor a 12 vdc battery using the adc0 child since Feb 2021. Update 0.0.25 breaks that. Any suggestions? When I restore 0.0.4 it works.

What issue are you seeing? @Sebastien, are you using 0.0.25 successfully with adc0?

As I wrote above, 0.025 breaks adc0. It works on 0.0.4. On 0.0.25 Common reports but there is no communication from adc0. Rolling back to 4 and all is good. I had tried this several months ago and was hoping there was a new update that would be a fix but no joy. Maybe 25 is the same one I tried a while back.

It wasn't clear what was going wrong with adc0 from your previous post. This post gives me more to go on.

If you enable debugging logging on the Shelly Common chiled and then hit refresh from the main Shelly Uni device in Hubitat, what happens?

If you have 0.0.25 installed and hit configure, what does this page look like from the Shelly device?

This on 0.0.25 As soon as I updated the 1 minute updates stop.

I am currently on 0.0.25 and have not seen any issues with voltage reporting on any of my 4 UNI’s.

Here’s a graph showing the output form 2 of them today:

1 Like

My errors occurred when I did a Package manager update from version 0.0.4 to 0.0.25. Is it possible that you started with 0.0.25. I'm wondering if the issue is related to the update being incompatible with the previous code.

That was my hunch as well, but we haven't gotten to the bottom of it yet in our PM thread. Thanks for helping track it down.

One way you could quickly test this -- you could create a new Shelly Uni virtual device with 0.0.25 installed and just point it at the same IP as your existing one. If it starts working again with that as a fresh start, just migrating references in rules and other places might be the easiest path forward.

When I go to set up a virtual device I'm at a loss as to what type of virtual device to select.

If you're creating a new device, use the type "Shelly Uni". All of the child devices will be created later after you add the IP address and save that parent device.

For some reason I ended up with two Common child device and no others.

The Uni IDs look different to me.
E8DB84D65648
0709d42a-3e60-4d8f-b9d4-38ba53d240ea

I deleted the two Commons and did initialize on the Uni and now have one Common but no other children. I still get the duplicate device ID warning. I'll have to get back to this later.

My mistake. The suggestion to install a duplicate (new) device for testing can't work because the DNIs collide.

Since you have a working backup to recover to, and if you're willing to go nuclear to try to figure this out, I would ask that you delete your existing 0.0.4 virtual device, then uninstall 0.0.4 using HPM, then install 0.0.25 using HPM, and finally creating a new virtual device from scratch.

If that blows up and you want to get working again, you can restore your 0.0.4 backup and then make the tweaks you figured out to get it working as a stopgap.

1 Like