Please forgive me, this is above my head and below was generated by Claude following investigations into my issues. I believe it is a bug, but I'm largely trusting Claude for that.
Describe the bug
_process_history_dataframe in retrieve_hass.py calls self.freq.seconds but self.freq is passed as an integer (the optimization_time_step value from config, e.g. 30) rather than a pd.Timedelta object. This causes AttributeError: 'int' object has no attribute 'seconds' which is silently caught upstream and misreported as "The retrieved JSON is empty, A sensor may have 0 days of history".
Additionally, when a pd.Timedelta object is passed, recent versions of pandas have removed the .nanos attribute, causing a further AttributeError: 'Timedelta' object has no attribute 'nanos'.
To Reproduce
- Install EMHASS as Docker standalone container
- Set
optimization_time_step: 30 in config (integer, as documented)
- Run dayahead-optim or forecast-model-fit
- Observe misleading "empty JSON" error in logs
Expected behavior
RetrieveHass.__init__ should normalise the freq parameter to pd.Timedelta regardless of input type. Suggested fix:
if isinstance(freq, (int, float)):
self.freq = pd.Timedelta(minutes=int(freq))
else:
self.freq = freq
This ensures self.freq is always a pd.Timedelta throughout the class. Any subsequent use of .seconds will then work correctly without needing to handle multiple types downstream.
Home Assistant installation type
- Home Assistant OS (running in Docker on Synology NAS)
Your hardware
- OS: Linux (Synology DSM)
- Architecture: amd64
EMHASS installation type
- Docker Standalone (separate container, connecting to HA via
host.docker.internal)
Additional context
The type hint on RetrieveHass.__init__ correctly specifies freq: pd.Timedelta but the caller in command_line.py passes retrieve_hass_conf["optimization_time_step"] which is a raw integer. The fix belongs in __init__ to normalise at the boundary rather than patching each usage site.
Note: pd.Timedelta.nanos has been removed in recent pandas versions. Use pd.Timedelta.seconds or int(pd.Timedelta(minutes=x).total_seconds()) for portable code.
Please forgive me, this is above my head and below was generated by Claude following investigations into my issues. I believe it is a bug, but I'm largely trusting Claude for that.
Describe the bug
_process_history_dataframeinretrieve_hass.pycallsself.freq.secondsbutself.freqis passed as an integer (theoptimization_time_stepvalue from config, e.g.30) rather than apd.Timedeltaobject. This causesAttributeError: 'int' object has no attribute 'seconds'which is silently caught upstream and misreported as "The retrieved JSON is empty, A sensor may have 0 days of history".Additionally, when a
pd.Timedeltaobject is passed, recent versions of pandas have removed the.nanosattribute, causing a furtherAttributeError: 'Timedelta' object has no attribute 'nanos'.To Reproduce
optimization_time_step: 30in config (integer, as documented)Expected behavior
RetrieveHass.__init__should normalise thefreqparameter topd.Timedeltaregardless of input type. Suggested fix:This ensures
self.freqis always apd.Timedeltathroughout the class. Any subsequent use of.secondswill then work correctly without needing to handle multiple types downstream.Home Assistant installation type
Your hardware
EMHASS installation type
host.docker.internal)Additional context
The type hint on
RetrieveHass.__init__correctly specifiesfreq: pd.Timedeltabut the caller incommand_line.pypassesretrieve_hass_conf["optimization_time_step"]which is a raw integer. The fix belongs in__init__to normalise at the boundary rather than patching each usage site.Note:
pd.Timedelta.nanoshas been removed in recent pandas versions. Usepd.Timedelta.secondsorint(pd.Timedelta(minutes=x).total_seconds())for portable code.