Openhab Solar Monitor

I have several hardware designs, in various stages, that I hope to complete and implement, for use by the openhab community. One of them is a solar charge controller. I am currently working to complete a binding which allows for integration of a solar setup (in my case, off-grid) with the openhab platform .My ultimate goal is to design hardware with openhab in mind. I know that openhab is ‘vendor agnostic’, and I think this is one characteristic that makes it great, however I think it would also be great to have hardware that is designed for openhab.

For the Solar charge controller, it is tcp/ip based and reports real-time data values for some basics such as:
PV voltage
battery bank voltage
charge current
charge watts
total watts
battery bank temp
outside temp
etc.

Any input, feedback, criticisms, and/or advice on the issue of developing hardware for openhab is greatly appreciated, especially with this solar device. I also want to be sure not to overstep any bounds within the forum on this topic. I reviewed the FAQ but I’m still not sure if this is allowed or not.Hopefully a moderator will step in if this the case. Thanks so much

2 Likes

I’m not sure this makes sense in the context of openHAB. openHAB is all about serving as a Bridge between lots and lots of technologies and interfaces. As such, there really isn’t an “openHAB way” for integrating with hardware. Instead, openHAB adapts itself to work with the hardware, not the other way around. The only way to make hardware designed for openHAB is to write a custom binding that supports your hardware. But why do that when existing bindings can do the job?

The most popular ways to integrate DIY hardware are as follows (in no particular order):

  • serial connection over USB if the device is close to the server and not on the network
  • MQTT when the device is on the LAN
  • RFM69HW when the device is power constrained and WiFi or Ethernet needs too much power

It isn’t clear to me how power constrained this device needs to be. If it is running off of a solar charger or batteries you might consider an RFM69HW setup. The transceiver is very power efficient and lets you turn it off and on as necessary to conserve power. You can get orders of magnitude more life out of the same battery charge using this over WiFi.

There are all sorts of tutorials for this. I’ve implemented this myself so let me know if you have any question.

If your DIY device is on the LAN, it will be far easier to implement, far more flexible, and far more generic (i.e. work with all sorts of home automation systems) to use MQTT. The protocol is light weight, has excellent support almost everywhere, and is very flexible for use with openHAB.

Obviously, you could just use the TCP/UDP Binding and develop your own protocol to communicate with this device, but that will take more work and be less capabile than MQTT.

I see no problem with this posting.

I really appreciate your reply. Reading my post again I didn’t do a great job of conveying my situation and thoughts on this. Thanks for ‘hanging in there’ with me, as I am better at doing things than explaining things…lol.

Maybe I can try again with more detail?

I have an off-grid solar setup:

Solar panels ----> Charge Controller -----> Battery Bank -----> DC loads/devices/etc.

I searched but did not find an existing hardware device with a binding that could provide data from my setup (data metrics listed in original post). The closest I could find was this recent post:

That post deals with a grid-tied solar setup using AC micro-inverters. It also details how the OP reverse engineered the protocol to adapt the hardware device to integrate with openHAB.

The post references openenergymonitor, which is another great project, but is also designed to monitor AC voltages.Going further down the rabbit hole, there is a forum member at openenergymonitor that built their own PCB to monitor their DC solar setup with openenergymonitor. There is an exisitng binding for openHAB, but I would need to build this DIY hardware device to go between the charge controller and openHAB. Their custom PCB was also designed for their specific situation, which happens to be a 48V setup, so I would need to adapt it to my system voltage. I realize that this is the nature of “DIY” but I also think that there is a better way.

Using the existing binding I would need the following hardware:
Solar Setup---->DIY PCB----->openenergymonitor----->openHAB binding

I’d really just like an off-the-shelf solar charge controller to report data to openHAB, as directly as possible.
Solar Setup------>openHAB binding

So, I ended up “making” one by modifying an existing controller and writing new software. It is a solar charge controller that can be used with 12/24/48/96V DC setups and has ethernet. I think I am about 75% on building the binding, but I am still new to this aspect. I could also implement MQTT without too much re-configuring, which is part of the reason I stopped to get feedback.

I’ve been singing openHAB’s praises since I stumbled across it. I have also been cobbling together home automation setups for years, and openHAB is the best thing that has happened to home automation since it’s inception.

I just wish that more hardware currently on the market was easier to integrate. In my opinion, end-users should not have to reverse engineer protocols, even if it is sometimes fun to do!

I’ve also attempted to build other hardware for collecting data in openHAB, but I continue to run into problems/limitations with the hardware.

All I want for Christmas is hardware that is as amazing as the openHAB software! :grinning:

If you still happen to be reading this long post, thank you again, and let me know if you still think MQTT is easier to implement (considering the work I’ve already done on the binding approach).

Hi,

I did the ginlong inverter monitoring, but I think you are more looking at something along the lines of one of my other projects:

This is of the form:

Solar->charge controller->Serial interface->wifi->MQTT->Openhab (and hence influxdb for graphing)

