My data is a series of records like so:
stamp, (epoch time LONG)
asn, (UNSIGNED INT)
probeType, (UNSIGNED SHORT INT)
responseCode, (UNSIGNED TINY INT (bool?))
result (SIGNED INT)
Im hoping to eventually run predictions and/or anomaly detection on fields 3 (responseCode) and 4 (result).
Is this the appropriate setup?
Sensor<ObservableSensor<String[]>> sensor = Sensor.create(
ObservableSensor::create, SensorParams.create(SensorParams.Keys::obs, new Object[] {"model",
PublisherSupplier.builder()
.addHeader("epoch, INTEGER")
.addHeader("asn, INTEGER")
.addHeader("probeType, INTEGER")
.addHeader("responseCode, INTEGER")
.addHeader("result, INTEGER")
.build() }));
1 Like
Hi @phil_d_cat,
I know this can be a bit confusing, but there are always only 3 lines of header (i.e. addHeader must be called 3 times). The first line has all the header fieldnames, the second line has all the header types, and the third line has special flags most commonly having a βTβ for the time column, and βBβ for all other columns. However if there is a column devoted to indicating Resets, or turning Learning on or off, then those columns can have an βRβ or βLβ depending on the function. For an example of those please see the HeaderTest.
So for your configuration, the header lines would be:
.addHeader("stamp,asn,probeType,responseCode,result")
.addHeader("datetime,int,int,int,int")
.addHeader("T,B") // No need to put in 4 of these, the framework will intelligently insert them for "Blanks"
For reference you can have a look at the FieldMetaTypes enum to see the types and the strings that are used in the headers to represent them.
Cheers!
David
Oh my. Well I entirely missed the boat on that one.
So thereβs no problem if I pass in epoch time instead of a formatted DateTime?
TY!