Hi I have been running iCloud 2.3.1 for sometime now with issues.
I just tried updating 2.3.2 and iCloud fails to start warning there is an issue with config or failed to start etc.
It also killed my ping tracker.
Rolled back w.3.q and all good again
Any idea’s
@Kelvin_Sudlow
You’ll need to post the error messages, your config, where it fails, etc before I could offer any suggestions.
iCloud3 v2.3.3 Released
HACS was updated today with v2.3.3. It is a maintenance release that fixes the following bugs:
- The track_from_zone devices parameter is used to track from the home zone and an additional zone. It was not being accepted and creating an error, resulting in iCloud3 not tracking any devices.
- Changed invalid configuration parameter error messages so they are consistent and provide more information.
- Cleaned up and optimized some code.
Note: I rewrote the config_ic3.yaml configuration file decode routine and, hopefully, didn’t break anything.
Gary
Hey Gary, fyi, I’m getting this error in my logs:
name 'selwf' is not defined
Traceback (most recent call last):
File "/config/custom_components/icloud3/device_tracker.py", line 1410, in _start_icloud3
selwf._display_info_status_msg(devicename, "Initialize Event Log")
NameError: name 'selwf' is not defined
I know about the 'selwf ’ issue and will update iCloud3 today or tomorrow. It is a one time error that happens during startup when displaying the process that is going to be done. It has no effect on the iCloud3 operations.
I found a problem dealing with requesting the location from the ios app and never receiving a response. The interval stays at 6-seconds and fills the Event Log with the request message error when it should just increase the interval. And this only happens during startup.
Edit: The above is for the iosapp tracking_method only.
@gcobb321
Hi Gary, FYI v2.3.3 release corrected the issue I was experiencing when running on a RC version and updating to a released version through HACS. I now see the correct version per below. Thank you!
Hi @gcobb321
I noticed something strange when fiddling with the recently added display_zone_format configuration parameter. When setting this parameter to another parameter than the default (name), the parameter is not applied when HA core is (re)started. Only when restarting iCloud3 with the iCloud3 eventlog the parameter is applied. Any idea why this happens?
iCloud3 loads all the zone info into an internal table and uses he values in the table for all processing when it starts or is restarted. Because of the way zones are handled and zone data is processed, it is not practical to go back to HA every time zone info when needed. Thus, a restart of iCloud3 is required to pick up any zone data changes.
v2.3.4 has been uploaded to the icloud3/development v2.3.4 directory
- Download it here
- Unzip the device_tracker.zip file into config/custom_component/icloud3 directory.
- Restart HA
Change log:
- Corrected the ‘selwf’ spelling error.
- Fixed a problem setting up the track_from_zone parameter. The zone(s) specified are now verified. Also, the track_from_zone zone name can now be either the zone name or the zone’s friendly name.
- The config_ic3.yaml configuration parameters are now being validated. Errors are displayed in the Event Log and ignored.
- Added a check for a mismatched quote (’) in the config_ic3 parameter file. An error message is displayed in the Event Log showing the line number with the error.
- Fixed a problem where the ‘True/False’ configuration parameters were not being handled correctly.
- Removed all iCloud ‘2-factor-authentication’ code.
I dont see this update yet on HACS?
@shmookles
I haven’t put it in HACS yet. I was hoping a few would download using the unzip instructions to make sure I didn’t break anything first.
Installation instructions:
- Download it here
- Unzip the device_tracker.zip file into config/custom_component/icloud3 directory.
- Restart HA
I’ve been running 2.3.4 since you released it yesterday. Other than a couple seemingly age-related errors new to the HA log, all is fine.
v2.3.4 Bug Fix Update (2/23/2021) is available on HACS and on the iCloud3 GitHub Repository
- Corrected the ‘selwf’ spelling error.
- Fixed a problem setting up the track_from_zone parameter. The zone(s) specified are now verified. Also, the track_from_zone zone name can now be either the zone name or the zone’s friendly name.- The config_ic3.yaml configuration parameters are now being validated. Errors are displayed in the Event Log and ignored.
- Added a check for a mismatched quote (’) in the config_ic3 parameter file. An error message is displayed in the Event Log showing the line number with the error.
- Fixed a problem where the ‘True/False’ configuration parameters were not being handled correctly.
- Removed all iCloud ‘2-factor-authentication’ code.
Hi @gcobb321
I’m getting the below errors running v2.3.4
Logger: custom_components.icloud3.device_tracker
Source: custom_components/icloud3/device_tracker.py:9156
Integration: icloud3 (documentation)
First occurred: 12:30:30 PM (49 occurrences)
Last logged: 4:25:30 PM
►INTERNAL ERROR-RETRYING (_update_device_icloud:OverallUpdate-'isOld')
Logger: custom_components.icloud3.device_tracker
Source: custom_components/icloud3/device_tracker.py:2761
Integration: icloud3 (documentation)
First occurred: 12:30:30 PM (49 occurrences)
Last logged: 4:25:30 PM
'isOld'
Traceback (most recent call last):
File "/config/custom_components/icloud3/device_tracker.py", line 2761, in _update_device_icloud
location_isold_attr = location_data[ATTR_ISOLD]
KeyError: 'isOld'
Same errors here after updating through HACS. Before the HACS update I had no any error with V2.3.4 updated through GitHub.
Edit: error messages are gone after updating HASSIO op system to 5.12.
All working fine now.
I’m still getting the errors after upgrading to Home Assistant OS 5.12, but only about once per hour rather than ~12 times per hour before the upgrade.
@scotty1395
I’ll put a temporary fix up today. There is also a problem with setting the zone’s friendly name that was fixed in v2.3.1 and reintroduced in v2.3.4 that I’m working on. I think I’ve found that but am thinking about changing the zone name sensors to better match the Configuration > Zone > Name field that effects zone names with multiple words. See the following note.
I’d like some opinions about the sensor.zone_name fields created by iC3
This is an issue that:
- Only effects zone names with more than one word (The Point, Indian River Shores, etc).
- Will make the zone sensor names the Name of the zone in the Configuration > Zone Name
I think I found the problem with the fname handling. Basically, fixing one problem - allowing track_from_zone friendly zone name specification reverted the fname setup and reintroduces a setup problem corrected in v2.3.1.
I’m thinking about changing the zone sensor names so they better match the Configuration > Zone >Name. Currently:
- Configuration > Zone > Name = iC3 zone_fname (friendly name)
- iC3 zone_name is a reformatted zone entity name
I now think:
- iC3 zone_name = Configuration > Zone > Name.
- iC3 zone_fname = Goes away since it would be the iC3 zone_name
This only effects zone names with multiple words. A single word zone entity (Home, Work) and Name (Home, Work) create the same value.
An example of how the sensors are configured now:
- zone entity - ind_river_shores
- zone_name - IndRiverShores (from zone entity, remove the ‘-’, capitalize the first letter)
- zone_fname - Indian River Shores (from zone Name field, ok in v2.3.3, wrong in v2.3.4)
- zone_title - Ind River Shores (from zone entity, change ‘_’ to space, capitalize first letter)
The iOS App uses the zone’s Name (Indian River Shores), which is the iCloud3 friendly name.
The new way would make the iCloud3 sensor.zone_name the same as the zone’s Name and the same as the iOS App zone’s name. The sensor.zone_fname would be removed.
New way:
-
zone entity - ind_river_shores
-
zone_name - Indian River Shores (from zone Name field,))
-
zone_sname - IndRiverShores (from zone entity, remove the ‘-’, capitalize the first letter)
-
zone_title - Ind River Shores (from zone entity, change ‘_’ to space, capitalize first letter)
-
zone_fname --> zone_name
-
zone_name --> zone_sname (
sname
for short name) -
zone_title --> zone_title (or do you think
lname
for long name is more consistant)
The default would be the zone_name
Does any body have any thoughts on whether this makes sense or not?
Edit:
Upon further reflection, I will leave it as it is. I think there is a conflict between the Name of the zone on the Configuration > Zone screen and everything else.
- The zone’s entity name and it’s ‘friendly name’ are created when the zone is created. It is based on the name you type on the Configuration > Zone > Name field (the original name). You can later change that original name but the friendly name does not change.
- The friendly name is displayed in the Name on the Configuration > Entities window and can be changed there. It does not change the original name on the Configuration > Zone Name field.
- The friendly name is the name used by the iOS App for zone enter/exit triggers. Changing the friendly name in HA changes the iOS App zone name on the next HA restart or the next iOS App reload.
- It appears, HA is calling both the original name and friendly name on their windows ‘Name’ even though they are different names, do different things and do not relate to each other.
So I will leave things as they are until HA clears up this confict.
v2.3.5 is available for testing in the GitHub development v2.3.5 directory
- Download the zip file here
- Unzip it into the icloud3 directory
- Restart HA
It fixes the following bugs:
- The location_isold error when the data is not available. This was obsolete and unused code that has been removed.
- Fixed the problem with the zone’s friendly name created in the v2.3.4 update for zones with multiple words.