Nuimo Integration

The latest version of the iOS Legacy App. But now I also don’t see any possibility for updating the firmware. I don’t remember how it was working in the past. Maybe the app checked automatically for a firmware update and a popup showed up when a newer version was available. Maybe you have already the newest version and that’s why nothing is offered to you. Anyhow, this way we cannot be sure whether this functionality is still working or not.

I think probably they just did not thought about this problem when introducing the hub. In wrote an e-mail to the developers asking them how the firmware update can be done now without the hub, will inform you as soon as I get a response.

@spawny0815: Would be cool if you could check the Legacy App and tell us if the app offers you a firmware update. Unfortunately, only the link to the Android app is still working afaik.

pip3 show nuimo :

Name: nuimo
Version: 0.3.6
Summary: Nuimo SDK for Python on Linux
Home-page: https://github.com/getsenic/nuimo-linux-python
Author: Senic GmbH
Author-email: developers@senic.com
License: MIT
Location: /usr/local/lib/python3.7/dist-packages
Requires: gatt
Required-by:

i set up the hub and connected the nuimo but i cannot find a way to update the firmware and there is no popup or something like that :frowning:

Thanks for your effort ! :slight_smile:
I’m curious what they say. What usb BT adapter you use ?

at the moment i use an old logilink adapter. but I already bought a new one which i can test these days.
i will give you a feedback asap.

I use these two:

Both are working well. Sometimes I think the range of the Hama one is slightly better, but I’m not sure. If there is a difference, it’s marginal.

This one will also work

Hi Patrick,

after your presentation on our virtual OH meeting I bought 2 Nuimos which were delivered for the special price - thanks for the information.
After some fiddling around I could succesfully connect the Nuimo and get the demo sitemap working.
I am using the inbuild bluez adapter on my Raspi 4 which is working fine.
In order to separate the 2 Nuimos I changed the bluetooth alias from “Nuimo” to “Nuimo1” in the “bluetoothctl” - command - and that broke the connection to your software.
Question: Is the BT-Alias “Nuimo” somewhere “hardwired” in your programming?

And BTW: I also do not get a value updated in the “Nuimo_BatteryLevel” item.
The BT info profile of the Nuimo shows:
UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
so it seems there is something around.

regards, Gordian

Nice to hear! With the previous Raspberry’s, the connection quality was extremely bad with the built-in adapter, so I hope it’s working better on the RPI 4. If you have a BT adapter, it would be cool if you could compare it with the built-in adapter and report us back how the results are :slight_smile:

Not in mine, but within the Nuimo Python SDK by Senic: https://github.com/getsenic/nuimo-linux-python/blob/master/nuimo/nuimo.py#L40

Anyhow, you don’t have to change the alias to run multiple Nuimo’s, you can distinguish them via their MAC address.

Mhm, don’t know what could be the cause of that.

Thanks for the quick answer…
In order to use 2 Nuimos - I take it that I would have to create a second sitemap and differently named config.yml pointing to the other sitemap and the different MAC address.
How would I start this to run in parallel to the first instance?

You definitely need 2 config files, but not necessarily 2 sitemaps if you want to control the same things with both Nuimo’s.

To have 2 config files and 2 instances of the software, you’d just add a second systemd unit with a different configuration file path. Example:

nuimo1.service:

[Unit]
Description=Nuimo1 openHAB Integration Service
Requires=network-online.target bluetooth.service
After=network-online.target bluetooth.service rsyslog.service openhab.service

[Service]
ExecStart=/usr/bin/python3 /YOUR_PATH_TO_THIS_APP/main.py
Environment=NUIMO_OPENHAB_CONFIG_PATH=/etc/nuimo-openhab/nuimo1.yml
Type=simple
SyslogIdentifier=nuimo1-openhab

[Install]
WantedBy=multi-user.target

nuimo2.service:

[Unit]
Description=Nuimo2 openHAB Integration Service
Requires=network-online.target bluetooth.service
After=network-online.target bluetooth.service rsyslog.service openhab.service

[Service]
ExecStart=/usr/bin/python3 /YOUR_PATH_TO_THIS_APP/main.py
Environment=NUIMO_OPENHAB_CONFIG_PATH=/etc/nuimo-openhab/nuimo2.yml
Type=simple
SyslogIdentifier=nuimo2-openhab

[Install]
WantedBy=multi-user.target

