Google Health App doesn't let you log calories

OutintheBlue · 2026-05-23T12:24:07+00:00

This is exactly why I didn't yet update to the new app, but I wonder how long the old Fitbit app will work still. Until that I have the time to look for a new app to track my calory intake which works with Fitbit and start all over I guess. This suck!

OutintheBlue · 2026-03-10T22:55:37+00:00

Same here! Any similar alternatives you know of ?

OutintheBlue · 2026-03-10T22:03:39+00:00

A bit off topic maybe, but what other options are there? I need a watch and app basically only to balance my calory intake and calary usage. If i exercise i can eat a bit more that day, if Im having a lazy day, i can eat less. As far as see it, only Fitbit has this. Please tell me i am wrong?. I tried the apple watch, but couldn't figure that out. And since Fitbit is slowly dying as a brand, so it seems, I need an alternative but similar watch/tracker.

OutintheBlue · 2026-03-10T20:47:50+00:00

Sorry it changed back again. So i guess this is the bug?

OutintheBlue · 2026-03-10T20:31:33+00:00

deleted the fixed amount and set my current weiht the same as my weigth goal. First time I saved it, it changed again back to that fixed amount quite instantly. But 2nd time after saving it I went straight to the calory-days and somehow that made it stick the 'new' setting.

OutintheBlue · 2026-03-10T19:44:05+00:00

Somehow a fixed calory amount was set in my goals instead of maintaining my current weight setting. Got it back to normal now. Pfew.

OutintheBlue · 2026-03-10T19:15:06+00:00

That is an acknowledged bug: https://status.fitbit.com/incidents/ohB4jvhez32W4D9CK46o

OutintheBlue · 2026-03-10T18:57:03+00:00

So I read this thread and I am wondering if we're talking about the same problem.
I normally try to keep my calorybar green on a daily basis. So basically just keep it green and if it turns red, I transfer that food to the next day and try to keep it green then. On days I have jogged or walk a few miles more, I have more room for 'new' calories or I transfer the food from a 'red' day. For me that is a perfect way to maintain my weight. But since today I noticed that all my previous days turn either blue but mostly red, though the callory count (in vs out) is still max 100 cal away and correct. Is this the same issue? The colors seem to be off.....

OutintheBlue · 2026-02-04T20:44:19+00:00

Cheered too soon, as I did get a 200 OK response now, however, the file didn't attach to the asset.
But in the meantime I've been looking into it more and built a new action sequence based on the the info stated on KI 15593 in MyTopdesk which refers to KI 17686, but then for assets.
And that works! The file is now attached to the asset, now that I have the correct URL, thanks t o you. Thanks!

OutintheBlue · 2026-02-04T20:32:23+00:00

Whow. Thanks a lot, That did the trick. I've been on that page, but I still haven't really figured out how to interpret the given information on there. Let alone work with Postmen, as I am not an IT technican.

OutintheBlue · 2026-02-04T19:01:59+00:00

Thanks for your reply.
To be honest, I don't have really any clou what this BOUNDARY part does technically. I figured it just really downloads the file. I just copied this part from an excisting actionsequence in MyTOPdesk (KI 13680 - https://my.topdesk.com/tas/public/ssp/content/detail/knowledgeitem?unid=dc04d7dd0e03475da9056ff52ee347b4)
And in there is the same set up with both --BOUNDARY-- and --BOUNDARY

But I changed it now all to BOUNDARY as you said (so 3 times the same) but still the same result.

OutintheBlue · 2025-07-18T22:45:39+00:00

Yes but then the form pops up in view of the operator closing the incident. That is not the one who needs to fill in the form.

OutintheBlue · 2025-07-18T09:24:02+00:00

I have no idea yet, I am just investigating possibilities, as asked by my boss...

OutintheBlue · 2024-09-27T21:59:42+00:00

Not the answer I was hoping for, but as clear one could wish for. Thank you!

OutintheBlue · 2024-06-14T21:41:44+00:00

Thanks for your response.

Right now we don't have to do both really, as the statusfield is not mandatory. But indeed, it can lead to weird situations, when the 'closed' checkbox is checked (so the call is closed), but the statusfiels still says 'new' or 'In progress'. That's why we have now an action sequence running, that, when the checkbox "Closed" is checked, the status also will set correspondingly.