The EPSolar RS485 protocol is pretty well documented too (as far as any of them are anyway). The MQTT server is hardcoded into the arduino sketch, as are the wifi details, but it wouldn’t be too much of an addition to put a small screen on there with some buttons to do a config interface.

Personally, I think MQTT is the way forward for this, rather than having another random binding. Its a very simple protocol to follow, and easy to incorporate into openhab.

Yes, if I were doing this I would still use MQTT. It will still be easier for you to implement, give the most flexibility, and give you compatibility with more than just openHAB. If you read up enough in the DIY electronics space, these days it seems rare to encounter any project like this that does not use MQTT. And there is a reason, it really is fantastically well suited for this problem space.

1 Like

Thanks for your feedback as well. I really wasn’t meaning to call you out by citing your post, but I appreciate that you added to the discussion.

This is where I get hung up. If openHAB is meant to be a bridge for lots of (disparate) technologies and interfaces, then won’t there will always be “another random binding”?

Perhaps not random, but actually the opposite: another very specific binding, tailored to a specific hardware vendor. Isn’t that the point that @rlkoshak made? Maybe I am missing something here.

And perhaps I am asking for too much: a hardware vendor that eliminates the middleware to speak to openHAB.

Even your other project is:
Some Hardware----> Some middleware hardware (RS485 to Modbus adapter)---->another middleware hardware (NodeMCU)----> openHAB

Please don’t get me wrong: I am NOT trying to detract from your hard work and contributions to ‘the cause’, I am merely trying to illustrate that all of us are having to create workarounds for things that we should not have to.

The reason OH exists is because every hardware vendor creates their own way to talk to their hardware or technology. It is a fragmented world with almost every vendor having their own walled gardens and stovepipes.

If you create your own binding, you will have created your own custom protocol, your own walled garden, your own stove pipe. You are making the problem worse.

However, if you use an existing protocol, one that is the defacto standard for DIY electronics and even the standard for many commercial offerings, you will be much closer to your goal.

2 Likes

This is so eloquently stated, and I think I now have a much better understanding.

I definitely want to be a part of the solution, not the problem. Soon I will quit my day job and make automation hardware that needs no middleware, uses a well established ‘stovepipe’ such as MQTT, and is plug-and-play with openHAB.

Also, wood fuel is a lot less renewable, please use solar and wind :rofl:

2 Likes

we support this platform that can talk to charge controllers, solar inverters, switches/PLCs, battery computers and also weather webservices:

http://solarnetwork.net/v4/architecture/

it has an OSGi plugin framework also.

No offense, but everything you can do, OpenHAB can do better.

I’m going to need a lot mote convincing to spend time to write a plugin for your cloud-based service when I can use openHAB to collect, analyze, and report my data locally (and access it remotely from my own system or using openHAB’s cloud based service).

For example: I have an IPANDA iSmart charge controller, with proprietary protocol for reporting charge Controller data, on my off-grid setup. What steps are needed to begin using SolarNetwork to collect and report the data on this specific setup? What hardware is needed?

Hi,

I think @rlkoshak said it well when he described the problem of fragmentation and walled gardens and the fact that OpenHAB “adapts itself to work with the hardware, not the other way around”. We call that “silo-busting” and are also adaptable to new hardware. The advantage of OSGi is that you can build a really flexible, solid platform for something that is constantly updating and changing, especially when your client implementation is remote. It’s great to even be compared to openHAB but our problem space is much narrower. :slight_smile: So I think you are correct in that you probably can achieve what you are looking for with OpenHAB, which is an awesome platform. It just sounded like what you are building possibly would also possibly suit SolarNetwork.

Looking at the iPANDA iSmart device, it looks like it has an RS-232 protocol. We have created plugins that talk to devices over RS-232 and RS485 - so likely a new plugin based off one of these would be the way forward. We speak to a Morningstar charge controllers over RS-232, which use a Modbus RTU protocol - that might be a start. But if it does have Modbus with declared registers for voltage, current and power you might be able to use our generic Modbus Device without any coding:

http://solarnetwork.net/v4/testing-the-modbus-device-plugin/

Looking at the iPANDA iSmart device, I think all you would need is a USB-to-RS232 adapter:

https://www.aliexpress.com/item/USB-to-RS232-Male-COM-Port-Serial-PDA-9Pin-DB9-Serial-converter-Adapter-GPS-FTA-Cable/32256629382.html

and then a DB9-to-RJ45 adapter - we would probably use one of these:

https://www.jaycar.co.nz/d9-female-to-rj45-computer-adaptor/p/PA0906

because there’s no soldering, it’s just snap together - you map the RX/TX pins to CAT5 pairs and and plug it in.

question about myopenHAB - it looks very easy to configure a Pi to be remotely accessible, but is there an SSH interface available to the device once a unit is authenticated? We have that, it’s called SolarSSH:

http://solarnetwork.net/v4/solarssh-for-firefox-chrome-and-safari/

and there’s an API which you can use if you want to create your own remote access apps:

Thanks, John