Thanks.
Works prefectly well with 2 Nuimos in parallel as described above

1 Like

Patrick,
regarding the bluetooth connection (bluez using the inbuild BT module of a RPi4): I found the connection to be quite weak - when removing the Nuimo more than 3 m away, it breaks.
I will look for an external USB BT adaptor - could you recommend one?
The other issue is that there is no automatic reconnect if the connection has broken. One has to stop and restart the service to reconnect. Can this be improved (by a regular reconnect job)?

Already posted the ones that I use: Nuimo Integration - #65 by pfink

Anyhow, it won’t be much more than 3m with these (max. 4 I guess). The very safe and stable zone is also just ~2,5m for me. There are may better ones (meanwhile). I just tried these two and a third one + the RPI Zero internal adapter.

In fact there is automatic reconnect. Unfortunately, you have to go quite close to the adapter to ensure the reconnect works. But this has nothing to do with my implementation.

Hello pfink and all others

I managed to spend two evenings making this run due to my own assumptions and not watching the video. Which clearly shows how few and simple steps there actually are. Now that I got it running (hint dont try running the main.py file from the command line while also running the service in the background) I am however left with one problem.

my openhab instance runs in a docker container, which starts apperantly after the service for nuimo has started. Which in turn means that I get the following error that seems to not be handled:

2021-01-25 19:48:20.753 ERROR connection - maybe_handle_message: Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 159, in _new_conn
    conn = connection.create_connection(
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 84, in create_connection
    raise err
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 74, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 387, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib/python3.8/http/client.py", line 1255, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1301, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1250, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1010, in _send_output
    self.send(msg)
  File "/usr/lib/python3.8/http/client.py", line 950, in send
    self.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 187, in connect
    conn = self._new_conn()
  File "/usr/lib/python3/dist-package
s/urllib3/connection.py", line 171, in _new_conn
    raise NewConnectionError(

maybe if this error was issuing a warning and a retry was scheduled it would be more graceful?

other than that thank you for this, i am sure i will get a lot of use out of it

I don’t like this approach as it’s really a fatal error if openHAB is not available on startup. Easiest workaround should be to add

Restart=on-failure
RestartSec=30

to your systemd config.

Yes, thank you for suggesting that, excellent solution.

Hint: On the openHAB 2020 Virtual Meetup I already mentioned a special offering by Senic for users of this integration in case you’re interested in buying a Nuimo. I did not mention it in this thread yet because I wanted to debug a remaining issue with them first, which is done now. So the offer still exist and I added information for it to the first post of this thread :slight_smile:

Hi Patrick,
as mentioned above, I already bought 2 of the Nuimos. What was the issue you mention - did it affect the usage?
Thanks, Gordian

Hi Gordian,
it’s the same one that we discussed already via PN. The issue was that Nuimo just rebooted randomly on usage and it only occured on the newer Nuimo revisions that are sold now by Senic. Anyhow, we cannot reproduce it anymore after I updated to the latest Python and apt dependencies (which I had to due to another issue) and that’s why we didn’t put more efforts into it. Also, I know from some users like you that they already got their Nuimo’s from the sale and they reported that they don’t have this issue.

Hi Patrick,
I struggled for some time because changing into the submenues (swipe up/down) simply didn’t work.
After looking deeper in to the the key mapping provided, I made changes according to the below - now it works without problems.

key_mapping:
# Default mode is mandatory and the initial key mapping after nuimo startup
default:
# The mode can be changed with the MENUE.CHANGEMODE=newmode command. “newmode” must be a mode that is listed in this key mapping
BUTTON_PRESS: “MENUE.CHANGEMODE=menue”
BUTTON_HOLD: “MENUE.SHOWAPP”
BUTTON_CLICK:
- “OPENHAB.Switch.TOGGLE”
- “OPENHAB.CustomSwitch.TOGGLEIFPLAYER” # Workaround making default Player elements work without extra config. Toggles PLAY/PAUSE if it’s a player element.
> SWIPE_UP: “MENUE.PARENT” # changed GS
> SWIPE_DOWN: “MENUE.CHILD” # added GS
> #SWIPE_DOWN: “MENUE.SHOWBATTERYLEVEL” # changed GS to omit battery
SWIPE_LEFT:
- “OPENHAB.CustomSwitch.<<” # Workaround making default Player elements work