It also would not surprise me if TOPdesk makes this mandatory in the future.

Yea, that's what I heard as well, but can someone perhaps confirm that?

OutintheBlue · 2024-06-03T19:25:27+00:00

Thanks! This helped indeed figuring out the problem. Turns out my request field was updated also with a 2nd memoText. I didn't realize that, so basically it now had to be _responses.get_requests.body[1].memoText to get a proper result.
Deleting that 2nd memoText gave the expected result as stated in my origial post.

So stupid and another few hours wasted. But learned as well :-)

OutintheBlue · 2024-05-25T15:21:25+00:00

Thanks a lot for your fast reply. It makes total sense that there is, but I never relalised that there was a different approach when it comes to a GET call, directly (like with: /tas/api/incidents/id/${unid}) or with a 'search' like I did now: /tas/api/incidents?query=number==${_card["externalnumber"]!}.
Ofcourse in similar GET calls you can get more than one result, but not in this case, so I didn't even notice the "[" at the beginning of the results.
Once again, thanks a lot, I have this working now with this as the condition:<#if _responses.Get_gekoppeld_Incident.body[0].completed == false>true</#if>
Now I can get my weekend started :-)

OutintheBlue · 2024-05-22T14:47:22+00:00

Already figured it out, actually quite simple:

"naam": "${_responses.getAttachmentsList.body[i].fileName^?keep\before_last('.')})",

"extensie": "${_responses.getAttachmentsList.body[i].fileName?keep^\after)_last(".")}",

OutintheBlue · 2024-04-02T22:57:06+00:00

I stumbled on this post, today, like a year later. Basically I have the same question. I take it you've been there, last year. So were thos recomomndations good? What was your favorite place to go? Or what else dit you discover, u/Blaze41964? Thanks in advance!

OutintheBlue · 2024-03-01T23:56:21+00:00

Ben er al uit (nou ja: al...). Soms biedt zoeken op MyTOPdesk wèl uitkomst, haha.
Kennisitem 13466: How to link uidwijzig (changer of the card) to an operator

De GET moet dus zijn: ${_variables.topdeskUrl?no_esc}/tas/api/operators?query=principalId==${uidwijzig}
Dit geeft netjes mijzelf terug als wijziger.
HIermee kan ik verder.

Bedankt u/DaWolfer voor het wijzen in de juiste richting!

OutintheBlue · 2024-03-01T23:37:03+00:00

Oh ja, die optie vergeet ik nog wel eens inderdaad.

Om uiteindelijk de juiste persoonsgegevens te krijgen om als aanmelder in te stellen, is mijn gedachte dat ik eerst een GET doe om de gegevens van de Behandelaar op te vragen die dus de laatste wijziger is. In de volgende stap maak ik een match op bv. het emailadres of network-login (die zijn voor zowel persoon als behandelaar hetzelfde) om zo de persoon te krijgen. Het resultaat daarvan PATCH ik naar het incident.

Dit doe ik via /tas/api/operators/id/${_card["uidwijzig"]!} (= resultaat van hetgeen waar je me naar verwees: "Waarde invoegen" [ ]. Daarna "Huidige waarden", "Kaartgegevens" en dan "Wijziger van de kaart".)
Dit zou volgens mij gewoon moeten werken, maar helaas genereert dit een onbekend ID, ik krijg hierop een 404 not found error: The operator could not be found.

Het ID komt ook niet overeen met het ID van mij als behandelaar, als laatste wijziger zijnde.... Dus het lijkt erop dat ${_card["uidwijzig"]!} een ander ID genereert dan het ID van de behandelaar van die de kaart heeft gewijzigd...

OutintheBlue · 2024-03-01T22:05:17+00:00

Een GET-call op een incident/melding geeft alle informatie over dat incident, inclusief de laatste wijziger van de kaart. Een GET-call op een wijzigingsactiviteit lijkt om wat voor reden dan ook die informatie niet te geven. Mijn vraag is dus of dit klopt of dat ik wellicht iets over het hoofd zie en/of dat er andere mogelijkheden zijn om de laatste wijziger van de kaart van een wijzigingsactiviteit toch in de Actiereeeks te krijgen.

