-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mihome_energy_monitor.py doesn't register or report values on console #132
Comments
The energenie.csv file stores all received messages from devices that send reports, by virtue of the way it registers a global fsk_router for all messages then appends them to the log. But really to be useful to users, this demo program probably needs to correctly route incoming messages to the device class instances, so that their RAM variables are correctly updated; besides, the application developer probably wants to use device.get_power() to query the last known power value, etc, rather than just relying on what has been written to the CSV file. |
@ytoch The logging to file works fine now for your MIHO004 (monitor only device), but this new ticket captures an issue that I need to think about and fix, so that you have a useful Python API to query values in a programatic way, rather than always relying on the data dump written to the energenie.csv file. |
Many thanks David for looking at the problem so quickly. Logging to file is the most important thing for us at the moment but I agree that an alternative would be useful. |
@ytoch No problem, glad to be able to help. Will look into building some better 'get you started' examples for the future, but glad that the log to file functionality gives you what you need for now. Good luck! |
A fairly small change to mihome_energy_monitor.py sets up routers for all devices.. |
Thanks. I will be picking this project up again in April, feel free to send this as a PR if you want to, and I will merge. |
While debugging #131 I noticed that the mihome_energy_monitor.py example doesn't correctly register the route from a registry retrieved device, to the object created when parsing the registry.
The upshot of this is that all incoming messages are reported as 'no route for unknown device', and therefore if you access the device class instance via the registry iterator, all it's values will be None (as demonstrated by the new print statement below). I never noticed this before in previous testing.
The text was updated successfully, but these errors were encountered: