-
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
MIHO004 / ENER034 without Miihome gateway #107
Comments
Hi John, The MIHO004 is a transmit only device, but it uses an FSK device that transmits data on a regular period using the OpenThings payload format. Inside that payload format is a unique deviceid. To use without a MiHome gateway, run setup_tool.py and start the "mihome discovery mode". This will then repeatedly listen in FSK mode, and when your MIHO004 transmits an energy report (it chooses when to send this, I forget how often, perhaps every 30 seconds or 1 minute), a message will pop up on the console screen with the device details. setup_tool.py when in discovery modem is configured to use the 'ask' joining behaviour, inside the code. This means you then get asked 'Do you want to register to device: %s?' where %s will be the deviceid unique to that device. Answer with a y and it will store details about that device inside the registry.kvs file, so that all the other examples programs and the other options on the setup_tool.py menu will recognise the device. You can monitor readings now from setup_tool.py using the 'watch devices' or 'logging' options, to gain some confidence that the device is working. Once you have each of your devices learnt to the registry.kvs file and showing correct readings, you may then want to use one of the example Python programs in the root of the src folder to build your application from. There are a number of different design pattern examples there, depending on what you wish to achieve. But it should be possible to monitor a large number of devices. Note that due to there being no advanced support in the Energenie protocols for collision detection, if two devices transmit a report simultaneously, you may get corrupted data. However if the monitors power up at different times, report times will be staggered. There is a potential use-case I identified (power cut), where if your house consumer supply goes off and on due to a house-wide power cut, all plugs are likely to power up at the same time and report at the same interval from power on. It is normal for device manufacturers to insert a random delay on power-up to prevent this situation, but I haven't yet been able to verify with the engineers at Energenie HQ whether these devices have a random power-up delay in their firmware or not. Please do report back here as to how you get on with this. Hope this helps. |
Also note, the drivers are written to allow interoperability between legacy devices and MiHome devices. The radio will be left in receive FSK (OpenThings) mode most of the time so that you don't miss energy reports from transmit-only devices. If you request a legacy device to switch on or off, the radio auto-reconfigures into OOK transmit mode, bursts a run of 10 messages to that switch to change it's state, then immediately reconfigures back to FSK receive mode. So, it should be possible to build a system with both legacy and MiHome devices, and I did indeed have a large number of both devices present and working when I originally tested this code. So, you have all the building blocks to build a simple system or a system of comparable complexity and flexibility of the MiHome gateway yourself in Python. |
Cheers David. That's pretty much exactly what I needed to know. My existing application (https://github.com/megatron-uk/sdlRFController) is designed to run macro actions when pressing a touchscreen button, so you can press, for example "Sega Megadrive", and the configuration of devices to buttons knows that to do that we have to do the following power-on actions:
Here's what the actual definition of one of my touchscreen buttons looks like, in this case for Roland MT-32 MIDI synth module:
A mixture of how the button renders on-screen, and also the actions to take when pressed 'on', or 'off'. In 'on' mode it sends a power-on signal to remote/device id 0xABCDE, socket 1 (which is the MIDI module itself), but then also sends an 'on' signal to every other device tagged as 'speakers'... which includes an amp module, a mixer and a midi controller. All which have their own 'remote' and 'socket' identifiers, of course. The power on/off code unwinds to the individual device signals a tag is assigned to via the function setButtonPower() It's a little bit like a Logitech Harmony remote, but for the dumb Energenie legacy remotes :) What I want to be able to do is monitor the power use of all the ENER010 devices as I'm powering things on, so that I know what sort of headroom I've got with the mains supply. I think with what you've provided I can do that relatively straight forward and add a seperate Python thread listening for those broadcast messages on a periodic basis, logging them and graphing the results on the touchscreen. |
Or you could try my new node-red nodes node-red-contrib-energenie-ener314rt. I've just made the github repo accessible for beta. It allows for control & monitoring using node-red, and it should deal with your use case. |
Hi, after finally getting my radio module working I've been able to look in to this. First thing I found was that there's an exception thrown if you're using Python 3 -
... so it looks like we may need to change raw_input() to input() (plus associated key value to character mapping) to make it Python 3 safe. This is in Using Python 2 it runs, and eventually after 30 seconds or so I see a response from my MIHO004:
Selecting
In my test code I am trying:
This eventually, after a few loops of listening, shows the following text:
If I run
|
Regarding raw_input yes that is a bug, we should fix it for sure. Regarding no-route, there was a PR I merged a few weeks ago that uses a different way of calculating the path to the registry.kvs file, it's possible that depending where your cwd is when you invoke the script does or does not have a bearing on which file is actually used. Follow through the code here to see if it is loading your real registry when init() is called, I have a hunch it might for some reason now be not finding your registry and creating an in memory default blank registry, and thus when the message arrives it doesn't know which object (via fsk_router) to pass it to. One of the perils of me not having a live setup is that I currently rely on PR authors to test their changes, which is why I am often slow to merge PR's. Let me know what you discover. There are some print() statements in that referenced code, do they generate output in your case? |
Ok, so it seems to try and load If I symlink
The problem with the error
I see the following output:
I would have thought that the init() call should have added an entry to the registry for 3966, but it appears empty. |
So I realised that the code in registry.kvs
test.py
For some reason this gives me different behaviour of the registry routes data structure, here's the output now:
And I see the mains line voltage being printed! |
Ok, looks like I need to re-test mihome_energy_monitor.py and fix or update appropriately, thanks. |
Since I now own 13 (yes, not a typo) ENER010 power strips which will probably be running from just a handful of sockets I figured it would probably be a good idea to monitor what they're actually pulling from the wall (though I don't expect to have loads of things turned on at the same time).
How do I use (probably 2x) MIHO004 without a miihome gateway; is that even a supported configuration? Do I need to pull some sort of unique broadcast device id from them the same as we have to do with the older legacy remotes?
The text was updated successfully, but these errors were encountered: