v2.04.82 locks up ubisys dimmer #230
Comments
Shouldn't a powercycle be sufficient to get the device back?
To see APS and ZCL traffic
Shouldn't be a problem, the RaspBee firmware doesn't process these and deCONZ doesn't have any limits. Also for the RaspBee the local neighbour table size is >150 :) |
|
Apparently the dimmer got stuck so badly, that it would no longer accept the power cycle sequence to reset. After opening the wall switch and resetting the dimmer using the hardware button (hole), it once again paired with v2.04.82. As a side node, I would really like to be able to update the dimmer's firmware using deCONZ... |
|
I've powered my D1 now, will report back if it also got stuck. I still wonder why it happens, because since 2.04.82 deCONZ won't poll lights when they support reporting. Just found this GitHub link on ubisys homepage https://github.com/ubisys/SmartThings might be handy for further rintegration.
I've downloaded latest 2017 D1 OTA files from their homepage will do a test later on after doing some email stuff. Curios to get it working :) |
|
The Update gets stuck at 0.76%, I've looked in older emails and found the problem was already investigated with ubisys. Problem is the ubisys device requests a larger chunk of data from OTA server than it can send (28 vs. 56 bytes), normally this shouldn't be an issue since the spec allows to send smaller chunks, but the (old) firmware doesn't support that. There were RaspBee firmware versions recently which could send larger packages but these were replaced in favor of source routing firmware for IKEA and OSRAM. I'll check to find an older firmware and if the updates work with it during the days. |
|
Been running .82 for some days now. The GUI showed an occasional red node, but seemed to recover automatically. Only now, my ubisys dimmer is lost again. It shows red in the GUI, won't revive on pressing 0, won't revive on power-cycling the dimmer. When powered, the connected lights are on, but blink off/on once every five seconds. The log shows (filtered on 0x001f): I don't understand where the max transmit errors come from. I only control the dimmer through group commands: recalling a scene to switch the lights on, and setting |
The dimmer is polled by deCONZ core and poll manager but at a very slow rate since attribute reporting is working. I don't know why the dimmer passed out, I don't think it's due polling since this should happen at a much slower rate than older deCONZ versions. Maybe the source routing feature added for OSRAM and IKEA is problematic, perhaps the newer ubisys firmware will fix the problem (on it..) |
|
New firmware in testing, ubisys dimmer OTA update runs but is very slow — 3 % in 5 minutes. |
It would seem my dimmer has serious issues. This time it won't even react to the hardware button (hole). When powered, the connected lights (and the LED next to the hole) are on for five seconds, then switch off briefly, then on again for five seconds... ad nauseatum. I tried leaving the dimmer disconnected completely (including the N wire) overnight, but no change. This sequence is not described in the technical reference - I'll try and contact ubisys support. |
|
Did they have a solution, maybe reset the dimmer? I've also managed to update my D1-R dimmer now, if you wanne give it a shot RaspBee/ConBee requires a different firmware version. $ sudo GCFFlasher_internal -f deCONZ_Rpi_0x261a0500.bin.GCFdeCONZ_Rpi_0x261a0500.bin.GCF.zip My dimmer didn't show any problems, but it's also not actively used other than being a permanent member of the network :) |
|
ubisys support have been very responsive, unfortunately unlike the dimmer itself. I returned it for them to have a look at it. |
|
Would be interesting to know what caused the state and if it can be prevented from the gateway side. |
|
@manup I created a network to update a friends Tradfri bulb to be Hue compatible and it always got stuck at 0.04% (using 0x26190500 firmware and 2.04.84 deCONZ). Tried it multiple times, power-cycled both Raspbee and the bulb and nothing helped. Then I tried the 0x261a0500 firmware you posted here and now it's updating blazingly fast on the first try! |
|
Yes 0x261a0500 allows greater messages to be send which is especially useful for OTA updates. 0x26190500 will be replaced in the next versions. :) |
|
Is there also a firmware version for the ConBee stick? I am trying to update a Tradfri remote and it's been stuck at 0,04% for hours... |
|
You can use the firmware mentioned above |
|
Thanks! I tried it already, but it didn't work because I tried to use the GCFFlasher_internal tool - I had to use the GCFFlasher tool and it worked immediately. I will now try the update again. |
|
GCFFlasher_internal should work, note it is important that deCONZ is not running while updating the firmware. |
|
Hmm - deCONZ was not running. It told me that it couldn't find the device. Also "-l" showed no devices, whereas GCFFlasher worked immediately without any issue. |
|
@DOliana did you manage to update the firmware and upgrade your IKEA remote? |
|
Sorry update was messed up for 0x26190500 (packages are too large which is only supported with firware 0x261a0500 from above). Will be fixed in next release 2.04.88 so that 0x26190500 does work again. |
|
@snozzlebert yes. I updated the firmware using GCFFlasher instead of GCFFlasher_internal. After that it took some time before the update started (had to press update in deCONZ / on the remote a few times). As soon as it started it was done in about 45 minutes. |
Just got the dimmer back with a cryptic note that they reset and “slightly refurbished” the dimmer under warrenty. Haven’t installed in yet. |
|
I guess they might have erased memory and programmed the firmware again. If no hardware defects are present this is the most simple approach to get a device alive again, but sadly delivers not much debug data. |
After updating to 0x261a0500 updating the Tradfri motion sensor succeeded after 45 minutes. |
|
Installed the dimmer and paired it to deCONZ (v2.04.89). It still has the same MAC address. They did update the firmware. The Date Code is now I had some problems recreating the groups and scenes, but it took multiple attempts before as well, storing the scenes from the deCONZ GUI instead of from the REST API. Otherwise, it seems to work as before. Fingers crossed. |
|
Haven't seen any issues with the Ubisys dimmer for almost a month (knock on wood). Closing the issue... |
|
Damn I wonder what happens here :/ if the ubisys is still missing would it be possible to sniff the other channels for > 30 seconds to see if it is on a different channel? Relevant channels: 11, 15, 20, 25. After a power-cycle devices scan all channels to see if the network has wandered usually indicated by higher Later on it would be possible for coordinator to go over all channels and see if devices are wrongly there, bringing them back. Still I wonder why such things happen in first place. |
|
Hi everyone, Been following this thread these past few weeks and have recently decided to take the plunge: bought a D1 and C4 from Ubisys. Seeing the option of adding Ubisys switches in the (old) webapp helped as well ;-) Just installed the C4 today and have two issues. Though the C4 shows up in deCONz (currently 2.04.99), the webapp does not find it when I search for it. Tried resetting it, still the same. Figured I would try to do a firmware update, got the file, update is stuck at various values below 0.77%. Remembered your conversation here, downloaded the firmware version from @manup earlier in this thread, not working either. @ebaauw Did you add the "switch" of the D1 via the webapp or via REST? I'm not exactly proficient neither with code nor with deCONz, so I would appreciate any help possible. |
|
The C4 is not yet whitelisted, so it won’t appear as sensor (switch) in the REST API. If you post some screenshots, showing the node, incl. the enpoints and cluster as well as the details of the basic cluster, I could give it a try. Edit I found the documentation. Will you be using it to control lights or window coverings? I’ve never updated the firmware of my D1 through deCONZ. Indeed it would hang a something like 0.77%. My D1 locked up and I had to send it to ubisys for a factory reset. When they returned it, it had the latest firmware. You should add all devices through the web app, not through the deCONZ GUI, or the REST API won’t see them. The web app uses the REST API to talk to deCONZ, so there’s no difference there. |
Did not know that, explains the fact I can't find it.
Sure, thank you very much! Here are the screenshots:
I plan on using it to control lights, only using the first and second sensors, 3 and 4 are unused.
Hope it will work in time, then. I guess it's in Manuel's hands.
Did not know that either, very interesting piece of information. I did not, however add the device through deCONZ, it juste showed up, figured therefore there might be some way of adding devices through deCONZ GUI. But since then it won't work on the web app, that's of no use. |
|
I think I added support for the C4, but obviously cannot test it. Could you please compile the REST API plugin from my latest commit (see above) and test it? The C4 should be exposed as four sensor resources, one for each endpoint / input / button. The deCONZ web app might support it, sometimes it seems to like my D1.
Edit | Permit Join. In the web app it's Settings | Open Network. |
Been trying it out for a short while now. I am able to add the sensor as follows: Added rules as well, here's one example:
Nope, the web app is not finding the C4. I did hook up my D1 (not yet installed) via 12V to try and add it to the network and it worked flawlessly right away. I should mention I tried it directly in the old web app. |
|
You shouldn’t add any sensor resources, deCONZ should create them, just as for the D1. Maybe you need to reset the C4 and re-pair it, opening the network from the web app. Before that, double-check that you’re running the compiled plugin. It should report |
|
Progress! I was able to add the C4 via the web app after resetting it. I am seeing 6 endpoints which is puzzling: |
|
Can you post what the sensor resources look like? I’ll probably need to exclude the endpoints for controlling the window blinds. I haven’t been able to configure my D1 through the web app, but you can program any action in rules based on the sensor resource’s |
|
Just did a reset and re-added the C4. Was able to assign lights to a button, but they still won't show in the web app as above. Went to the REST client and poked around. Found the following for sensors (keeping in mind I only have the C4 on the network): Checked on the rules as well: I noticed that, when I added my rules manually earlier, the "owner" was my API key, but this time it isn't. Any chance that plays a role? |
|
Quick update: did the bindings between endpoint 1 & endpoint 2 and the two lights I want to control in deCONZ as you suggested. Nothing shows up in the web app, but pressing on the switch twice will trigger each event. Only weird thing: I have to press twice... |
|
If they work like the D1’s inputs, a press/release should toggle the light and a press/hold should alternate between dim up and dim down. That is, of course, if the light supports the corresponding commands. And if you created a binding for the Level cluster for the dim up/dim down. Could you check (easiest is through the web socket) what buttonevent values are generated? It should be a x002 for press/release, and a x001 for hold and x003 for release after hold. X=1,2,3,4 correponding to the input. I never fully understood or used the BIND rules. They don’t exist on the Hue bridge. If you ceate the bindings in the deCONZ GUI, you don’t need them, as far as I can tell. The rule |
Well, the output of the websocket seems to not want to give me the buttonevent values: Tried binding level control of the lights (FLS-PP3) to the according cluster, but pressing and holding does nothing. This, however is just an FYI, not something I want to pursue in this case since I won't be needing dimming functionalities.
Yes, I checked on this and it was indeed the web app that created the rule. |
Yeah, that's the Windows Covering Controller endpoints alright. My latest commit should no longer create ZHASwitch sensor resources for these (you probably need to reset and re-pair the C4 again, after recompiling the plugin).
Bummer. That probably means the C4 sends different ZigBee commands than the D1, at least in its current configuration. I take it, you didn't try and change the C4 configuration (see #360)? Without ZigBee sniffing, this is going to be trial and error, I'm afraid.
What do you mean by "event"? The light going on or off?
You do have a stateless "pulse" switches connected to the inputs, don't you? If you connect a regular light to the switch, it only turns on while you're pressing/holding the switch? |
Indeed, the Window Covering Controller endpoints are now gone in the web app.
No, I did not attempt this. I will give it a try sometime this week and report back.
Exactly. I don't see that there are lights assigned to buttons in the web app, but pressing the buttons twice turns the light on or of.
I'm not an expert, but based on what I've read and seen, my switches (pre-existing, I'm upgrading) are stateful. Could that have an influence on this pressing twice business? |
|
Yes, by default, the D1 is configured for pulse inputs - I guess the C4 is as well. The unit reacts to power dropping from the input. With a stateful switch, the first press/release puts power on the input and the second press/release removes it, so the unit only reacts to the second press/release. With a stateless switch, press puts power on the input, and release removes it again. I think the web app expects the endpoint to be bound to a group and won’t show a single light. Also, if the light and the switch are close to each other and further from the RaspBee, deCONZ might not see the command, causing no |
Ok, so basically, I need to get stateless switches, correct?
Definitely the case in my configuration. RaspBee is on the ground level, the C4 and the lights it controls are upstairs.
Indeed, RaspBee did pick the group command up along with |
That would be the path of least resistance. Alternatively, you could re-configure the C4 and tell it there's stateful switches connected to the inputs, but we haven't figured out how to do that with deCONZ (other than writing your own plugin), see #360.
Cool. If you bind the Level Control cluster to the group as well, you should also get |
Well, I'm planning on upgrading my entire home and just did a quick calculation. Changing the switches would be more expensive than getting the Ubisys gateway to change this without plugin. I guess I will live with double pressing for now, will see how #360 and/or deCONZ evolves. There are some news in the works, as I've read multiple times.
Unfortunately, I did not have any success with this on the C4. Still only get a 1002 I should point out that I just upgraded to 2.05.00. |
Did you create a binding to a group for the Level Control cluster? Note that the (traditional) light(s) connected to the C4 output won't dim.
You're using stateful switches, they probably only change state only on release - holding the key doesn't do anything. Hook up a traditional light to switch to understand how it works: one press/release to turn the light on (i.e. put power on the C4 input), another one to turn the light off (i.e. remove power from the C4 input).
I don't think you're looking at the right switches. You'd need a simple mechanical switch that emits a pulse, typically under EUR 10, not an electronic one that reacts to a pulse, typically well over EUR 50. |
Yes I did. No dice on the 1001 and 1003
Exactly what I attempted and it's pretty much what I got with the D1, but not with the C4. But even when seeing the different
Well, the thing is, I live in Switzerland and there's basically a monopoly of one brand for switches (whichever kind you want). Mostly due to our funny Typ 12 & Typ 13 plugs. Add to this the fact that certain products are more expensive to buy here and I end up with a basic, single Schema 3 stateful switch costing around EUR 25 and a 3-way in-wall outlet costing about EUR 42. So it actually does not surprise me that a simple combination of a dual mechanical switch with one power outlet that is compatible with said manufacturer's program (e.g. built by them) is actually quite expensive. For the reference, here is the link to said switch on the manufacturer's website (sorry, they don't have an englisch website): https://online-katalog.feller.ch/kat_details.php?fnr=87063.AR63AR.FMI.61 and here's the price of it on a reseller's website: https://www.elektrogut.ch/em/kleinkombinationen/ediziodue/unterputz-up/taster_steckdosen/baukasten/ediziodue-einsatz-kleinkombination22.html. To be fair, I should mention that the price is only for the insert module and its small covers, no VAT and no shipping. Add to that the aluminium frame behind it for mounting and the cosmetic frame (already have those, fortunately) and then you've a complete switch. Don't yet know what I will do, but for now I will live with the double-tap on my switches... |
|
Just wanted to give a short update. I have bought a stateless switch and just replaced it today in combination with my C4. Works like a charm, pushing once turns the light on, pushing a second time turns it off. Thanks for the help @ebaauw. Now I just have to invest for the rest of my home... |
|
As we’re giving updates. I haven’t had any issues with my D1 since ubisys support updated its firmware. Knock on wood. |
v2.04.82 seems more stable than previous versions, but somehow my ubysis D1 dimmer dropped off the network. This had happened before, with earlier versions, typically when the network would lock up. After a factory reset the dimmer would re-pair. However, the dimmer won't pair with v2.04.82. It makes the connected lights blink steadily when power is applied (meaning it's searching for a network to join, according to the reference manual). When opening the network in the deCONZ web UI, the blink pattern changes, like it's trying to join the network and failing. After closing the network, the steady blink pattern is resumed.
I don't see the dimmer's MAC address in the deCONZ log with --dbg-info=2. What logging would I need to enable to see what's going on?
According to its documentation, the dimmer supports up to 78 entries in its neighbour table and up to 96 entries in its routing table. Could this be causing buffer overflows in deCONZ or in the RaspBee firmware?
The text was updated successfully, but these errors were encountered: