Extension of #8746 :
I have tried to set the precision in the config file as seconds. But as i write data and tries to fetch it its again showing Nanoseconds timestamp.
I read the whole Doc but couldn't figure it out
only change in my config file is: precision = "s"
help me understand these things
How do I set the precision at DB level and how will I make sure I only get set precision timestamps in epoch. And I am using IST as timezone for my Application so also tell me how to set the same for InfluxDB in configuration
I am using python-influxdb client seriesHelper to write data into db and not specifying any time while writing data.
Edit: Added a pull request to resolve this in influxdb-python SeriesHelper Class - #502
Set query parameter epoch=s. See docs.
Query parameters are already supported by influxdb-python, for example:
client = InfluxDBClient(<..>)
client.query(<..>, params={'epoch': 's'})
Related
I'm trying to log to file / seq an event that's an API response from a web service. I know it's not best practice, but under some circumstances, I need to do so.
The JSON saved on disk is around 400Kb.to be honest, I could exclude 2 part of it (that are images returned as base64), I think I should use a destructured logger, is it right?
I've tried increasing the Seq limit to 1mb but the content is not saved even to log file so I think that's not the problem...I use Microsoft Logging (ILogger interface) with Serilog.AspnetCore
Is there a way I can handle such a scenario?
Thanks in advance
You can log a serialized value by using the # format option on the property name. For example,
Log.Information("Created {#User} on {Created}", exampleUser, DateTime.Now);
As you've noted it tends to be a bad idea unless you are certain that the value being serialized will always be small and simple.
I am pretty new to Cumulocity and I am trying to get data into the platform from my own device using mqtt and the smartrest templates. I can get data in using the static templates but they only support certain data types. I am struggling to create the appropriate smartrest template in the UI and the documentation doesn't go into much detail.
I get that the template name goes in the MQTT topic (or selected on login as part of the username) in s/ut/template_name and the messageId of the messages in the template get matched to the first CSV field of the MQTT publish payload. What I don't get is the template terminology. In the UI I choose API->Measurement and Method->POST and I am presented with required values $.type and $.time. My questions:
Is $.type the "measurement fragment type" name or do I have to make it "c8y_CustomMeasurement"? Can I call it whatever I want?
$.time has a value field. Is this the default value if one is not supplied in the publish?
I assume I need to add a numerical value in the optional API values. To link it to the value of the data point should I make the key "c8y_CustomMeasurement.custom.value"?
Am I way off base here?
Every time I publish to my own smartrest template the server drops the connection so I assume its an error in my template setup but I don't see a way of accessing debug messages (also nothing is published back to me on s/e or s/dt).
For the sake of an example, lets say I wish to publish a unitless, timestamped pulse count with payload format "mId,ts,value" with example data "p01,'2017-07-17 12:34:00',1234"
What you wrote so far is mostly correct just to be a bit more precise:
The topic is s/uc/template_id (not the template name, this is just a label)
The $.type refers to the 'type' fragment in the measurement JSON. It is a free text field
In 99% of cases you want to leave the $.time empty. If you set something here it is not the default but fixed to that timestamp and you cannot change it when using the template. If you leave it empty and still not send something in
Example: p01,2017-07-17T12:34:00,1234 (no quotes arounf timestamp and ISO8601 format
Example without sending time: p01,,1234 (sending empty string as time results in server time beeing set. The template is the same)
Hope these points help you to find you issue
I have a datetime value which comes from the API in this format: 2015-07-07T17:30:00+00:00. I simply want to split it up between the date and time values at this point. I am not using an Active Record model and I prefer not to use an sql database if I can.
The way I have set up the app means that the value is "stored" like this in my view: #search.dining_date_and_time
I have tried two approaches to solving this problem:
Manually based on this previous stackoverflow question from 2012: Using multiple input fields for one attribute - but the error I get is the attribute is "nil" even though I put a "try"
Using this gem, https://github.com/ccallebs/split_date_time which is a bit more recent and seems to be a more elegant solution, but after closely following the doc, I get this error, saying my Search model is not initalized and there is no method: undefined method dining_date' for #<Search not initialized>
This is when instead I put #search.dining_date in the view, which seems to be the equivalent of the doc's example (its not that clear). The doc also says the method will be automatically generated.
Do I need to alter my model so I receive the data from the API in another way? ie. not get the variable back as #search.dining_date_and_time from the Search model for any of this to work?
Do I need an Active Record model so that before_filter or before_save logic works - so i can (re)concatenate after splitting so the data is sent back to the API in a format it understands. Can I avoid this - it seems a bit of overkill to restructure the whole app and put in a full database just so I can split and join date/time as needed.
Happy to provide further details, code snippets if required.
As I am not using a conventional Rails DB like MySql Lite or Postgresql, I found that the best solution to the problem was by using this jQuery date Format plugin: https://github.com/phstc/jquery-dateFormat to split the date and time values for display when I get the data back from the API.
The Github docs were not too expansive, but once I put the simply put the library file in my Rails javascript assets folder, I just had to write a few lines of jQuery to get the result and format I wanted:
$(function() {
var rawDateTime = $('#searchDiningDateTime').html();
// console.log(rawDateTime);
var cleanDate = $.format.date(rawDateTime, "ddd, dd/MM/yyyy");
// console.log(cleanDate);
$('#searchDiningDateTime').html(cleanDate);
var cleanTime = $.format.date(rawDateTime, "HH:mm");
// console.log(cleanTime);
$('#searchTime').html(cleanTime);
});
Next challenge: rejoin the values on submit, so the API can read the data by sending/receiving a valid request/response. (The values can't be split like this when sent to the remote service).
If I run the following command from my bitcoin console client:
bitcoind -reindex -txindex -debug=net -printtoconsole
it take extremely long to run, does this reindex all the previous bitcoin transactions ?
Here are the detail about the options you use:
-txindex: Maintain a full transaction index (default: 0)
-reindex: Rebuild blockchain index from current blk000??.dat files
-debug: Output extra debugging information. Implies all other -debug* options
It's normal that this operation takes time because txindex represent a uge amount of data and you force the bitcoin core to rebuild the blockchain from your local saves each time you run it (which is, from my experience, not necessary). My suggestion is to remove -reindex and try to figure out if you really need -txindex.
If you want to check on all the transactions related to your wallet, I think this option is more appropriate:
-rescan: Rescan the block chain for missing wallet transactions
note: this will also be time consuming
information from : http://we.lovebitco.in/bitcoin-qt/command-line-options/
Tips for faster reindexing:
Use -printtoconsole=0 (will not output anything at all to the console)
Increase dbcache from default 450 - for example, to 1000: -dbcache=1000
Quick environment overview:
I have an ASP.NET MVC/AngularJS application that is ultimately being hosted as an Azure Webrole. The data is stored in MongoDB hosted in the same Azure data center (via MongoLab). Development environment and staging environment (Azure) point to same MongoDB database and thus see the exact same data.
Issue:
Individual users of the application are stored with their preferred timezone as a string (TimezoneID). All dates in the app are stored as UTC times. Conversion to and from UTC times to a users specific timezone is done on the server via an extension method which ultimately calls:
return TimeZoneInfo.ConvertTimeFromUtc(UtcDate, _lookup[TimeZoneID]);
Nowhere in the entire app is there a DateTime.Now or any other date conversion I would expect to use the server time settings.
In a particular area of the application a date is being stored in Mongo (UTC). I can confirm that the date is correctly stored as UTC (based on the offset from my local time). When I retrieve that date from the data store and convert it back to my local time (Central Standard Time) I step over the above line of code and the conversion works fine and the local time is set. The result is sent to the client's browser as part of a Json result of an API call and displayed to the user correctly. During transport the MVC Json serializer parses the datetime into a format similar to:
EventDate: "/Date(1399407153971)/"
I parse this in Javascript and display accordingly and all is good.
When I deploy the exact same code to Azure (which points to the exact same data store in Mongo) the result that comes down via the API call appears to have applied the UTC transformation twice (meaning the regular 6 hour UTC offset is applied twice and the displayed date is 12 hours earlier than UTC...6 hours off of what I want).
I've updated the stored time in Mongo by a minute or two to make sure both sides update and they do (verifying the same data). I've modified the date/time settings of my local machine to see if it has any effect on my local results and it does not. I've changed the timezone for the selected user in the app and both my local result AND the Azure returned result adjust by the UTC offset difference between Central Standard Time and the new time zone (meaning if I switch to Mountain Time the result of both the local result and the Azure result adjust by 1 hour...but are still 6 hours off). I've confirmed via Chrome Dev Tools that the date in question that is retrieved at the client (via Json) is different based on whether the site hit was the remove (Azure) environment or local environment (meaning it isn't being modified incorrectly anywhere on the client after-the-fact)
Here is the most telling thing:
If I convert the date to a string prior to returning it to the client the string sent down appears correct in the Json response. If I leave it as a .NET DateTime type (as a property of a complex object) the Json serializer appears to translate it again but ONLY when hosted in Azure. This has pointed me to the issue being somehow related to the DateTimeKind of the date I'm returning. Although, at this point, I'm too lost in the weeks to see why the difference between my local environment and the Azure host environment in serialization and why one things a time is correct and the other converts it twice. If the DateKindTime was wrong wouldn't both environments perform the same conversion?
Thanks for reading through this and I'd appreciate any ideas to address anyone has.
It's difficult to say for sure without seeing more code, but could it be that the problem is with conversion on the way in, rather than on the way out? You said that you're using TimeZoneInfo.ConvertTimeFromUtc for the output. Are you also using TimeZoneInfo.ConvertTimeToUtc on the other side? If so, that's likely the source of picking up your local time zone.
You might also somewhere have a call to DateTime.ToUniversalTime, which again - uses the local time zone.
Another area which might be the culprit - when you retrieve your value from Mongo, check the Kind of the values coming back. If they're Unspecified, then when they are serialized to JSON, they will be treated as if they were Local. basically, there's a ToUniversalTime call going on under the hood. So you may need to explicitly call DateTime.SpecifyKind to set the value to Utc before it goes out the door.
With specific regards to Azure, it follows best practices of setting the server time zone to UTC. You could try that on your own machine and see if you get similar results.
Of course, you really don't want the server's time zone to influence the result at all.
You may want to consider creating a new project with a minimal, complete, and verifiable example. That will help you verify your assumptions, and will likely track down the source of the problem. If it still fails, well then you'll be in much better shape for asking for help.
That was a long post :)
If I were you I would transfer all dateTimes in UTC format. The server basically must work with UTC time as far as I'm concerned. Transformation to client time must be applied at clients side. You can use momentjs library that proved to be very fine library for working with dates and times.
On client side do something like this
var date = {
utc: '/Date(1399407153971)/', //time that you have recieved
offset: 240
}
var localTime = moment.utc(date.utc).zone(date.offset).format('DD/MM/YYYY hh:mm');
I hope this helps
UPD
As Matt Johnson pointed out you can make it even shorter for current time zone.
var localTime = moment('/Date(1399407153971)/').format('DD/MM/YYYY hh:mm');