Sorry for meddling, since I’m not an insider here at all.
Yet, I deem it uttermost important advice to clearly separate any network-based communication from e.g. serial. It’s sort of a rule for distributed systems to compartmentalise into subsystems which are then managed/connected via TCP/UDP. The base of it being architecture: Service-oriented, publish/subscribe (in most cases a wrap of the former), stream-based (RS). With OH service-oriented (incl. p/s) is easy, out-of-the-box and useful, but trying to shove streams into the mix a bad, baaaad idea IMHO.
I’d use a subsystem node (e.g. an ESP or PI) to realise a clean stream-2-network interface and leave the nice-to-have all-in-one OH (add-on) features here alone. More work, greater payoff and control. Best of luck!
@Jack_of_Atmon, Fully agree. I think we are in consensus here. I do it exactly the same as you describe in my own home system. I have quite a lot of technological components in the home all in the end controllable via OH. However, I have each and every subsystem designed and done in such a way, that they can work without OH as well. May be, some more advance features would not be available and you are not able to control it from one place, but it will work. So, distributed standalone technological systems integrated via OH for visualisation and control.
That is also why I’m so much suggesting avoiding WiFI bridge using internal TCP network for essential PV to Meter communication. Energy supply has to work even if the whole TCP network is down => use dedicated cable even if it means digging ditch into the grass and putting there 70m of protection pipe and new shielded cable.
@davek145 That’s what I’m talking about. Just like our brains falling back to the limbic system whenever thinking becomes inefficient or is too slow, engineers like us trust in copper (EDIT: alright, or glass fibre, but that sounds far to geeky) when we want to be sure.
Small disclaimer to my last post: It’s sort of a matter of opinion, what constitutes a “stream-based” communication approach. Readers, please imagine that my point was rather about end-to-end vs. network communication and that this shouldn’t be mixed up. That should bash the frigg out of devil’s advocates sitting next to you in the lecturing hall for good.
EDIT 2: I hereby propose that we choose a cool abbreviation for “glass fibre”. My candidates are “gfibre” (uttered akin to “pneumonia”), “dusty” (r.i.p. master Hill) and “blinky”. (…I’m bored…)
I spent my afternoon trying to get the cable connection to work! And in the end it actually worked!
I removed the 2 PW11s - no more Modbus-Wifi experiments.
2 old telephone cables had to be crimped together. I found two 100 Ohm resistors in my box (I didn’t have any 120 resistors left), but could only fit one to the smart meter. The connection still works. I was only able to test it in the evening with a Modbus USB dongle, but was able to query the values at 100 ms intervals via the tinkered cable.
Unfortunately, I was unable to see any power values above zero on the X3 as the sun had already set. However, the X3 received the meter reading from the smart meter.
Tomorrow at sunrise we will see whether the values are transmitted reliably.
Thanks for all the tips!
My to-do list has filled up. Next, I’ll take a look at the CAN connection from the X3 and see what I can read from it. Then I won’t have to do it via the wifi dongle.
Is there already some preliminary work on this? The Solax binding only works with the WiFi dongle. This was only available at the time when I had already completed my solution via HTTP binding. The github repo by squishykid was a good start.
I assume that the Modbus binding is used for this. A good Solax ModbusRTU documentation regarding the registers is available for download. Given the large number of registers, this is likely to be quite a job…
There should be a modbus:solaxx3 thing about the Modbus Binding - that would be great!
(Unfortunately I have no idea how to build this).
By the way, how do you connect to the Solax CAN port? Are you using a patch cable and connecting 2 PINs to a Modbus USB dongle on the Raspi? Or can the Raspi somehow read the Modbus PINs on its Ethernet port? Or can you use the IO PINs from the Raspi?
Or I use one of the unemployed PW11s to read the registers via ModbusRTU over Wifi (if that works stably) and save myself the cable connection with the Raspi!?
You’re a skirmisher in this case. Whatever you do now seems to produce valuable results, whether positive or negative. Please be the pioneer and keep us in the loop. Thank you so much (and this is rarely said in engineering, when it comes to no-profit)!
(…I’m bored…)
