search

nmakel / solaredge_meterproxy

Modbus proxy for SolarEdge inverters and unsupported kWh meters
MIT License
29 stars 20 forks source link

MQTT integration with Dutch P1 meter #20

Closed marcelrv closed 5 months ago

marcelrv commented 2 years ago

@nmakel here my integration with the Dutch P1 meter.

nmakel commented 2 years ago

So I'm debating whether this is the most effective way of getting P1 readings. The hardware required for this to work is the P1 reader, right? Why not interface with this hardware directly, instead of p1 device -> p1monitor/dsmrreader/whatever -> p1 monitor/dsmrreader/whatever to mqtt -> mqtt device in solaredge_meterproxy.

If it's a TCP device it should support more than a single consumer, right?

nmakel commented 2 years ago

I also had a look at your p1-reader project and I suspect I understand the stack a little better. My gut says the mqtt device that you submitted a while ago should be able to accept any source of P1 readings. The number of fields in a P1 telegram is limited, and getting the right value in the correct place should be little more than a quick lookup in a from-to map.

marcelrv commented 2 years ago

the hardware required are a 10k Ohm resistor & basic transitor to invert the signal. I use the hardware serial on a RPI to consume the P1 signal. I have had various (hardware/software) setups in the past 10 years I had a P1 reader. (separate serial ports, arduino+ethernet, esp32, currently hardware serial on (readonly) RPI) but keeping something stable to run for years without looking is challenging.

But indeed hardware like above in your post could be used as well. Likewise I could have written a direct input from P1 to this project.

I have chosen not that path for multiple reasons: 1) I have other equipment also connected to visualise the power details to bring it to my home automation. 2) Would have needed to rewrite that bit 3) The calculations were quite specific to the solaredge environment, hence choose to do the specific conversions/calculations ion this side rather than on the 'P1 sending side'

For folks where the P1 meter is close to the inverter and no other integrations required, I would make different choices wrt to the stack (easier with less failure points). But in my case meter and inverter are not close at all, I want all my raspberry Pi's to have readonly filesystem (as too many sd cards died in the last 10 years...) and some other considerations.

But indeed, the mqtt device I submitted is generic, this is not, so I would fully understand if you don't want to merge it.

nmakel commented 2 years ago

the hardware required are a 10k Ohm resistor & basic transitor to invert the signal. I use the hardware serial on a RPI to consume the P1 signal. I have had various (hardware/software) setups in the past 10 years I had a P1 reader. (separate serial ports, arduino+ethernet, esp32, currently hardware serial on (readonly) RPI) but keeping something stable to run for years without looking is challenging.

Cool, nice job.

I have chosen not that path for multiple reasons:

Agree with your reasoning.

But indeed, the mqtt device I submitted is generic, this is not, so I would fully understand if you don't want to merge it.

I think a P1 specific mqtt device with additional calculations and such is useful. If you don't mind I will apply a couple formatting edits and merge the pull request.

marcelrv commented 2 years ago

I think a P1 specific mqtt device with additional calculations and such is useful. If you don't mind I will apply a couple formatting edits and merge the pull request.

Sure.... I can imagine there are several items/formatting's that can be improved.