When deserializing data in connectors (KNX, MQTT, etc.), there's currently no way to access RuntimeContext to generate platform-independent timestamps or access other runtime services.
For example, when receiving KNX telegrams, we'd like to timestamp them using ctx.runtime().now() during deserialization, but deserializers only receive data: &[u8].
Current Limitation
// Current API - no context available
.with_deserializer(|data: &[u8]| {
records::temperature::knx::from_knx(data, "9/1/0")
})
Monitors have context access, but deserializers don't.
Proposed Solution
Add a context-aware deserializer option:
.with_deserializer_context(|ctx, data: &[u8]| {
let mut temp = records::temperature::knx::from_knx(data, "9/1/0")?;
temp.timestamp = ctx.runtime().now(); // Platform-independent timing
Ok(temp)
})
This would enable:
- Platform-independent timestamps during deserialization
- Access to logging for deserialization diagnostics
- Consistent timing across Embassy and Tokio runtimes
Workarounds Attempted
- Setting timestamps in monitors works but complicates data flow
- Using
Debug formatting on Instant works but is hacky
- Deserializers can't access context, making proper timestamps difficult
Would appreciate this feature to keep deserialization logic clean and platform-independent!
When deserializing data in connectors (KNX, MQTT, etc.), there's currently no way to access
RuntimeContextto generate platform-independent timestamps or access other runtime services.For example, when receiving KNX telegrams, we'd like to timestamp them using
ctx.runtime().now()during deserialization, but deserializers only receivedata: &[u8].Current Limitation
Monitors have context access, but deserializers don't.
Proposed Solution
Add a context-aware deserializer option:
This would enable:
Workarounds Attempted
Debugformatting onInstantworks but is hackyWould appreciate this feature to keep deserialization logic clean and platform-independent!