Cooperation and win-win development needs

[dav1dBoy]

Hello, reinhard-brandstaedter!
I am an embedded engineer and I have the ability to develop solarflow IoT modules, similar to DTU modules. Can you tell me the current real needs for solarflow products in Germany?
Will you use it with smart sockets or shelly products?
Looking forward to your reply.

[reinhard-brandstaedter]

Hi @dav1dBoy ,
implementing the solarflow-control on a IoT platform (e.g. on an ESP) was an idea I had also but I decided to go with a generic/container approach first.
I can see the interest for a turn-key solution of my tool running as a IoT device and think it would be appreciated by the SF community to have a DTU style device.
The direct use of SF controlling smart sockets or shellies I don't see that much. I rather see people combining it with smarthome software like IoThub, Homeassistant, NodeRed etc. where SF/SFControl becomes a data source that helps controlling/steering other devices. That said I'm also not a big fan of the smartplug integration with SF directly, only the integration with a smartmeter reader makes sense.

Happy to discuss.

[dav1dBoy]

I'm honored to receive your reply.
I agree with your point of view, and I can understand it as follows: In Germany, when smart meters serve as control centers, and SF and smart sockets serve as data sources and control terminals, is this an ecosystem worth improving?
I want to use my abilities, but I don’t have a direction yet.
In my opinion, the primary problem of current SF is the inaccurate data of BMS and the slow response of micro-inverse control; the second problem is the ecological issues of the Internet of Things such as overall network communication.
If you were me, would you spend time re-developing SF's IoT module?

[reinhard-brandstaedter]

Hi @dav1dBoy ,
sorry for the long delay in replying I've been travelling.
I'm not sure if I got your above statement right.
A smartmeter typically is not a control center, but a source of getting the overall household consumption. (especially for family houses, different for apartments - there you typically do not have access to your overall consumption as the measuring device is located outside reach).
I'm with you, regarding the limitation of SF data, although the response of the micro-inverter limitiation has already improved. Though controlling inverters e.g. via OpenDTU is still faster.

if you mean re-developing SF's IoT module as meaning to replace it's firmware I think that is a potential dangerous thing.
I do not think it's worth going down that path, as the current firmware can still be set up in a way that the SF reports to a local MQTT. Since this is working just fine, and a hub can operated/controlled purely local this is enough to be independent.

An "OpenSF_DTU" device could fullfill these purposes:

• endpoint for SF Hub telemetry (MQTT server)
• able to read from various smartmeter readers
• able to integrate/control OpenDTU
• able to control the Hub (via MQTT)
• integrate with Homeautomation systems (via MQTT)
  (thats basically what my tool is doing today)