Hi Matthias,

I should have clarified that there will be multiple unconnected LAN’s. There 
are no persistent readers available at the individual sites (until a phone is 
turned on or an appliance is turned on, sort of like an optional thermostat 
that can measure temperature in a gauge and be replaced with a smart thermostat 
which can trend.)

As a practical example, I have an inverter which transmits voltage and current 
over a Bluetooth connection, receives only when the app is running, only at a 
particular location, the app is clunky, uses gauges, does not offer line 
graphs, but there is a lot of potential in the concept. I use it only during 
power outages. I need to review the stats even less often.

Are you sure collectd would queue UDP multicast until all readers are available 
& responding with acks?

I could not quite find that behavior in the docs, I may have missed it. That 
would not meet my use case for telemetry, if that is the case.

To be frank, I never imagined a UDP multicast performance data collection & 
transport would queue until ack… in my mind, that’s like expecting DirecTV 
boxes to send acks before broadcasters send the next frame. Performance data & 
live audio/video streams are normally tolerant of loss. SNMP theory argues 
performance monitoring should be the lowest on network priorities & least heavy 
of protocols when monitoring devices. (I know this is not SNMP.) I certainly 
don’t want the embedded system running out of RAM because my phone is 
disconnected, I don’t need history beyond the time I leave my phone on for.

I am in need of something very small & light to quickly collect & transmit 
telemetry to guest readers, where simple readers can be added & removed & 
upgraded painlessly, some using gauges, others using graphs. 

It is sounding like it might be better for me to just get an X Windows emulator 
for my phone and use something like XDM with an series of X Apps readers 
positioned by X-Y coordinate on an automatic pop up root screen or a choice of 
root screens (for multiple telemetry feeds) while on the LAN, to provide 
something closer to a zero-administration telemetry appliances? (X worked for 
the airplane telemetry & diagnostic equipment… I was just hoping collectd could 
be lighter on the embedded system in my project and simpler to set up.)

Thanks, DavidH
PS over the past 15 years, people refer to this as “collected” (what the tool 
might have done for old data), auto-correct mangled it, others mis-read it, 
others search for “collected”, writing it as the first word in a sentence Is 
awkward in documentation using all lower case, so all lowercase generally 
creates a problem with communicating concisely. Since most search engines are 
case insensitive, when I used CollectD in docs & conversations, those issues 
are quickly resolved when they type in what they remember, capitals is more 
memorable with newbies, more easily pronounceable when communicating only in 
text, and the capitals accentuate what seems to be it’s core identity & 
functionality: Collect Daemon

Sent from my iPhone

> On Jul 16, 2021, at 5:05 AM, Matthias Runge <mru...@matthias-runge.de> wrote:
> On Fri, Jul 16, 2021 at 01:30:45AM -0400, DavidHalko wrote:
>> Hello CollectD List!
>> I am interested in using CollectD on a LAN, but would like to use the 
>> MultiCast Network output to transmit to whatever real time readers may 
>> appear, capture, and graph the output.
>> In particular, I would like to connect my iPhone to the LAN, run a CollectD 
>> receiver, just start receiving data, and have my iPhone start producing 
>> graphs based upon the data observed.
>> Is there an iPhone CollectD MultiCast Network Receiver, basic logger, and 
>> basic time-series or gauge grapher?
>> I am thinking about functionality similar to “perfmeter” on old SunView or 
>> OpenWindows workstations, but eliminating the workstation part since I have 
>> a phone in my pocket, and trying to simplify usage for collectd on 
>> appliances forwarding telemetry.
>> The use case: IoT appliances are collectd enabled & dumping telemetry on 
>> multicast, I start start up an iPhone app, view graphs in real time from 
>> what is seen over multicast, determine health of IoT items, discard data as 
>> I shut off the app, I don’t want any knowledge of IoT objects outside the 
>> LAN (no web sites, no usernames, no passwords, maybe MAC Address or serial# 
>> or appliance name, just Appliance sensors & IoT health on my LAN.)
>> Thanks! DavidH
> Hi DavidH,
> I'd go with a setup where collectd is sending metrics via network to a
> central location, that can be a prometheus for example (which is pulling
> for metrics, to be exact).
> You could then use your device of choice to visit that site.
> Collectd is has a list of write targets, and if the write did not
> succeed, it will try again. Until this is successful, it stores the
> metrics (by default).
> prometheus runs fine on even small devices.
> A side remark: collectd never spelled with an upper-case 'D' at the end.
> Where did you read it that way?
> Matthias
>> Sent from my iPhone
> -- 
> Matthias Runge <mru...@matthias-runge.de>
> _______________________________________________
> collectd mailing list
> collectd@verplant.org
> https://mailman.verplant.org/listinfo/collectd

collectd mailing list

Reply via email to