How to get the current time from the CSA Matter SDK on espressif ESP32 - arduino

My understanding of the CSA Matter (aka project CHIP) spec (11.16) seems to indicate that nodes on the Matter fabric will sync the current time using the TimeSync cluster service.
If true, it seems like there should be a way to use Matter to get the current real time from within my app code. The Matter SDK includes various headers and functions for dealing with time. SystemClock().GetClock_RealTime() seems promising, but when I call it I only seem to get the number of microseconds since device boot rather than the real time. ToTimeval() in the same header also seems promising to convert to a timeval, but that declaration is not defined on ESP32, at least on my version.
I'm using the jakubdybczak/esp32-arduino-matter Arduino port of the Espressif Matter SDK.
I also tried accessing the time service on Node 0, but the returned attribute is always null:
endpoint_t *root_endpoint = endpoint::get(node,0);
esp_matter::cluster_t *time_cluster = cluster::create(root_endpoint,TimeSynchronization::Id, CLUSTER_FLAG_CLIENT);
// in this example I'm looking at timezone, but the same thing happens for LocalTime::Id
attribute_t *timezone_attribute = attribute::get(time_cluster,TimeSynchronization::Attributes::TimeZone::Id); // always NULL
esp_matter_attr_val_t timezone_value = esp_matter_invalid(NULL);
attribute::get_val(timezone_attribute, &timezone_value);
What is the proper way to use Matter to get the current real time?

Related

What should be passed in the timingCompatibility variable of the findsequence2 API?

I'm trying to use this API : https://wps.hereapi.com/v8/findsequence2
(documentation here https://developer.here.com/documentation/routing-waypoints/api-reference.html)
This variable : timingCompatibility (string)
is proposed but undocumented.
What should be passed in it?
What is its purpose?
I am trying to delay the departure of a car/truck to match first opening time on my sequence, I thought it might help but tried a a few values without success yet.
Setting timingCompatibility=true enforces WSE to synchronize with the travel times of the Router (WSE uses the Matrix-Router by default). The travel times are cross-checked after the sequence has been established and there will be no influence on the order of the waypoints. It is intended to have precisely consistent timings between WSE and the subsequent usage of Router (V7.2). My expectation is, that this parameter will not be necessary anymore with the migration of WSE to use Matrixrouter V8. This migration is progress.

Finding calling site of instrumented system calls

In my pintool, I check NtReadFile() and NtCreateFile() system calls using the PIN API:
PIN_AddSyscallEntryFunction()
PIN_AddSyscallExitFunction()
But the outputs seems to be polluted with many unexpected additional interceptions, I would like to filter out.
Problem is, the SYSCALL_ENTRY_CALLBACK functions do not let you access to information needed to deduce from where the system call has been spawned (calling site), even at the entry. Checking the value of REG_EIP (address of the instruction pointer) juste before the system call is executed, I see I am way off the calling site (out of the address range of the image I am instrumenting, although the system call is made within this image).
I also tried to instrument instructions with INS_IsSyscall() at IPOINT_BEFORE and check it's address, but it seems it is too late too (out of range of the image's low and high addresses)
What would be the correct process to instrument only system calls starting from the image I am instrumenting ?

Detect silence while playing sound

I am developing an java-asterisk application that is calling subscribers to deliver messages. At some moments during the call, I need to monitor whether the subscriber is talking or is silent. I need to monitor that for a fairly long time (1-3 seconds) but don't want to interrupt the flow of the outgoing message.
The way I am doing it now is as below
streamFile(*file A*);
exec("WaitForSilence","300,1,1");
waitStatus=getVariable("WAITSTATUS");
streamFile(*file B*);
This works fine but it is only a 300ms detect and a 1s timeout, so from the subscriber point of view the silence between file A and file B is almost unnoticeable. But if I want to listen for longer (say 3 seconds for example) then the subscriber's experience will be ruined.
What I would need is a function similar to "WaitForSilence" but that:
runs in parallel to the script;
delivers its outcome in a variable channel with a name that I define (as there might be several calls to the function, and I need to get all the results)
I've been looking for more than aweek now and couldn't find a way to do that. Any ideas?
Code you provided will do wait, after that will do playback.
There are no way do that simple in one application.
Posible ways:
1) create c/c++ application(asterisk guru skill required) for that.
2) create enother channel, mix it with ChanSpy and in that channel do silence detect. Complexity - expert in asterisk.
Both are not so short(more then 2-3 screens of code), so can't be described in this site.
You can also try use Background application, but i am afraid it will not work too.

The operation could not be performed because the filter is in the wrong state GetCurrentBuffer

The operation could not be performed because the filter is in the wrong state
I am getting this error when attemting to run hr = m_pGrabber->GetCurrentBuffer(&cbBuffer, NULL);.
Strange part is - it initially worked when I stopped the graph, now it fails on running or stopped graph.
So - what state it should be in??
The sample grabber code in MSDN I copied does not say if the graph should be stopped or running to get the buffer size - but the way it is presented the graph is running. I assume the graph should be running to fill the buffer, but I am not getting pass the sizing the buffer.
The graph is OK, all filters are conncted and renders as required, in may app and in GraphEdit.
I am trying to save the captured still frame into bitmap file so I need the capured data in the buffer.
Buffering and GetCurrentBuffer expose you a copy of last known media sample. Hence, you might hit conditions "no media sample available yet to copy from" and "last known media sample is released due to transition to stopped state". In both cases the request in question might fail. Copy data from SampleCB instead of buffered mode and this is going to be one hundred percent reliable.
See also: ISampleGrabber::GetCurrentBuffer() returning VFW_E_WRONG_STATE
Using GetCurrentBuffer is a bad idea in most cases. Proper way to use sample grabber is by setting your callback and receiving data in SampleCB.

IMediaControl::Run followed by IMediaControl::Stop followed by IMeidaControl::Run doesn't switch on certain Onboard cameras

I have a DirectShow webcam application. I make use of Sample Grabber to get the buffer callbacks and IVideoWindow to control the display co-ordinates for the Preview. I have Preview and Capture Streams which I run as below.
g_pBuild->RenderStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video,cam,g_pGrabberF,pNullRenderer2); g_pBuild->RenderStream(&PIN_CATEGORY_PREVIEW, &MEDIATYPE_Video,cam,NULL,NULL);
On certain On board cameras, IMediaControl::Run followed by IMediaControl::Stop followed by IMediaCOntrol::Run doesn't switch on the camera.
Extenal USB cameras work properly here. How can I diagnose more on this? Any pointers, please help.
Maybe its specific to a certain hardware issue in the unit.
Do a quick test by adding sleep of 1 sec between calls.
If it does help than you need to find a way to know when to unit state in idle or not.
There are two important parts of the question which you did not provide:
Filter graph topologies
HRESULTs of the method calls
A problem you might be having is that one of the filters in the topology does not handle well state transitions and fails somewhere between states. Supposedly your second Run meets it still trying to complete Stop. You might get a HRESULT there which indicates the issue (better for you) or the filter fails silently.
The filter graph's is the unlikely source of the bug itself. Chances are high that it does everything flawlessly, however since internally it distributes the calls between filters, one of the filter is letting you down.

Resources