import / contact save fiddling

releasenotes/RELEASE_NOTES_1.17.7-zephcore.md

@@ -1,10 +1,10 @@
 # ZephCore 1.17.7-zephcore
 
 Faster GPS fixes on three trackers, a clock that survives a reboot, fixes for USB companions that
-could stop responding right after boot or when the port closed during a contact sync, more reliable
-detection of clock chips, repeaters that power down an external flash chip they do not use, a
-formatter that erases that chip on every board that has one, and a few fixes ported from upstream
-MeshCore.
+could stop responding right after boot or when the port closed during a contact sync, a contacts
+import that no longer stalls every few seconds, more reliable detection of clock chips, repeaters
+that power down an external flash chip they do not use, a formatter that erases that chip on every
+board that has one, and a few fixes ported from upstream MeshCore.
 
 > [!NOTE]
 > A normal upgrade keeps your identity, settings, contacts and phone pairing.
@@ -101,6 +101,15 @@ Now a reset of the USB bus ends the session, and a session on a sleeping compute
 connected app until the computer wakes. An app that keeps the port open but stops reading can still
 hold up a second app.
 
+## Companion: importing contacts no longer stalls every few seconds
+
+Importing a configuration with many contacts from the app paused for a few seconds, again and again.
+The node saved its whole contact list 5 seconds after the first change, and while the import was
+still running it saved again every 5 seconds; it answers nothing while it saves.
+
+The save now waits until 5 seconds after the last change, as in MeshCore, so an import is saved once
+when it is done. The same applies to any other run of contact changes.
+
 ## Repeaters: the external flash chip is powered down
 
 Some boards carry a second flash chip, which companions keep contacts and channels on. Repeaters,

zephcore/Kconfig

@@ -385,7 +385,7 @@ config ZEPHCORE_BLE_CONN_MAX_INTERVAL
 	range 6 3200
 	help
 	  Maximum BLE connection interval in 1.25ms units.
-	  36 = 45ms. Matches Arduino default. Higher = lower power when idle.
+	  36 = 45ms. Higher = lower power when idle.
 
 config ZEPHCORE_BLE_CONN_LATENCY
 	int "BLE connection latency (skip events)"
@@ -393,7 +393,7 @@ config ZEPHCORE_BLE_CONN_LATENCY
 	range 0 500
 	help
 	  Skip up to N connection events when idle to save power.
-	  4 = skip 4 events (effective interval up to 375ms idle).
+	  4 = skip 4 events (effective interval up to 225ms idle at 45ms).
 
 config ZEPHCORE_BLE_CONN_TIMEOUT
 	int "BLE supervision timeout (units: 10ms)"

zephcore/app/CompanionMesh.cpp

@@ -276,22 +276,19 @@ void CompanionMesh::timeSyncTick()
 
 void CompanionMesh::markContactsDirty(bool substantive)
 {
-	int64_t deadline = _ms->getMillis() +
-			   (substantive ? LAZY_WRITE_DELAY_MS
-					: LAZY_WRITE_LIVENESS_MS);
+	int64_t now = _ms->getMillis();
 
-	/* Only set the timer on first dirty — don't keep pushing
-	 * the deadline forward or a busy mesh never flushes. */
-	if (!_dirty_contacts_expiry) {
-		_dirty_contacts_expiry = deadline;
+	/* A substantive change restarts the short delay, as upstream: a burst
+	 * (a contacts import) is written once, after its last change. */
+	if (substantive) {
+		_dirty_contacts_expiry = now + LAZY_WRITE_DELAY_MS;
 		return;
 	}
 
-	/* ...but a substantive change must not have to sit out a liveness wait
-	 * that is already pending.  Pulling the deadline IN cannot starve the
-	 * flush, only hasten it. */
-	if (substantive && deadline < _dirty_contacts_expiry) {
-		_dirty_contacts_expiry = deadline;
+	/* A liveness change only arms the long deadline; it never moves a
+	 * pending one (devdocs/lld/06-companion.md). */
+	if (!_dirty_contacts_expiry) {
+		_dirty_contacts_expiry = now + LAZY_WRITE_LIVENESS_MS;
 	}
 }