I’m not sure, but I think you need to group together the main sections, otherwise the second one overwrites the first (instead of adding items as you intend).
So, one rest_command section with two items, then one sensor section with two items, then one command_line section with two items
I am trying to set this up for my Kids to use. So I have 3 sections, Morning, After School, and Evening. I’ve created a label to filter by for each time of day. I also want a 4th one as a catch-all for tasks missing either a due date or a label. I can’t get it to filter properly. Here is my code
The idea is, this would act like the Inbox in Todoist, so items without a date or not labeled would be added to this parked section. I can’t get the unlabeled/dated to populate at all.
I never implemented that as a filter, only as an action (to clear all labels). But when I edited the README I mistakenly wrote it in the filters section… sorry.
You can probably work around it with some other label scheme. How are you creating the items, is it from this card, or from Todoist app, or …?
I use Todoist directly. This will eventually make it’s way to a Nest hub for the kids to check off their daily list. I’ve been fighting with Labels and dates for the last couple of days. Right now, I have 2 tasks that have a due date of today, but no labels. I want these to show up in a new section but it’s not displaying. I see them in the entity
So is the !* filter not supposed to filter for items without labels? I’m not sure I understand what you’re saying. Basically, I can’t get any exclusion filters for Labels to work.
Hi - I just started using this a few days ago. We are using this to track daily chores for my kids on a tablet mounted on the wall. It basically works for our purposes, but my kids complain that when they tick an item it sits there for a bit before it disappears, and I have witnessed them trying to quickly tick multiple items, which leads to unpredictable results when suddenly one of the ticked items disappears after a couple seconds (meaning they have now just ticked the wrong thing since the entire list moved up by one or two items).
Is this lag between ticking an item and clearing the item from the dashboard a known issue? Any tips for increasing performance?
Hi. Yes I am well aware of the lag. It’s the downside of working with remote data (Todoist).
To improve that you basically need good internet performance all the way to Todoist’s server. Some of these elements might be under your control - check your tablet has proper wi-fi coverage, your house Internet is not laggy, etc.
But if nothing helps, I can tell you that I am about to release (in 2 or 3 weeks) a newer version to move to a new Todoist API, so it is a breaking change, involves some tweaks to the config files.
This new version should have a better experience regarding those lags, although still not perfect. But with good internet you should be able to see everything updated in 1 or 2 seconds.
hey - thanks for the reply. just a thought, and I don’t know how much of a pain this would be to implement in HASS, but making all the operations local and then backgrounding the API call may be better solution here rather than waiting to receive the response back from todoist before updating the list. this would allow you to immediately update the status / hide the task that was just ticked without waiting to get a response back from todoist.
queueing of all api calls until x seconds after the last interaction with the list would also help ensure that the list doesn’t jump around due to an update coming back from todoist while someone was in the middle of ticking other things off.
again, I have never done any coding for HASS, so maybe this is not possible for reasons that I am not aware of, but generally speaking, working locally and backgrounding async tasks and api calls would make things feel snappy and hide latency from users.
The API call is backgrounded, it doesn’t freeze the UI. The problem is that the card reflects a HASS sensor, which in turn is fed by the API. So when you change something, the change goes off to Todoist, then the sensor period passes (typically 20 seconds although you can set it tighter), it calls to get the new API data, then refreshes the UI.
The card has several tricks to obviate this, such as (in some cases) making the specific change to the UI directly while waiting for the whole thing to refresh.
But it’s just not a good architecture. I was learning Javascript as I went along, and I am definitely guilty of feature creep. The code is convoluted and, as a developer, I assure you I would never pass what I wrote if I was doing a code review of it
But hey, it mostly works and does a lot of cool things, so…
The updated version (for the newer Todoist API) I spoke about is the one where I changed things around more deeply. It also brings quite a few new nice features. It definitely feels faster and then we can improve on it.
I have installed this card today, but cannot get the Rest sensor to work. It is created, but not available. Is this something to to do with the above mentioned changes to the version? The following data has been added to the configuration file:
The problem here is white text on a white background, as you suggested. If I change the theme of the page, I can see the dates - not just the calendar icon.
Is there a way of changing the font color?