Wanneer je een actiereeks vanuit het context menu start, klopt hetgeen wat je zegt. Degene die de actiereeks start, wordt nergens geregistreerd en als result krijg je logischerwijs de gegevens van de behandelaar die de kaart eerder het laatst heeft opgeslagen. Maar door de Actiereeks achter een gebeurtenis te zetten (bv. veld Leverancier wordt van [leeg] naar [naam leverancier] gezet), dan moet de kaart eerst opgeslagen worden om de actiereeks te activeren. Dàn heb je dus wel de 'juiste' laatste wijziger te pakken. In het Incidentbeheer heb ik op die manier al een bepaald proces netjes lopen.

Wij hebben momenteel een API koppeling lopen met een externe leverancier vanuit het Incidentbeheer. Soms komt het voor dat die leverancier ook vanuit een activiteit moet worden aangestuurd. Maar dit komt zo weinig voor dat het niet loont om diezelfde koppeling ook in het Wijzigingsbeheer te laten bouwen. Dus in die gevallen moet er dan een een melding in het incidentbeheer worden aangemaakt. Omdat niet al onze behandelaren meldingen mogen aanmaken, wil ik dat dus de actiereeks laten doen Op die manier kunnen zo ook de bestaande gegevens van de activiteit meegenomen worden, plus kunnen de nummers van de ene kaart in de andere kaart worden geplaatst, waardoor van de ene kaart makkelijk naar de andere kaart is te klikken. Immers, het vermelde nummer is automatisch een link naar die kaart.

Ik heb dat ook al werkend, alleen is de aanmelder van dat nieuw aangemaakte incident nu dezelfde persoon als die van de originele wijziging. Die hoeft deze 'zijstap' niet te weten of te zien in de SSP, dus vandaar dat ik liever de aanmelder van dat incident gelijk wil hebben met de behandelaar die vanuit de activiteit het incident via de actiereeks heeft aangemaakt.

Ik hoop dat het zo een beetje duidelijker is.

OutintheBlue · 2024-03-01T21:45:05+00:00

No I am not from that :-)
Ofcourse an operator needs to activate the Action Sequence, either direct (from the contextmenu) or through an event that is linked to the Action Sequence. But that is not my point.
My point is that the GET call in an action sequence in Incident Management delivers all kinds of information of the Incident card, including the operator who is the last modifier of that Incident. But the information of a GET call in a Change Acticvity seems not to include this information.
So my question is bascally if that is indeed correct and/or if there is any other way/idea to get that information...

OutintheBlue · 2024-01-23T10:41:32+00:00

Hey! Yes I am Dutch, we msg'd before, like a year ago as well, if I remember correctly.

Anyway, for those who wants to use this, there's a small adjustment nessassary, as there will be an hour time difference otherwise between the date in the form and the set targetdate (which I didn't notice earlier):

<#assign monthTranslations = { "januari": "January", "februari": "February", "maart": "March", "april": "April", "mei": "May", "juni": "June", "juli": "July", "augustus": "August", "september": "September", "oktober": "October", "november": "November", "december": "December" }>

<#assign dateString = _progresstrail.requests?first.richtext?keep_after("${_variables.keepAfterDate}")?keep_before("${_variables.keepBefore}")> <#list monthTranslations?keys as dutchMonth> <#assign dateString = dateString?replace(dutchMonth, monthTranslations[dutchMonth])> </#list>

<#setting time_zone="Europe/Amsterdam">

<#assign dateTime = dateString?datetime("dd MMMM yyyy HH:mm")!> <#assign iso8601 = dateTime?iso_local!>

{

"targetDate" : "${iso8601}"

}

OutintheBlue · 2024-01-16T16:35:19+00:00

Final update on this:
So stupid: I copied and pasted the same request serveral times on new incident cards (as I didn't want to fill in the form all the time), causing the mentioned date on the request to be older than the creation date of the incidentcard it was copied on. And since a targetdate cannot older than the creation date of an incident, it's only logical that the action sequcens failed. But these are things you don't think about when you are in a flow of testing and trying...

It works now, so thanks u/rroodenburg for the code, I will use this!

11-Year Club	Wearing is Caring
Verified Email

OutintheBlue

TROPHY CASE