As part of my morning alarm routine I have TTS announce the date using the %date% string. I'm in the UK so use the European date format.
I've been using it for a few weeks and it's all been fine. Yesterday it announced "the 31st of August" correctly, but today it announced "the 9th of January".
It is now a few hours later and testing it again it has now correctly announced "the 1st of September".
Wierd!
I haven't updated or rebooted my hub in the last 24 hours and my location settings are all correct. The date format is showing ok on dashboards. The only thing I can see is that the format of the date in the current hub time is the US format, but that is now and the date is being spoken correctly now anyway.
It sounds to me like an Alexa Poly problem. The in the settings for your hub isn't dependent on where you are located. It's in "universal" format used by almost all date/time systems. YYYY-MM-dd. It's the same for me here in the US.
I work on a medical device system and all dates when sent from one system to another are translated into that date format so that both systems know exactly what the date is without having to ask the format. It also goes from Number that would change the least frequent to the number that would change the most frequent. Makes it a lot easier to sort numbers.
Do you have the %date% stored in a variable or just sent directly to TTS? Because here in the US, %date% still results in 01-Sep-2019. If yours is the same, then it isn't a Hubitat issue, that would always be formatted the same. It sounds like when Amazon Poly was creating your TTS message, it couldn't figure out what it was supposed to use so it just said what it thought it should. When i use %date% though I get "September first twenty nineteen" spoken out completely. You'rs saying you just get First September?
Mine does say the year as well for %date% which I haven't got stored anywhere, just used directly in the TTS.
When I test in now is says "The First of September Twenty Nineteen" but this morning it said "The Ninth of January Twenty Nineteen".
That is what is so wierd. It has been working fine for weeks and yesterday said "The Thirty First of August Twenty Nineteen" correctly.
I have no idea what has happened. As I said, I have changed nothing on my system between it working fine yesterday and it thinking it was in the US this morning.
And you were using Hubitat TTS (which is Amazon Poly)? I would suspect it was a futz in it rather than in Hubitat. I've never seen %date% spit out the wrong date but I've had amazon poly screw up a lot.
Yes I'm using the standard HE Speak command to a Google Mini via the Chromecast integration.
I'm annoyed because I didn't have time to look at the issue at the time and by the time I did it seems to have fixed itself and those lines were beyond the range of the past logs by about 20 minutes.
Well, if it happens again, see if you can get to it to grab the logs. But like I said, I've never seen %date% spit out something in the wrong format and I wasn't able to find any other threads about someone reporting the same thing. But how many times has Amazon Poly mispronounced something? Happens a lot.
This morning the alarm routine announced "The 9th of February Twenty Nineteen" which seems to be based on the correct date (which is 02/09/2019 in UK format) but with date and month switched. This is what it did yesterday.
However if I run a test rule to send %date% to the same speaker it announces "The 1st of September Twenty Nineteen" which is the correct format but the wrong date!! I tried the same test with another speaker (Sonos) and get the same announcement.
Something has definitely screwed up my %date% format/value and it also seems to have more than one value at the same time.
I have captured some logs this time and have also recorded the announcements on my phone to prove I'm not just cracking up! (update - can't upload the phone mp4)
Announces "It is eight forty four the 1st of September Twenty Nineteen"
I also tried the same test rule but to my Sonos speaker with the same result. This is the log for the Sonos showing the %date% as being wrong as the 1st September not the 2nd.
@bravenel. Bruce any thoughts on this? I'm tempted to just reboot to see if the problem clears, but am happy to do any tests to help identify the issues if you want me to.
But you also said that when you ran the same rule again it was correct the second time. You didn't say that you changed anything in between those two executions.
So, you changed something between event #1 and event #2?
Okay...but the first was wrong and the second was right. So, it can't be the rule then if the rule is constant between the two events, right? or am i missing something?
No. I agree I dont see how it can be anything in the rule. The rule hasn't changed since I added the date announcement to it a few weeks back and it worked fine until the change of month yesterday.
This is still happening. Today it announced ninth of March instead of third of September.
Yesterday I also added a line into a rule that runs every day at 00.05 to set a GV to the %date% value of that rule. That has set it to 09/03/2019, so %date% is now definitely getting returned in US format for some strange reason.
It seems to be in the wrong format now everywhere I test it. It's as if as the %date% values for each rule get updated with a new trigger/event they are getting updated into US format. Dashboard dates are still showing correctly
Time for a reboot do you think?
EDIT. Update a new rule created now speaking %date% works correctly so it isn't wrong everywhere as I thought. But is very odd that anything using %date% early in the day seems to be the wrong format then after around 10am it seems OK!!!! Maybe %date% just isn't a morning person!
EDIT EDIT. Bizarrely it seems there might be something in that. I have just set another GV to %date% and that is in the correct format whereas the one created at 00.05 is in the wrong format. There were both set using the exact same command "set variable to %date%"
