I’m seeing the same thing. I’ll fix it ASAP.
I pushed an update that fixes the compatibility with the latest version of the Smartfriends hub. Upgrade to version 3.8 and your problem should be fixed.
Lightning fast - working beautifully again. Great work & thanks for making this possible for all of us!
Just updated the addon, but still not working. Any idea?
[1],"R#5#2":[0],"R#5#4":[1],"R#5#512":[1],"R#5#8":[0],"R#5#8192":[0],"R#500#1":[1],"R#500#2":[1],"R#500#4":[0],"R#500#8":[0],"R#6#1":[0],"R#6#16":[1],"R#6#2":[0],"R#6#4":[1],"R#6#8":[0],"R#7#1":[0],"R#7#2":[0],"R#7#4":[1],"R#7#8":[0]},"timestamp":20230525130428,"userOrGroup":36495}}},"responseCode":1,"responseMessage":"success"} fail: SmartFriends.Api.Session[0] Refresh failed null System.Threading.Tasks.TaskCanceledException: A task was canceled. at SmartFriends.Api.Client.SendCommand(CommandBase command, Boolean skipEnsure, Int32 timeout) in D:\Projects\smartfriends-bridge\source\SmartFriends.Api\Client.cs:line 175 at SmartFriends.Api.Client.SendAndReceiveCommand[T](CommandBase command, Int32 timeout) in D:\Projects\smartfriends-bridge\source\SmartFriends.Api\Client.cs:line 138 at SmartFriends.Api.Session.RefreshDevices() in D:\Projects\smartfriends-bridge\source\SmartFriends.Api\Session.cs:line 136
The task cancelled error is a timeout. Your SmartFriends box didn’t respond or didn’t respond with the expected message. Double check your setup. The version and api numbers changed so update them. Although I didn’t see a difference but maybe there is.
It’s a holiday weekend where I am, I can take a closer look on Tuesday. Any more logs would be helpful. Does the REST Interfaxe work at all?
It’s still very strange behavior. The Shc version of Smartfriends has just been increased again - 3.4.5. I entered this in the configuration. Still the same result: Nothing can be controlled after launching the add-on. The log output remains the same.
BUT (in version 3.4.4): After some time (I didn’t follow it closely), the devices can be controlled. Calling up via http:/haip:5001/list also shows the devices. But it tooks a very long time.
Normally (before the version jump to 3.4.4) the devices were available right after the start.
my config:
Host: 192.168.0.68
Port: 4300
Username: ha
Password: *****
CSymbol: D19033
CSymbolAddon: i
ShcVersion: 3.4.5
ShApiVersion: “3.3”
Logfile → https://flog.duckdns.org/s/oToZQwHJoFW3BDW/download/ha.txt
Update: after about 15 minutes the devices were displayed.
Those are timeout problems, meaning your hub isn’t responding fast enough.
The SF hub doesn’t seem to handle multiple simultaneous requests very well. Basically you send a request and if you wait for a response it is difficult to know which response is from your request. It is easier when there are no problems but if there is you just get a generic error message and you have no idea which request resulted in the error response. Originally I was just waiting on the next response and hoping that would be for the request. I changed it a little bit so there is no waiting for any response and just process the messages mostly disconnected from the request. There still has to be some waiting because the login process is multiple hand shakes.
Theoretically I could just ask for the status of every device once on start then use the new device value events to stay up to date. In reality those events aren’t reliable. They might send a blind is moving but not send the new position once it stopped. Maybe it’s better in the latest version but originally it was really bad. To keep the connection open there needs to be a keep alive sent. What I do is instead of the standard keep alive, I just keep asking for the status of all the devices to catch all the real changes. This is where you’re running into problems. This operation needs to wait on its response, I have a 5 second timeout for this and your hub is taking more than 5 seconds to respond. Timeouts are a double edge sword, too low and you timeout from basic network hiccups but too high and it’s hard to catch real failures and you may lose data.
All that said, I pushed a new version that handles this request/response a little better (hopefully). Handling that better should give the requests that need to wait on a response some breathing room, like so another request doesn’t stealing it’s response that it is waiting on. If this does not work then I can change this status check to be fully independent of the response so there will be no timeouts BUT doing that means I have no idea if the hub actually isn’t responding. So I’ll have to do something like “if there are no status updates for 5 minutes then declare the hub offline.” So if the connection gets lost or something it will be a lot longer before I can automatically recover it.
1 Like
Now works as expected!
Thank you for your fast support!
Great, I was really hoping I wouldn’t have to change more to get it working for you.
Hi,
i already open a Issue.
My Schellenberg covers are not working anymore since i updated to 3.9.
But also restoring to 3.8 doesn´t help.
Maybe someone can help.
But as i found now you have 2 projects for Smart Friends
1.) hassio-addon
2.) smartfriends-bridge
i don´t know the difference, and now i am not shure which one i am using.
I installed it as an Add-On so i think that it is the 1.)
But the issue i wrote you will find under 2.).
So i hope that you can help me.
Here is the Add-On Log
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
info: SmartFriends.Mqtt.MqttClient[0]
Loaded 2 devices to map.
info: SmartFriends.Api.Session[0]
Connecting to 192.168.178.63
info: SmartFriends.Api.Session[0]
Logging in as homeassistant
info: SmartFriends.Api.Session[0]
Logged in to SmartFriendsBox
info: SmartFriends.Mqtt.MqttClientService[0]
MQTT StartAsync method called.
info: SmartFriends.Mqtt.MqttClient[0]
Client Connected to mqtt://homeassistant:1883
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://0.0.0.0:80
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: /opt
info: SmartFriends.Mqtt.MqttClient[0]
Received 'smartfriends2mqtt/sf_11291/rollingShutter/set': Down
info: SmartFriends.Mqtt.MqttClient[0]
Received 'smartfriends2mqtt/sf_11291/rollingShutter/set': Stop
info: SmartFriends.Mqtt.MqttClient[0]
Received 'smartfriends2mqtt/sf_11291/rollingShutter/set': Up
I found a solution by myself.
The Id has changed.
[
{
"id": 19322,
"name": "Rollo",
"room": "LivingRoom",
"gatewayDevice": "SmartFriendsBox",
"kind": "RollingShutter",
"manufacturer": "Alfred Schellenberg GmbH",
"state": 1,
"devices": {
"rollingShutter": {
"Id": 11291,
"description": "SchellenbergRadioMotor_Unidirectional",
"commands": {
"Stop": 0,
"Up": 1,
"Down": 2
},
"currentValue": 1
}
}
},
{
"id": 4081,
"name": "Rolladen",
"room": "Badezimmer",
"gatewayDevice": "SmartFriendsBox",
"kind": "RollingShutter",
"manufacturer": "Alfred Schellenberg GmbH",
"state": 1,
"devices": {
"rollingShutter": {
"Id": 10114,
"description": "SchellenbergRadioMotor_Unidirectional",
"commands": {
"Stop": 0,
"Up": 1,
"Down": 2
},
"currentValue": 1
}
}
}
]
i dont know why, but before there where no 2 different Id´s
The first cover has id “19322” and “11291”.
Before ist only has the “11291”.
Now i changes to “19322” and it works again.
Same with the second cover.
Changing 10114 to 4081 in the “deviceMap.json” did the trick.
Hope it helps someone.
Glad you figured it out. I bet it was the SmartFriends hub upgrade. The IDs are controlled by the hub and my bridge just forwards them. Some day I might make a web GUI for easier configuration where you could see such changes.
FYI about the repos
1.) hassio-addon → This is the repo for downloading and installing the add-on. There is no code just home assistant add-on configs. This also contains the files for building the docker container which HA runs.
2.) smartfriends-bridge → This is the actual code but contains only a release zip of the binaries. You could compile it yourself from here or download the release binaries and run it without HA.
Why do I have 2 repos? Because the hassio-addon has a required structure so the add-on store can read it and that structure does not fit the project or release cycle very well in my opinion.
1 Like
Hi, with the Last HA Version 2023.08 comes a change in name conventions belonging to MQTT. At the Moment it is only a notice but will change in HA 2024.02.
Did you plan to bring an update according to this changes?
Yes, I will be fixing it as soon as I have some time. My understanding is that it should be a rather small change, probably just delete a line of code.
Hi, thank you for your answer.
Yes i also understand that ist is only a small change, and there is enough time left.
Greetings
I just released version 3.10 with the MQTT entity name removed.
Thank you for the quick Solution.
Updated and works.
Hi @GimpArm ,
I have recently started having problems with your addon. My rolling shutters do not want to move via Home Assistant. As soon as I execute the corresponding command in the browser, I only get false. I have already checked the IDs and reinstalled the addon. In the Smart Friends App everything works fine.
What can I do?
Seeing your logs would help. Put them up at pastebin.com and show me the link. Also a copy of the output of /raw would help.
Aside from that make sure you have the correct values for all the settings like CSymbol, CSymbolAddon, ShcVersion, and ShApiVersion
I also make sure to have a different user configure for the addon than what I use for the app. This user doesn’t need administrator access.
I managed to solve the problem myself. There was an update on the Smart Friends Box and then everything worked again…
Thanks anyway.