Then this is fine, got the same.
Do the same checks on the ESXi, what permission you have there ?
its suddenly seems to connect, but only happens ones. Seems something, after I restarted the server (no power off)
but then the timeout happend again
2024-10-07 23:31:35.250 DEBUG (MainThread) [custom_components.nikobus] Starting setup of the Nikobus integration
2024-10-07 23:31:35.250 DEBUG (MainThread) [custom_components.nikobus.nikobus] Creating Nikobus instance with connection string: /dev/ttyUSB0
2024-10-07 23:31:40.768 INFO (MainThread) [custom_components.nikobus.nkbconnect] Connected to serial port /dev/ttyUSB0
2024-10-07 23:31:40.768 INFO (MainThread) [custom_components.nikobus.nkbconnect] Nikobus handshake successful
2024-10-07 23:31:40.768 INFO (MainThread) [custom_components.nikobus.nkbconfig] Loading module data from /config/nikobus_module_config.json
2024-10-07 23:31:40.790 INFO (MainThread) [custom_components.nikobus.nkbconfig] Loading button data from /config/nikobus_button_config.json
2024-10-07 23:31:40.792 INFO (MainThread) [custom_components.nikobus.nikobus] Nikobus instance created and connected successfully
2024-10-07 23:31:40.792 INFO (MainThread) [custom_components.nikobus.nkbcommand] Nikobus Command Processing starting
2024-10-07 23:31:40.792 INFO (MainThread) [custom_components.nikobus.nkblistener] Nikobus Event Listener starting
2024-10-07 23:31:40.828 DEBUG (MainThread) [custom_components.nikobus.coordinator] Performing initial data refresh for Nikobus
2024-10-07 23:31:40.828 DEBUG (MainThread) [custom_components.nikobus.nikobus] Refreshing data for module address: A72F
2024-10-07 23:31:40.828 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Getting output state - Address: A72F, Group: 1
2024-10-07 23:31:40.828 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Sending command $10122FA7324A64 to address A72F, waiting for answer
2024-10-07 23:31:40.828 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Attempt 1 of 3 waiting for $0512 / $1C2FA7
2024-10-07 23:31:45.829 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Timeout waiting for ACK/Answer on attempt 1
2024-10-07 23:31:50.793 DEBUG (MainThread) [custom_components.nikobus.nkblistener] Read operation timed out. Waiting for next data...
2024-10-07 23:31:50.830 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Timeout waiting for ACK/Answer on attempt 1
2024-10-07 23:31:55.832 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Timeout waiting for ACK/Answer on attempt 1
2024-10-07 23:31:55.832 DEBUG (MainThread) [custom_components.nikobus.nkbcommand] Attempt 2 of 3 waiting for $0512 / $1C2FA7
Thx for your update below, I’m not able to reply anymore (3 replies max limit)
I will give it a try this evening
- Just tried it out, and this is the output now. I will try that restart ones more:
2024-10-08 19:27:22.831 DEBUG (MainThread) [custom_components.nikobus.config_flow] Starting user step with input: {'connection_string': '/dev/ttyUSB0', 'has_feedback_module': False}
2024-10-08 19:27:22.831 ERROR (MainThread) [custom_components.nikobus.config_flow] IP/Port validation error: not enough values to unpack (expected 2, got 1)
2024-10-08 19:27:22.831 DEBUG (MainThread) [custom_components.nikobus.config_flow] Starting options step with input: None
2024-10-08 19:27:24.343 DEBUG (MainThread) [custom_components.nikobus.config_flow] Starting options step with input: {'refresh_interval': 120}
2024-10-08 19:27:24.343 DEBUG (MainThread) [custom_components.nikobus.config_flow] Creating entry with data: {'connection_string': '/dev/ttyUSB0', 'has_feedback_module': False, 'refresh_interval': 120}
2024-10-08 19:27:24.344 DEBUG (MainThread) [custom_components.nikobus] Starting setup of the Nikobus integration
2024-10-08 19:27:24.344 DEBUG (MainThread) [custom_components.nikobus.nikobus] Creating Nikobus instance with connection string: /dev/ttyUSB0
2024-10-08 19:27:35.624 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Nikobus - /dev/ttyUSB0 for nikobus
after the restart the OS(not shutdown) its again communicating a bit better. I will, to be sure, Install the nikobus software again, so I can make sure all addresses are correct. Already much appriciated the help on this! Thx!
Update 8/11/2024 - 22:38
For now all is working fine. Seems the wrong addresses, where causing lots of stability issues, and connectivity issues also.
Thx a lot for helping @fdebrus
Now it seems to be your module address, if you send the wrong module address, Nikobus will not reply to your query.
Have you copy/pasted the module address from openHAB ? then it’s wrong and cannot be used in HA. It has to be the module address you find in the Nikobus software.
So if your module address in openHAB is A72F use 2FA7 in HA.
1 Like
Hi Again, I still see issue with the connectivity, from time to time, I need to restart the server, to have it working again. This is the error I see in the debug logs:
2024-10-08 23:41:02.318 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Nikobus - /dev/ttyUSB0 for nikobus
Traceback (most recent call last):
File "/config/custom_components/nikobus/nkbconnect.py", line 63, in _connect_serial
self._nikobus_reader, self._nikobus_writer = await serial_asyncio.open_serial_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/serial_asyncio/__init__.py", line 504, in open_serial_connection
transport, _ = await create_serial_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/serial_asyncio/__init__.py", line 448, in create_serial_connection
serial_instance = serial.serial_for_url(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/serial/__init__.py", line 90, in serial_for_url
instance.open()
File "/usr/local/lib/python3.12/site-packages/serial/serialposix.py", line 336, in open
self._update_dtr_state()
File "/usr/local/lib/python3.12/site-packages/serial/serialposix.py", line 713, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
OSError: [Errno 5] I/O error
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 594, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/nikobus/__init__.py", line 26, in async_setup_entry
await coordinator.connect()
File "/config/custom_components/nikobus/coordinator.py", line 55, in connect
self.api = await Nikobus.create(self.hass, self._config_entry, self.connection_string, self.async_event_handler)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/nikobus/nikobus.py", line 40, in create
if await instance.connect():
^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/nikobus/nikobus.py", line 48, in connect
if await self._nikobus_connection.connect():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/nikobus/nkbconnect.py", line 34, in connect
await self._connect_serial()
File "/config/custom_components/nikobus/nkbconnect.py", line 66, in _connect_serial
except (OSError, serial_asyncio.SerialException) as err:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'serial_asyncio' has no attribute 'SerialException'
any idea what this could be related to?
Ones this error happens, it also seems not to retry anymore.
OSError: [Errno 5] I/O error
This indicate you cannot reach /dev/ttyUSB0
You have a problem in your setup not related to the intégration. Search on the forum on how to setup USB devices.
It’s normal not to retry as there is a fault in the platform setup
Examples
Try USB2 port vs USB3 if relevant to your case
Many other posts around USB device on VMWare on the forum
I needed to change the controller in vmware ESXI to USB3 in stead of USB2 and it works now without errors.
For reference, and others that might have same issue:
I am using ESXI version 6.7.0 Update 3. The vm is in compatebility mode ESXi 5.5.
Thx Again for all the help. I’m bringing my full installation over to HA
1 Like
We still have a little problem with covers…
At integration starts, as Nikobus does not feedback on cover position, if we set a position for a cover it will not reach intended position.
We need a full run (full open or close) so HA knows about cover position before we can set one.
Options
-
leave as is, setting cover position right after integration starts will fail and cover will be in a random position. setting position will only work after a full close or open when HA become aware of the correct cover postion.
-
Perform a full open or close even if a position has been set, cover will be fully close or open even if we asked for a specific position.
-
Perform a full open or close and then set position, cover will be in the correct postion but it require a full open or close before. It will be managed by the integration, so setting a position of 50%, you will first have a full close or open, then a position setting to 50%
Suggestion ?
I vote for fully open the cover, then set to position.
Fully open the covers at integration start seems to be reasonable for me. Then the integration is in sync with the real position of the covers.
Is there an option to set a default state (if desired) for each defined cover after integration (re)start?
It’s only needed for setting a position right after integration start when cover position is unknown. We do not need this for other scenario’s
Integration starts: Command can be from Nikobus button (except for setting position) or HA.
- Command to fully open; cover will fullly open and HA / Nikobus will then be in sync
- Command to fully close; cover will fullly close and HA / Nikobus will then be in sync
- Command to set a position; cover will fullly open and HA / Nikobus will then be in sync, then position will be set.
I will test this
That could be an option in your module definition ?
{“description”: “myCover”, “operation_time”: “29”, “led_on”:“”, “led_off”:“”,“origin_pos”:“0”},
So at integration start, instead of “unknown” the cover starts with a postion of “origin_pos” which can be anything between 100 fully open and 0 fully closed.
This is not working, I can set a state, but somehow HA revert the state after startup. Reading HA docs…
new release available, it adds an “initial_position” parameter for cover channels,
new release it includes support for HomeAssistant Scene, why ?
If you setup scene, or automation with mutiple nikobus output combined in HomeAssistant. Each nikobus output will be triggered in sequence with a command delay between each.
Custom scene definition will allow the same combination of any Nikobus output but the outputs that belongs to the same module same group will be triggered all at once.
so we will have a new config file: nikobus_scene_config.json with as example
{
"scene": [
{
"id": "scene_turn_on_living_lights",
"description": "Turn on living lights",
"channels": [
{"module_id": "0E6C", "channel":"1", "state":"50"},
{"module_id": "0E6C", "channel":"4", "state":"100"}
]
}
]
}
The scene can be used in HomeAssistant, linked to a button or an automation; etc…
is this example, for module address 0E6C channel 1 will be set to 50 and channel 4 to 100 with 1 command to Nikobus, so no delay between the 2 lights turning on.
that seems to be a good addidtion.
I’ll test it out if i have some spare time left !
Do you have Shutter with button or group that particially open them ? I see a open 6s in your config.
As we know, Nikobus has no feedback on shutter position on the bus. So if you open or close a shutter, the integration always assume you will fully open or close it, unless you send a stop command which will be catched by the integration.
If you have partial open or close in Nikobus, using Nikobus internal timer T1… It will break the sync between Nikobus and HA.
Nothing we can do to prevent this. Nikobus is old tech with no open API / documentation and ZERO feedback on shutter position.
I’m afraid, you are stuck, HA will never manage shutter position correctly in your specific case.
Did it worked under openhab ?
You could migrate this logic to HA. So HA knows when the shutters is operated by 6 seconds.
It’s quite some work:
1- define an automation that open the cover for 6seconds.
2- link all needed physicall buttons to this automation as a trigger.
3- remove this logic from Nikobus.
Basically, the more you manage in HA the better, as the sync between Nikobus and HA is close to impossible in most cases.
All logic, groups, etc… shall be converted to HA and removed from Nikobus.
HA manages all logics, Nikobus executes the command from HA.
Yes, I used to have it in the past but it is not used or linked anymore.
I’ll clean it from the Nikobus conf to make sure it is complete gone.
Today it was the bathroom roller and my bedroom. Both stopping after I press the wall buttons. The other rollers work fine today.
This morning, my bedroom was opened bij the wall button. That was not seen by the integration if I check the app:
As you can see, closed yesterday evening. But the open is not there.
Not much we can do without a debuglog, I’m still running wirh zero issue on covers.
Could you enable debug log in the morning before to operate shutters ? see if we get something.