The two most certain defects of the multi unit ID work are invisible to
the offline suites, because they only appear once a discovery has
actually run: the orphan sweep deleting the children of the other
connection, and the aggregation of the connected state.
This suite mounts the plugin behind a real ThingManager against a real
device. It is deliberately not a testcase, so "make check" never runs
it, but it is still built so it cannot rot unnoticed. Without
SUNSPEC_TEST_HOST every test skips, and no address is written into the
repository: the address of a real installation is customer data.
NOT YET RUN against hardware. It needs the address of a GEN24 and, given
the polling rate guidance, a deliberate decision to point it at a
customer inverter.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A GEN24 answers for the inverter on unit ID 1 and for its Smart Meter on
unit ID 200 by default, behind the same host and port. One thing now
carries two SunSpecConnection objects, the second one driven by the
meterSlaveId parameter that until now no line of C++ ever read.
The meter connection is created during setup but left idle: it is only
brought up once the primary connection has finished discovering, so the
two never handshake at the same time towards the same inverter. An
absent meter never fails the pairing, since a GEN24 without a Smart
Meter is a legitimate installation and the parameter has a non zero
default the user did not choose.
thingRemoved() and the reconfigure path now dispose of both connections
through a single entry point. Their else if chain used to stop at the
primary one, which left the meter connection outliving its thing with an
open socket and signals pointing at a destroyed Thing.
Child things look their model up across every connection of their
parent. The two connections of a GEN24 never announce the same model ID,
so no discriminator has to be persisted.
Adds a test suite instantiating the plugin behind a real ThingManager
with two connections. It lives in its own binary because the F1 suite
checks global call counters that extra configured things would falsify.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The existing suite only exercises free functions and the plugin JSON, so it
cannot see whether a thing class is dispatched at all. A thing class missing
from the dispatch in setupThing() falls into the final Q_ASSERT_X: in a debug
build the process dies, in a release build the assert is compiled out and
setupThing() returns without ever calling info->finish(), leaving the pairing
stuck with no message.
Split the tests into two suites. The logic one keeps its former scope and its
single dependency on libnymea-sunspec. The new one instantiates the plugin
behind the real ThingManager of libnymea-core and a faked HardwareManager, so
the dispatch of setupThing(), postSetupThing() and thingRemoved() is covered.
No network access takes place: the faked monitor is never reachable, so the
plugin never attempts a Modbus connection.
The four new cases fail: froniusConnection is not dispatched yet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
One test per AC of specs/fronius-sunspec.md, named test_AC_<n>_<what>.
Definition criteria (value ranges, thing classes, defaults) are checked by
re-reading integrationpluginsunspec.json. Behaviour criteria run either on
a model 124 register dump fed to the real libnymea-sunspec model, or on the
pure logic units the plugin is about to grow.
All red at this point: sunspecstoragelogic and froniusrules do not exist
yet, so the suite does not compile. That is the expected starting state.
