I can’t see this as a filter in the Python module the integration uses. If anyone knows better, then we can always raise it as a request with the owner of that module.
1 Like
Hi RogTP
I have been using your 365 version, but two weeks ago, it isn´t reading my inbox new mail.
Is there anything I need to reconfigure?
You are amazing by the way :3
Regards
Sorry, I really have no idea. I’ve never used or tested that element of the integration. I have moved it into my GitHub to fix basic problems due to changes in HASS that stopped it working. I’ve only used the calendar, so I have no idea if email works or how it works. I’d query whether others are seeing the same problem.
One things I have done is moved it from a custom HACS install back to being a standard repository, but I don’t think that will make any difference.
1 Like
By the way I’ve released a couple of new versions since this query, where I have validated that it reads email fine. I’ve also just added a new sensor to read the Teams presence status, which is in version 2.3.0 which is in pre-release (beta) at the moment.
1 Like
I have just posted a beta of the O365 integration which supports multiple accounts. It is a major update to the code which has been tested through Alpha, but may still have minor issues. This will require a change to you configuration structure (if you want to utilise multiple accounts). It also enables the use of entity_id rather than calendar_id for service calls.
Additionally it reduces the default permissions requested if use multi-account config, and enables the reduction of permissions for existing installs that don’t require them. Please look at the enable_updates config items for more details.
Just for information the next release after the 3.0.x series, planned to be 3.1.x, will require HA 2022.5 as a minimum due to some changes in how Calendars are handled in that release.
Full documentation is here:
The release notes are available here:
Full list of changes are available here:
For information, I’m planning to change the default method of authentication with the next release 3.2.0. This is because the current alternate method is actually the simpler method of authentication for many people and is the method recommended by the underlying module that interfaces to O365.
This will have no impact to existing users unless their token expires, in which case you will need to reverse the value of ‘alt_auth_flow’ to retain your existing method of authentication.
Sorry, but I couldn’t think of another method of swapping the default method.
I’ve changed this, so in order to support the change in default authentication method I’m adding a new configuration variable alt-auth-method so I can provide some deprecation warnings. It will mean everyone will need to do something in order to retain the same authentication mechanism, but there will be guidance on what to do in the warning.
1 Like
Want to give a big props to @RogTP for the O365 integration and ongoing development! Thanks for the new chat status 
2 Likes
darn it. I get the message
“This app requires your admin’s approval to…”
Any option to bypass this?
As far as I know you will need to request the access from your admin
Ok total NOOB question here, but when I try to add
“https://github.com/RogerSelwyn/O365-HomeAssistant”
OR
“O365-HomeAssistant/custom_components/o365 at master · RogerSelwyn/O365-HomeAssistant · GitHub”
As repositories under add-in’s I get either a git error or “https://github.com/RogerSelwyn/O365-HomeAssistant is not a valid add-on repository”
I can not find any other way to add repos (I have checked the 3 dots for integrations, devices, entities and helpers… no dice)
I am sure it is me, and I am sure I am being dumb… but my google-fu is not locating how to add integration repos in the current version of Home Assistant. And I would like to see if I could get this module working to replace my DakBoard setup.
You need to use HACS, where you will find it in the preconfigured repositories.
1 Like
Ahhhhh. I didn’t know what HACS was! I literally thought it was short hand for the out of the box HA supported add-ins and stuff…
Installing now… Much appreciated (now to get IT to let me read my own calendar from MS graph…)
@RogTP Hi. I’ve gotten to step 4 on your guide. However, I never receive any persistent notification after restarting (without error). Any idea as to what could be wrong?
You need to go check for the notification, it maybe there, but HA doesn’t seem to show a badge for it
Also, you did do the pre-requisites as well?
Thanks, that was it. Now I’m instead stuck on the next step where after approving the permission requests and adding the URL, I don’t have any calendars added as entities. Although the yaml o365_calendars_calendar. is created and they have ID’s.
Another strange thing I noted is that even though I followed the instructions for the primary method, the yaml that is created is named “o365_calendars.yaml” and not " o365calendars.yaml" like the instruction says it will.
I’ll correct the documentation. Have you rebooted HA after the yaml file is created?
And if you can post your config with secrets hidden, that would help since yaml should be created as o365_calendars_aaaaa.yaml for primary method.
Also could you point me at where it says “o365calendars.yaml” in the instructions?
Quoted from the website (bolded the relevant text):
- A persistent notification will be shown in the Notifications panel of your HA instance. Follow the instructions on this notification (or see Authentication) to establish the link between this integration and the Azure app
- A persistent token will be created in the hidden directory config/.O365-token-cache
- The o365calendars .yaml (or o365_calendars.yaml for secondary configuration method) will be created under the config directory
The only entity available is a configurator: O365 - calendar.calendar_xxx
Configuration.yaml:
o365:
accounts:
- account_name: calendar.calendar_xxx
client_id: "xxx"
client_secret: "xxx"
alt_auth_method: False
enable_update: True
email_sensor:
- name: inbox
max_items: 2
is_unread: True
download_attachments: False
query_sensors:
- name: "Example"
folder: "Inbox/Test_Inbox" #Default is Inbox
from: "[email protected]"
subject_contains: "Example subject"
has_attachment: True
max_items: 2
is_unread: True
status_sensors: # Cannot be used for personal accounts
- name: "User Teams Status"
chat_sensors: # Cannot be used for personal accounts
- name: "User Chat"
Calendar yaml:
- cal_id: xxx (copy paste from the generated yaml)
entities:
- device_id: calendar_xxx
end_offset: 24
name: cal_xxx
start_offset: 0
track: true
The persistent notification doesn’t seem to go away even after providing the URL.
Ahhh, that is Github converting some of the content of the page to italics. I’ll sort that.
No idea if it will work with a complex name like that. Try it with just a single word.
Have look in the logs, to see if there are any warnings. This suggests it isn’t authenticating properly. Probably this is because you have used a complex account name, which means it can’t read the authentication token.