Running setup_tool.py

[NathanWilcox]

Hi,

Been struggling with this for a day now, Trying to get it set up with my MiHome equipment but whenever I run sudo python setup_tool.py it doesn't do anything after it. I see that you say use option 2 but no options come up. I have left setup tool run for half hour and it just appears as if it's frozen.

Any help?

[whaleygeek]

Hmm, that's odd.

It might be getting stuck failing to communicate to your radio board, perhaps the radio board is slightly offset on the pins on your Raspberry Pi (especially with the newer 40 pin Pi's as the radio is a 26 pin device and can easily be slightly mis-aligned).

There is no 'timeout' in the radio_init() function, so if the board is not correctly responding, it will sit waiting for a response, forever.

You could rebuild the C code simply by doing the following to add some debug trace to the driver, and send me the debug trace, which might confirm that fact.

1. First, remove the // comment marker at the start of this line: https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/drv/trace.h#L14

2. Rebuild the code as follows:

   • open an LXterminal prompt cd pyenergenie/src/energenie/drv ./build_rpi

This will rebuild the C code with a debug option on.

Then try

sudo python setup_tool.py again and observe the on screen output.

If you see lots of repeated '_wait_read' messages, this will mean that the radio is not responding to any commands that are being sent to it, which might indicate a fault with the board, the board not seated correctly in the correct position, or perhaps some conflict with some other part of the Raspberry Pi setup. This was last tested on a Raspbian Jessie build on a Pi 3, but I haven't yet tried this with the latest Pixel build. What model of Pi and what version of the OS do you have installed?

Additionally you could try checking if the Raspberry pi hardware SPI is enabled (from the menu button, choose 'preferences' and depending on your OS version you may see a Configuration option. In one of the tabs of that, make sure that SPI is disabled, press OK and then reboot your Pi and try again.

The pyenergenie code uses a built-in SPI driver to communicate with the radio. It's unlikely to conflict with the standard Raspberry Pi hardware SPI, but it is worth turning that off just to try.

Let me know how you get on.

[NathanWilcox]

Hmm, it would seem that my files, whether it be python files or this file, had become corrupted somewhere along the line.

I've managed to get past the freezing point as mentioned above. I now get the full list of options (1-10). When selecting option 2. mihome discovery mode it now enters discovery mode but tells me it cannot decode payload:

Any ideas? I have a feeling it could be down to the fact I have sockets not listed in your directory e.g. ##PRODUCTID_MIHO021 = 0x0? # Double Wall Socket Nickel

if this is the case how can i rectify?

[NathanWilcox]

@whaleygeek

David,

Ok, so I seem to be making some kind of head way on this.... I've managed to run setup_tool. It has found my nickel wall switch _PRODUCTIDMIHO024 (although to control it I need to use the white _PRODUCTIDMIHO008) and I can control it using the options:

4. --> 1. (I used delete device to clear the others)

Now how can I add my Nickel wall sockets _PRODUCTIDMIHO021 to the list?

[whaleygeek]

021 and 024 both use the legacy OOK protocol - so strictly speaking you need to put them into learn mode at the switch end, then use the legacy learn option on the menu to send out a pattern that the switch then learns.

Although, the OOK devices are quite non-selective and will learn most patterns that are transmitted to them - they are receive-only devices, even though they are branded as MiHome, and thus use the legacy OOK one way protocol (Pi transmits only, switch receives only).

You will get failed to decode' messages if using the MiHome discovery, as it is probably trying to interpret some other signal on the same band - but those switches are receive only devices.

Also, try different distances between the Pi and the switches, as less than about 2 meters will cause interference, and lots of walls and a long distance will cause signal strength issues at the switch receiving end.

The reason that 021 and 024 are commented out in Devices.py, is that there is no deviceid for OOK/legacy devices - they all react to whatever they 'recorded' when in learn mode.

Hope this helps.

On 31 January 2017 at 10:33, NathanWilcox notifications@github.com wrote:

@whaleygeek https://github.com/whaleygeek

David,

Ok, so I seem to be making some kind of head way on this.... I've managed to run setup_tool. It has found my nickel wall switch PRODUCTID_MIHO024 (although to control it I need to use the white PRODUCTID_MIHO008) and I can control it using the options:

4. --> 1. (I used delete device to clear the others)

Now how can I add my Nickel wall sockets PRODUCTID_MIHO021 to the list?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/82#issuecomment-276328667, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAefTOu1xtVrOwCPQYuVkTOixV2EDks5rXw37gaJpZM4LtKTd .

[asprinwizard]

Hi David,

I'm having this same problem. I recompiled the build to turn the debug on. I get the following output when running the setup_tool.py radio_init reset... reading radiover... 0 warning:unexpected radio ver<min radio_standby writereg 1 4 _wait_ready

then it just hangs. I've tried it on multiple Pis and OS. Do you think I have a faulty radio board? Is there anything else I can try?

Thanks, Richard

[whaleygeek]

That's usually a sign that the radio is not communicating at all, because a register read/write is not returning any data (SPI bus returns 0 by default if there is no response, hence version=0 and also the wait for the ready flag always returns 0 due to the radio not responding).

Check that the radio is aligned on the pins properly, but apart from that, looks like it might be non functional hardware, sorry :(

[asprinwizard]

Thanks David,

Probably faulty hardware then. However Energenie supplied me with a script called rxtx which when run does find the two devices I have plugged it. It's just a test script, you can't do anything off the back of it in terms of controlling or monitoring but I would have expected that to fail to work too if the hardware was truly faulty. Any thoughts?

[whaleygeek]

Hmm, if it works with the C code from Energenie, it should then work with my code.

Is this a gpio permissions thing I wonder? What model of Pi are you using, and what version of the OS have you installed? Perhaps there has been a change to GPIO hardware or configuration that we haven't picked up on yet.

If you have a link to which precise version of the OS you downloaded, that would be helpful.

Also, can you tell me if in the configuration page on the menu, have you got SPI enabled or disabled (it should probably be disabled, as we use our own SPI driver integral to the library to make it zero-install)

On 27 February 2017 at 08:47, asprinwizard notifications@github.com wrote:

Thanks David,

Probably faulty hardware then. However Energenie supplied me with a script called rxtx which when run does find the two devices I have plugged it. It's just a test script, you can't do anything off the back of it in terms of controlling or monitoring but I would have expected that to fail to work too if the hardware was truly faulty. Any thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/82#issuecomment-282660597, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cAa3cSPhWAwymcGZwBX9GqyKVofULks5rgo28gaJpZM4LtKTd .

[asprinwizard]

Hi David,

It doesn't work with the Energenie C code - I cannot monitor or switch anything it just hangs. They sent me this rxtx script to test it could find any connected devices. It picked them up but that is literally the only success I've had with this whole process. Energenie seem to think it's something to do with the BCM libraries, I have no idea but I have followed the instructions and have had no joy.

This is a RPI3 running Wheezy but I've tried an RPI running Jessie (Pixel) and the same thing happens.

I'm sorry I have no idea about the SPI, what it is or where I can enable/disable it. Can you point me in the right direction.

Thanks, Richard

[whaleygeek]

Could you send a photo of the screen that you see when you run the energenie rxtx code, I'm curious to understand how it is finding devices at all if the radio is not functioning.

Note, the BCM library is only used with the Energenie rxtx C code - part of the reason for us writing the new code was to factor out this dependency so that people could just download the project files and run it without having to build or install anything.

To get into the preferences, follow this path on the menu... http://www.raspberrypi-spy.co.uk/wp-content/uploads/2015/09/raspberry_pi_configuration.png

Then on the interfaces tab, make sure SPI is disabled. http://www.raspberrypi-spy.co.uk/wp-content/uploads/2015/09/raspberry_pi_config_tab2.png

If it was enabled, disable it, press OK then reboot your Pi.

It is a long shot, but I'm just trying to rule out all possibilities here. Let's not write your radio board off yet, but we need to try to work out what the rxtx C code is managing to achieve, and what the differences in your OS might be.

It will be a little while before I can build up a Pi of the same spec as yours and test this, so let's try and narrow down the options as much as we can in the meantime.

On 27 February 2017 at 16:01, asprinwizard notifications@github.com wrote:

Hi David,

It doesn't work with the Energenie C code - I cannot monitor or switch anything it just hangs. They sent me this rxtx script to test it could find any connected devices. It picked them up but that is literally the only success I've had with this whole process. Energenie seem to think it's something to do with the BCM libraries, I have no idea but I have followed the instructions and have had no joy.

This is a RPI3 running Wheezy but I've tried an RPI running Jessie (Pixel) and the same thing happens.

I'm sorry I have no idea about the SPI, what it is or where I can enable/disable it. Can you point me in the right direction.

Thanks, Richard

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/whaleygeek/pyenergenie/issues/82#issuecomment-282762716, or mute the thread https://github.com/notifications/unsubscribe-auth/AD5cATiLsElD7UbiIHosYVkpNdn0V9YFks5rgvN0gaJpZM4LtKTd .

[asprinwizard]

Hi David,

The response I get is below:

Received packet with address: 04:02:000951 09:24:32:306 RSSI= -21dBm Received packet with address: Energenie:ADAPTER_PLUS:000951 pID= 0x70 REAL_POWER_RESPONSE pType= 0x82 dataType= 0x08 dataCount= 0x02 data: 0 17 pID= 0x71 REACTIVE_POWER_RESPONSE pType= 0x82 dataType= 0x08 dataCount= 0x02 data: 255 253 pID= 0x76 VOLTAGE_RESPONSE pType= 0x01 dataType= 0x00 dataCount= 0x01 data: 245 pID= 0x66 FREQUENCY_RESPONSE pType= 0x22 dataType= 0x02 dataCount= 0x02 data: 49 205 pID= 0x73 SWITCH_STATE_RESPONSE pType= 0x01 dataType= 0x00 dataCount= 0x01 data: 1

09:24:37:311 RSSI= -69dBm CRC received FAIL=2689 CRC_check=4B00

This is slightly different from what I was getting before which was both adapters and the fail bit at the bottom didn't appear. It now only appears to find the adapter closest to itself - in fact it is attached to the Pi!

As for the SPI, I run the Pi without the GUI, Is there a way to disable it using the command line?

Thanks again for your help. Richard

[asprinwizard]

Hi David,

Any views on the above? Not sure where to go with this.

Thanks, Richard

[DavidWhaleMEF]

Hi Richard,

Hmm sorry about this, been a bit busy with other stuff. It's curious that the script they sent you receives messages, but that my code just hangs in the radio init routine. That mostly implies that for some reason it can't drive the GPIO lines that are connected to the SPI port (as it drives them directly).

There was a patch to the gpio.c to include the new gpiomem device tree fixes on later OS's so that you don't need to run prefixed with sudo, although you would get a protection error if that was the case.

The only thing I can think to do, is to try to verify the operation of those GPIO pins, by putting LEDs on the SCLK, CS1 and MOSI pins and make sure that those pins can be driven - but using the gpio.c code that is inside my energenie code.

I'll have a look through my code and see if there is already any test code there that does that, or if not, I can think of a way to write a simple test harness that just waggles the pins slowly, so you can then report whether the LEDs turn on or off.

[whaleygeek]

Hi @asprinwizard I had a look at the code. There is a gpio_test.c that gets built as part of the build_rpi script.

The best diagnosis you could do here would be to edit gpio_test.c and change the GPIO_A and GPIO_B to use 25, 7, 11 and 10 (perhaps either expand the code, or do two separate tests with 25,7 and then 11,10)

I think that the default numbers in gpio_test.c are for the two LEDs on the radio board - so you could just try that first and see if it can drive the red and green LEDs on the radio board first, and then move over to testing the SPI pins numbered as above (but remove the radio board and wire an LED with a resistor to ground to test the pin).

You can rebuild the code by using the cd command from a lxterminal prompt to change into the src/energenie/drv folder.

Then rebuild the gpio_test code with ./build_rpi

You should get a new gpio_test executable, which you can then run with

sudo ./gpio_test

This should then flash the two LEDs on the radio board. Then change the GPIO numbers in gpio_test.c and rebuild it, run the same test with the radio board removed but LED and resistor to ground on the appropriate pins.

Note, take care to understand the difference between a pin number and a BCM number. The BCM number is what is used, I think (which is not the same as the pin number), but you can look up both on the internet, just google "Raspberry Pi pinouts'.

Let me know how you get on with this.

I have a hunch (and it is only a hunch) that the red and green LEDs on the radio board will flash, but when you attach LEDs to the SPI pins they won't flash, and this may be due to some other conflict in your system.

Also you should probably first test that you can attach LEDs/resistors to BCM GPIO22 and 27 (or whatever pins the two radio LEDs are on) and flash them to check your wiring first, before moving onto the SPI pins.

It might then be that we have to work out how to disable the hardware SPI driver on your raspberry pi if it is conflicting.

The energenie test code that they sent you that you used, probably uses the hardware driver, which is why that is working. I originally wrote the software spi driver as a way to avoid all this messing about with enabling and disabling SPI, but it is possible perhaps that the later builds of the OS forbid using these pins as GPIO pins if the hardware SPI is enabled. That's my hunch anyway.

Let me know how you get on.

[BobSammers]

There was a patch to the gpio.c to include the new gpiomem device tree fixes on later OS's so that you don't need to run prefixed with sudo, although you would get a protection error if that was the case.

There is an active pull request (#86) for this (at your request, @whaleygeek) to solve issue #84 that hasn't been merged yet! 😃

[whaleygeek]

Hi @BobSammers yes sorry about that, been busy with other projects and not had any chance to dig out the devices and test the various fixes, including this PR. I'm generally signposting your PR for people at the moment until I get round to doing it. I am sure it works fine, but I don't want to just press the merge button without trying it myself, and it's been a while since I've done anything with my devices.

[BobSammers]

@whaleygeek No problem - I think I misread your comment as, "the code (i.e. Master branch) was recently patched..." when you meant, "there is a way of patching the code...".

I obviously wouldn't expect you to merge untested code (I wouldn't!) into the main repository. If I admit that I edited it in the online Github editor and haven't actually compiled it myself from the revised code you certainly won't... (It was copied and pasted from working code - I've never used Github before and it was a bit of a learning curve.)

[whaleygeek]

@BobSammers no problem, glad you worked it out - yes, github can seem a bit odd the first time you use it, but it's very powerful. I was surprised to see so many forks of this project when I looked tonight, which is a good sign that people are doing things with the library!

I want to find some time soon to write and test the OOK receiver idea that I have, and finish off my webconsole (that's on a webconsole branch here: https://github.com/whaleygeek/pyenergenie/tree/web_console) when I have cleared my backlog of other projects, and I'll roll these fixes into it too.

[aziraphale]

I think the fact that the Pi's native SPI needs to be disabled needs to be written somewhere more prominently. I just spent a while trying to figure out why my 314-RT wasn't working (the setup script just hung) until I spotted the comment above about requiring SPI to be disabled. Lo and behold, after disabling SPI in sudo raspi-config and rebooting, the radio works perfectly!

[whaleygeek]

@aziraphale Good point. Although I must confess, when this library was written, SPI defaulted to off in the standard Raspbian build. It might be that has changed now.

[aziraphale]

@whaleygeek I think it does still default to off, but that doesn't mean that it hasn't been changed :) I enable SPI on all of my Pis by default when I set them up, as I've just been assuming that SPI-enabled is more useful than SPI-disabled. Maybe I was wrong ;)

[9600]

I can confirm that this does not work for me with a Raspberry Pi 3 and Raspbian Lite 2018-11-13. Enabled trace/debug and it hangs at _wait_ready as described above, suggesting it cannot communicate with the radio.

Testing was initially a pain because CTRL-C does not interrupt when running as root, but this was made easier by rebuilding with the unmerged PR changes to enable running as a normal user.

Also agree with @aziraphale that it would be nice if it was made clearer that SPI should not be enabled, since the moment I want to use an SPI device the first step I will take is to enable SPI. More generally I'm not convinced of the benefit of access in this way — which would seem to me to be far more fragile — over using a standard O/S device interface.

[jmigreen]

@9600 Can you confirm that it continues to fail if you run the cleanup_GPIO.py script included in David's package before trying to run anything else?

If it works after doing so, you can include that code in your own scripts to make sure that the pins are setup correctly. I found that after reboots, the Pi is resetting the pins to undesirable settings.

[whaleygeek]

@9600 any further progress on verifying whether this works or not?

[9600]

@whaleygeek afraid I returned the whole lot to Amazon some time ago. Couldn't get any of the software I found for them to work. Now using Zigbee2MQTT with Salus SP600 smart plugs instead, which worked without issue and was up and running in no time.

Thanks for following-up, though, it's appreciated.

[whaleygeek]

I have made the cleanup a bit more automatic now, and rolled this into setup_tool.py so it does it on all normal and failure paths.

I have put a signpost in setup_tool.py about the 'disable hardware SPI'.

I have put a check for python3 at the top (as Python2 support will be generally disappearing now Python2 itself is in the end of life phase)

I have added a setup_tool bash script that runs the setup_tool.py as root using python3, and updated the README to show this new wrapper script being used.

I think I've attacked all angles of this, so will close the issue now as there were a number of different things discussed on this issue and I think those have all now been resolved, or been open too long that people have moved on anyway!