Aligne la ligne nightly sur le support Fronius GEN24 déjà monté en testing :
signe du compteur, batterie fantôme, ordre des mots des float32.
nymea-plugin-sunspec-etm01 passe de 1.15.2+etm6 à +etm9.
La branche descend d'experimental-silo, donc cette fusion n'apporte que les
huit commits du lot — rien de landing-silo ne remonte ici. En particulier
waveshare-relay-d8 reste PRÉSENT : la suppression f25b620 vit sur la ligne
landing/main et n'appartient pas à l'historique fusionné, conformément à
l'avertissement de ce commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le message affirmait « le plugin lit de travers », vrai avant 1.15.2+etm9 et
faux depuis. L'outil sert à mesurer un APPAREIL, pas à juger une version : il
dit maintenant ce que lirait un lecteur gardant le défaut de la bibliothèque,
et rappelle depuis quelle version le vendor Fronius force big endian.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
byteOrder() renvoyait ByteOrderLittleEndian au motif qu'on « supposait le
défaut SunSpec ». La supposition confondait le défaut de la SPÉCIFICATION avec
celui de libnymea-sunspec, qui est son contraire : convertToUInt32 lit
registers.at(1) puis .at(0) en little endian. Garder ce défaut revient à lire
tous les float32 avec leurs deux mots permutés.
Mesuré le 2026-08-07 sur un Symo réel, en lecture seule : le compteur 213 sur
l'unité 200 sert Hz = 4248 0000, soit 50,0000 en big endian et 2,3777e-41 en
mots inversés. L'onduleur 113 concorde.
Le coût n'était pas un décalage mais une absurdité. Reproduit sur banc avec le
simulateur émettant l'ordre du matériel : un compteur important 2,7 kW rapporté
comme exportant 107 MW, et l'arbitre enclenchant toutes les charges sur un
« Surplus PV 107622496 W ». Le thing reste connected, sans erreur Modbus.
Conséquence sur l'ordre des correctifs : meterPowerSign() reste juste mais
n'est observable qu'une fois celui-ci appliqué — corriger le signe d'un
dénormal ne produit rien.
solarEdge force déjà big endian de son côté et le générique garde son paramètre
utilisateur : aucun des deux chemins n'est touché. test_AC_18 fige le
raisonnement plutôt que la seule valeur. Voir DIVERGENCES.md D-8.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le garde de présence batterie demandait isFroniusChild(thing->id()), qui
résout le parent par myThings().findById(). Pendant le setup initial la
connexion n'est pas encore enregistrée : la recherche répond faux, le garde
est contourné, et l'enfant storage est créé alors qu'InBatV et StorAval sont
nuls. Constaté en boucle fermée sur le simulateur, avec la trace nymead
"Invalid parent thing id ... Not adding thing to the system".
Le garde interroge maintenant directement le thing de connexion que la
fonction tient déjà. Le signe compteur passe de même par le parentThing déjà
résolu, dont la non-nullité est garantie quelques lignes plus haut.
La suite logique ne pouvait pas attraper ce défaut : elle couvre la décision
pure, pas le câblage. Consigné en D-7.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
L'antidote AC-16 triphasé verrouille le chemin réellement emprunté par le
matériel terrain, reproduit sur le simulateur en profil Symo (onduleur
modèle 103, compteur modèle 203) : compteur à -500/-100/-100 W, que le
plugin etm6 rapportait en +500/+100/+100.
tools/read-model124.py relève en lecture seule le bloc storage d'un
onduleur, sans aucune dépendance à installer. Il sert à lever D-6 : le côté
« batterie présente » du discriminateur reste inféré faute d'un GEN24 équipé.
Sur le simulateur il montre pourquoi ni le SoC ni les consignes ne peuvent
servir de discriminateur : le bloc annonce un SoC de 50 %, un statut Holding
et WChaMax à 10 kW alors qu'InBatV et StorAval sont nuls.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deux défauts constatés sur le GEN24 des beaux-parents (Primo GEN24 3.0,
Smart Meter TS 65A-3, sans batterie).
Signe du compteur. onMeterBlockUpdated() négociait le signe de tous les
modèles compteur sans distinction de fabricant. Sur Fronius la négation est
fausse : le Smart Meter émet déjà dans la convention nymea. L'onduleur étant
monophasé, il sert de référence de direction : le plugin rapportait la phase
portant l'onduleur en soutirage et les deux autres en injection, ce qui est
impossible sans source. L'arbitre en concluait « Surplus insuffisant
(-842 W) » et laissait chauffe-eau et PAC éteints en plein export.
La décision vit dans FroniusRules::meterPowerSign() et n'est annulée que sous
une froniusConnection. Les vendors generic et solarEdge sont inchangés, ce
qu'un antidote verrouille. Les compteurs d'énergie sont corrects et ne sont
pas permutés.
Batterie fantôme. Un GEN24 hybride publie le modèle 124 sans batterie câblée,
d'où un enfant storage bloqué sur batteryCritical.
FroniusRules::hasBattery() exige une grandeur physique non nulle (InBatV ou
StorAval), le SoC étant écarté car 0 % ne se distingue pas d'une batterie
vide. Le côté « batterie présente » reste INFÉRÉ : voir D-6, à valider sur un
GEN24 équipé avant tout déploiement.
Suite logique : 50 tests verts, dont six antidotes AC-16 et AC-17.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Records the new nymea-plugin-sunspec-etm01 binary package, the Fronius
vendor it carries, the storage setpoint corrections and the added
Build-Depends. The previous entry described an unrelated abbterra fix,
so the package would have shipped under a version that never mentioned
it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The plugin was added to PLUGIN_DIRS by the vendoring commit but never
packaged, so dh_missing found its .so in debian/tmp with nowhere to go
and aborted the whole source package: no .deb at all came out of
experimental-silo, not even for the four unrelated plugins.
Declares the binary package and adds libnymea-sunspec-dev to
Build-Depends. Upstream does not need that dependency because it builds
libnymea-sunspec from the same source tree; this repository vendors only
the plugin and links against the installed library.
Named with the -etm01 fork suffix rather than the upstream name, which
our own repository already publishes in stable and testing as a mirror
of 1.15.2. Same file path and same pluginId, hence Conflicts, Replaces
and Provides against nymea-plugin-sunspec so the two can never be
installed side by side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
experimental-silo feeds powersync-nightly and landing-silo feeds
powersync-testing, not the other way round. DEPLOY.md in the deploy
repository is the source of truth and says so in two places: its channel
table and its infrastructure inventory, where the core forks are named
etm-nymea-nightly for experimental-silo and etm-nymea-testing for
landing-silo.
Three places carried the labels backwards, all introduced by 30b58db
this morning: the diagram, the sentence on reverting a merge that breaks
the nightly, and the promotion channel list.
The order of the chain itself was already right and is untouched, as is
everything else in the document.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Building against a local sysroot rather than an installed
libnymea-sunspec-dev left the resulting binaries unable to find
libnymea-sunspec1 at run time: the sysroot is not in the dynamic
linker's cache, so -L alone is not enough and every test had to be
launched through LD_LIBRARY_PATH.
Only the NYMEA_SUNSPEC_PATH branch is touched. The package build resolves
the library through pkg-config and gets no rpath, as before.
Verified both ways: with NYMEA_SUNSPEC_PATH the binary carries a RUNPATH
to the sysroot, resolves libnymea-sunspec1 there and runs its 44 tests
with LD_LIBRARY_PATH unset; without it, no sunspec rpath is generated at
all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The chain climbs experimental-silo, then landing-silo, then main: a
change is attempted in testing before it becomes a nightly candidate for
stable. The document had the two silos the other way round, which is how
the Fronius work ended up one rung below stable while it had only ever
been verified against the bench simulator.
Corrected in the diagram, the promotion criteria, the fix table and its
downward path, the packaging channel list and the agent rules. The
channel each branch feeds is unchanged: experimental-silo is testing,
landing-silo is nightly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Where it should have landed in the first place. A change climbs the
chain: experimental-silo first, landing-silo once a nightly has proven
itself, main last. The previous merge put this straight into
landing-silo, one rung below stable, for work only ever verified against
the bench simulator and never on hardware.
Carries what landing-silo had wrongly received: the vendored SunSpec
plugin and the Fronius multi unit ID support, the three abbterra commits
the branch dragged in from the abbterra TCP line, and the two AGENTS.md
commits.
landing-silo goes back to main in the next step; nothing is lost, it all
lives here now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two points the document got wrong. The stable branch is main, not
master: the remote has never had a master. And the promotion chain was
written as if it existed, while landing-silo and experimental-silo were
created only today, the first as empty branches off main.
Nothing else in the document is touched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Committed verbatim from the working tree, where it had been sitting
uncommitted. Written by Patrick, not by the agent: this commit only puts
it under version control so the promotion chain it describes can be
corrected against reality in the next one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
First content of the promotion chain. Brings the vendored SunSpec plugin,
the Fronius vendor and its multi unit ID support: one froniusConnection
thing now carries two SunSpecConnection objects, inverter and Smart Meter
on separate unit IDs behind the same host and port.
Verified before merging: 60 offline tests green, plus 8 green against the
bench SunSpec simulator in froniusgen24-sunspec mode.
Note: the branch was cut from the abbterra TCP line, so this merge also
brings three abbterra commits that were never in main.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The suite captured a stack local of initTestCase() by reference in two
lambdas that outlive it. Once the function returned they wrote into a
stack slot reused by later frames, corrupting the running test: a
QSignalSpy reported a phantom emission, reading its recorded arguments
segfaulted, and the count changed when unrelated locals were added. Both
observed failures came from that, not from the plugin. The two flags are
members now.
Covers the two remaining claims the offline suites cannot reach: a meter
slave ID of 0 opens no second connection against a real device, and
losing the meter connection leaves the parent connected and the inverter
data flowing, marking only the meter child disconnected.
That last test drives one explicit block read first. This bench replaces
the plugin timer with a null object, on purpose, so nothing would
otherwise ever mark a child connected and the cut would prove nothing.
Run against the bench simulator: 8 tests, 8 green. Each of the two
corrections was confirmed able to fail by reintroducing its pre-F3 form.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The whole point of keeping the meter connection in a hash of its own was
that not a line of the generic and solarEdge vendors would change.
Checks it rather than claiming it: a stored solarEdge connection, whose
behaviour no suite covered until now, must still end up with exactly one
connection, as must a generic one.
Also records the connection a discovery came from in
processDiscoveryResult() rather than in the discoveryFinished handler.
The initial setup calls it from a second handler on the same signal, so
recording it there made the orphan sweep depend on the order Qt happens
to invoke the two.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
processDiscoveryResult() makes child things disappear when their model
is no longer announced. It used to confront them with the models of the
one connection that had just finished discovering, which is only half of
the picture on a thing carrying two: the inverter discovery would delete
the meter child, and the meter discovery the inverter and storage ones,
on every single reconnect.
The sweep now waits for every connection of the parent to have reported
a successful discovery, then confronts the children with the union of
their models. A grace period releases it if a connection never reports,
so a hung discovery cannot freeze the cleanup for good.
That grace period is inferred, not measured: it is set generously
because sweeping too late leaves a stale child showing as disconnected,
while sweeping too early deletes a thing of the user. Recorded as D-2 in
DIVERGENCES.md with what to measure to replace it.
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>
Takes the slave ID as an argument instead of reading it from the thing,
and takes whether it is the primary connection of that thing. Only the
primary one follows the network monitor, writes the connected state of
the thing and lands in m_sunSpecConnections; a secondary one lands in a
hash of its own.
Child things are updated per connection rather than per parent, resolved
from the model each child is bound to. With a single connection that is
every child of the parent, so nothing changes here yet.
No caller creates a secondary connection at this point: behaviour is
unchanged for all three vendors.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A GEN24 answers for the inverter on one unit ID and for the Smart Meter
on another, behind the same host and port. Isolate the decision to open
that second connection as a pure function, so it can be pinned down
without nymea, and leave the logging of the refusal to the caller.
Refuses a meter slave ID out of the 0..247 range, treats 0 as "no meter
on this connection" as documented, and refuses a meter slave ID equal to
the inverter one: a second socket on the same unit ID would rediscover
the very same models and duplicate every child thing. That last case is
reachable, since the discovery writes the scanned slave ID into the
thing parameter.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
AC-7 asks for the meterSlaveId parameter to be advanced. That property
does not exist on nymea 1.15.2 param types: the metadata verifier
rejects unknown fields, so adding it makes the whole plugin fail to
load rather than merely hiding a parameter.
Measured by loading the plugin JSON, with and without the flag, into a
PluginMetadata linked against the installed libnymea, rather than read
from an upstream tree that may differ from the package.
Also records the three other divergences the multi unit ID work runs
into, two of which predate it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
setupThing() only knew about sunspecConnection and solarEdgeConnection, so a
froniusConnection thing fell into the final Q_ASSERT_X. In a release build the
assert is compiled out, setupThing() returns without calling info->finish(),
and the pairing hangs until the setup times out - with no message at all. In a
debug build nymead dies on the assert instead.
Take the same branch as the two vendors that already work: createConnection()
already reads the slave ID and picks the byte order for froniusConnection, so
no new logic is needed.
postSetupThing() and thingRemoved() are unchanged on purpose. The former only
special cases solarEdgeConnection, for the battery search a Fronius must not
run, and registers the refresh timer for every thing. The latter is keyed on
m_sunSpecConnections, which createConnection() now populates for Fronius as
well.
Makes the four cases of tst_sunspecplugin pass.
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>
Adds a fronius vendor and a froniusConnection thing class alongside the
generic sunspec and solarEdge ones, following the SolarEdge mechanism but
none of its workarounds - no proprietary battery block and no PV
production computed by difference, since the GEN24 exposes model 160.
FroniusRules holds the vendor decisions as pure functions:
- discovery only keeps devices announcing Fronius as manufacturer;
- the byte order is the SunSpec default, not the forced big endian that
is specific to SolarEdge, and no endianness parameter is exposed;
- meterSlaveId defaults to 200, 0 meaning no meter on this connection;
- a hard 7 s floor on the poll interval. Polling faster can push the
inverter offline towards the vendor portal, and recovery needs an
AC+DC power cycle on site, so this is a guard in the code rather than
a configurable default;
- the registers the inverter accepts and then silently ignores are
refused before anything reaches the wire;
- the six HEMS battery modes map onto ChaGriSet, StorCtl_Mod, InWRte and
OutWRte, negative meaning charge;
- model 160 blocks are classified by IDStr, never by index: on a three
or four MPPT inverter the battery blocks are not in position 3 and 4.
Storages under a Fronius connection default revertTime to 300 s.
Setpoints now reread the scale factor before writing and read the written
registers back afterwards, reporting a mismatch through a new
controlHealthy state - the only defence against writes that are accepted
and then ignored without a Modbus exception.
Byte order and the revert timer semantics on model 124 are inferences, not
measurements; see specs/fronius-sunspec.md, H-2 and H-3.
setInOutWRteRvrtTms() existed but was never called. InOutWRte_RvrtTms is
the delay after which the inverter drops the setpoint and resumes its
native behaviour. Left at 0, a setpoint stays active indefinitely, HEMS
stopped, network lost or process crashed included - the battery stays
where the last command put it.
Add a per-thing revertTime parameter, 0..28800 s, defaulting to 0 so the
generic vendor keeps its current behaviour, and route every setpoint
through SunSpecStorageLogic::planSetpoint(). The plan orders the writes -
ChaGriSet, StorCtl_Mod, then the rates - and appends the revert timer
last, so the timer never starts counting against a setpoint that has not
been written yet.
Writes are issued sequentially rather than in parallel: the order is part
of the contract with the hardware.
onStorageBlockUpdated() fed chargingRate from wChaGra() and dischargingRate
from wDisChaGra(). Those are the gradients, in percent of WChaMax per
second, and read only on several inverters. The matching actions write
InWRte and OutWRte, in percent of WChaMax. The user wrote one quantity and
read back another.
Feed the two rate states from inWRte() and outWRte(), and keep the
gradients under names that cannot be mistaken for setpoints:
chargeGradient and dischargeGradient, read only.
enableDischarging was never reconciled either, while enableCharging was.
It stayed frozen on the last written value and drifted silently as soon as
the inverter changed StorCtl_Mod on its own. Reconcile both flags.
The mapping moves into SunSpecStorageLogic so it can be exercised on a
register dump without a running nymea.
chargingRate and dischargingRate map onto InWRte and OutWRte of model 124,
which are int16 setpoints ranging from -100.00 to +100.00 percent of
WChaMax. Declaring them as 0..100 makes a forced charge structurally
inexpressible: nymea rejects the negative action parameter before it ever
reaches the plugin.
Also fixes the default value, which was the boolean false on an int state.
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.
AC-1..AC-4 are the four upstream anomalies of the generic sunspec vendor
(setpoint range, read/write mismatch on the rate states, enableDischarging
never reconciled, revert timer never written).
AC-5..AC-15 are the Fronius-specific behaviour: manufacturer filter, byte
order, connection parameters, polling floor, forbidden writes, the HEMS
intent to register table, scale factor reread, readback verification and
the model 160 block classification.
Points the design contract leaves open are recorded as explicit working
hypotheses (H-1..H-6) rather than blocking on them.
Vendor the sunspec plugin into this repo so the Fronius work and the
upstream storage fixes can live here. Sources only: build artefacts and
generated plugininfo headers are excluded.
libnymea-sunspec is deliberately NOT vendored - the plugin must stay
rebasable on upstream nymea, so it links against libnymea-sunspec-dev.
sunspec.pri resolves it via pkg-config, with a NYMEA_SUNSPEC_PATH
override for a local sysroot, mirroring modbus.pri.
See sunspec/VENDORED.md.
Follow-up to the etm1 fixes, driven by live debugging against a real ABB
Terra AC 7 kW behind a Waveshare RS485->TCP gateway (192.168.1.132, slave 2):
- etm3: disable TCP auto-discovery (createMethods = "user" only). Discovery
blind-scans the LAN and SIGSEGVs nymead as soon as any Modbus device answers
:502 with an exception response. The crash is in the generated reachability
handler (abbterramodbustcpconnection.cpp:2062 dereferences the check-reachable
reply after it is freed); it could not be fixed from the discovery code alone.
A gateway's slave id can't be discovered anyway, so manual add is required.
- etm2: still defer/guard AbbTerraTcpDiscovery::cleanupConnection() teardown
(kept for correctness even though discovery is now off by default).
- etm4: setupTcpThing() never called connectDevice(), so manual setup hung until
timeout. Start the connection when the network monitor reports the device.
- etm5: decode the serial-number and firmware register fields as BCD per ABB
spec §5.1 (0x46 = week 46, not 70; 0x22 = 22 kW). The binary reading rejected
real chargers ("does not match the ABB Terra AC Modbus register map").
Verified end to end: charger adds cleanly (TACW7-4-4624-S0034), states poll and
actions execute, no SIGSEGV. The underlying discovery/generated-code crash is
tracked separately.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two coupled fixes so the ABB Terra AC can be added over Modbus TCP:
- Restore checkReachableRegister ("serialNumber") in the register JSON.
The libnymea-modbus 1.15 code generator *requires* it — without it the
connection classes (abbterramodbustcpconnection.h) are never generated and
the plugin fails to build. Reverts the false lead in b23a9a2. The register
is valid: mbpoll confirms holding reg 16384 (uint64) responds at slave 2.
- Fix a use-after-free in AbbTerraTcpDiscovery::cleanupConnection() that
SIGSEGV'd nymead during network discovery whenever any Modbus device on the
LAN answered on :502 with an exception (e.g. "illegal data address"). The
method is invoked from several of the connection's own signals; it now
bails out on the second (re-entrant) call and disconnects the connection's
signals before disconnectDevice(), so the teardown can no longer re-enter
while the QModbusReply "finished" handler is still dereferencing the reply.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The status block (12 registers × 2 words = 24 words) was read as a
single Modbus request, producing a 53-byte response that overflows the
RT38B01 433 MHz radio module's 31-byte frame limit.
Dissolve the status block into individual registers with
readSchedule:update so queuedRequests sends them one at a time
(max 9 bytes per response). The deviceInfo init block (8 words → 21
bytes) is left untouched.
Bump to 1.15.0+etm6.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
reachableChanged(true) never fires within the nymea setup timeout when
the RTU link is slow (e.g. 433 MHz radio relay). Add a fallback:
trigger initialize() immediately if master is already connected
(QTimer::singleShot 500 ms), and also on master::connectedChanged.
The existing reachableChanged path is kept for TCP-style RTU adapters.
Bump to 1.15.0+etm5.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
