Device Capability Reporting

[davidcutting42]

From #66 - Add a command to JMRI and the CS to report a list of device capabilities (devCaps structure

[mstevetodd]

Can someone flesh out or link what is meant by "devCaps structure"?
I'm wondering if this approach could also be used by WiThrottle clients to help client and server understand each others' capabilities?

[grbba]

Do you think about device capabilities e;g ram available / speed in Mhz etc or application level capabilities like i understand commands for throttles but not turnouts ? I can handle x locos or even things like the loco table at any given point in time ?

[habazut]

Capabilities that can be interresting for the higher level program, for example JMRI. # of slots is one such capability. Has RailCom feedback another. Mhz and RAM are not interresting I think. Either it's enough or not ;-)

Harald.

[Asbelos]

Agreed.. but the problem with ram is once you run out you cant tell anyone .. so we need warnings On 22 Nov 2020 20:04, habazut <[email protected]> wrote: Capabilities that can be interresting for the higher level program, for example JMRI. # of slots is one such capability. Has RailCom feedback another. Mhz and RAM are not interresting I think. Either it's enough or not ;-) Harald. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[grbba]

Agreed on the RAM warnings indeed but well is a warning and not a capability :) The warning will ev lead to the fact that the capabilities don't work any more So we have also to think about logging/monitoring maybe a bit beyond the std Diags. I did try this a bit when working on MQTT where i have what i called a telemetry class which would take an object as the logger and in my case that was an MQ 'logger' just pushing messages to my MQClient drawing then a nice graph about RAM consumption/availability. Issue being that that costs CPU cycles / ram itself you may not want to spare Where would be the balance ?

[Asbelos]

The existing ram warning only triggers when the ram goes lower than any previous time.. so it really helps spot leaks etc. On 22 Nov 2020 21:00, Gregor Baues <[email protected]> wrote: Agreed on the RAM warnings indeed but well is a warning and not a capability :) The warning will ev lead to the fact that the capabilities don't work any more So we have also to think about logging/monitoring maybe a bit beyond the std Diags. I did try this a bit when working on MQTT where i have what i called a telemetry class which would take an object as the logger and in my case that was an MQ 'logger' just pushing messages to my MQClient drawing then a nice graph about RAM consumption/availability. Issue being that that costs CPU cycles / ram itself you may not want to spare Where would be the balance ? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[FrightRisk]

I'm trying to remember what we were talking about that led to this discussion. I'll search in discord. In my business, the capabili are related to a phone device, dialtone, dtmf, put call on hold, ability to make a transfer, etc. For us, it would be what has been mentioned and if a display is connected and what type/number of lines, motorboard? Current sense? So JMRI nd other front ends can alter status displays. Wifi connected? In other words, what kind of things would an Engine Driver want to know about btje CS and visa versa?

[mstevetodd]

Is there a defined structure for this "devCaps" somewhere? I'd like to understand the mechanism itself, knowing that we will need to discuss the specific elements to be included later.

[FrightRisk]

I wanted to use something like this as a model. It comes from the Windows API, in this case the telephony API (TAPI) which allows devices like PBXs and SIP Trunks, etc. to report what they can and can't do. We could use a simplified version of this. https://docs.microsoft.com/en-us/windows/win32/api/tapi/ns-tapi-linedevcaps