@andi-tudor Can you please provide a little bit of background what kind of action you’re using. What is “Door open 2018-04-We 08:26”, please? Moreover, what kind of “dateformat” string are you using or which local applies in your setup?
-
Released pimatic-datetime@0.3.1
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Nevertheless, there seems to be something wrong. The differenceFormat is used for formatting the datetime String. If differenceFormat isn’t set the formatted variable is “unknown”.
At the moment I don’t know why. Maybe there couldn’t be multiple instances of Moment at the same time. I will check this later.
-
The calculation of all variables works totally fine. The problem is, that requesting the formatted variable by rule, device or whatever always points to the difference variable.
$datetime.formatted provides always the value of $datetime.difference. If no difference calculation is configured the result is “unknown”.
Also referring to all other variables points to the difference variable.
$datetime.unixTimestamp also gives the value of $datetime.difference. Really strange.
If I delete the “difference” logic, all variables refer to the unixTimestamp, that is the last in the attributes configuration.
@mwittig Could you please have a look? Could there be a core bug? I think it has something to do with your refactoring of the datetime plugin. The getters always refers to the last configured variable.
-
@saxnpaule said in Released pimatic-datetime@0.3.0:
@mwittig Could you please have a look? Could there be a core bug? I think it has something to do with your refactoring of the datetime plugin. The getters always refer to the last configured variable.
I think I know what it is. My fault
Will file a fix soon"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Fixed. It is classical JS problem: if you wish to use a transient object in a callback function you need to add an extra closure to keep a copy or reference to that object for.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Unfortunately not
The fix has to be done in the getter not in the setter function, or am I wrong? -
@saxnpaule Omg, you’re absolutely right and that’s also what the commit message is suggesting. I had to reset my fork as I did not properly rebase before the commit. So, I had to manually apply the changes again while doing other things at the same time (not a good idea). EDIT: I have updated the PR accordingly
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
Thanks for your help @mwittig
version 0.3.1 released 2018-04-18
- fixed getter functions to hold correct references
-
" { "locale": "en", "attributes": [], "xAttributeOptions": [ { "name": "dayOfWeek", "displaySparkline": false }, { "name": "dayOfMonth", "displaySparkline": false }, { "name": "dayOfYear", "displaySparkline": false }, { "name": "week", "displaySparkline": false }, { "name": "unixTimestamp", "displaySparkline": false } ], "echo": { "additionalNames": [] }, "id": "date-time", "name": "Date Time", "class": "DateTimeDevice", "interval": 60000, "dateformat": "YYYY-MM-dd HH:mm" } "
" When door is opened then send text telegram to Andi
"Door open 214 $date-time.formatted" " -
After update 0.3.1 everything is ok.
Thank you very much