[Release] Magic Home Wifi (Drivers) + MagicHome Manager (App)

Yes, the 2 devices went offline because I moved the fridge and the power supplies were destroyed so today the new power supply came in, they been like 2 days offline.

I did not have complaints from my wife when the power supplies were destroyed because was her fault I had to move the fridge, I had a sensor on top of it and she pushed it and fall behind the fridge....

1 Like

Thank you!! This is incredibly helpful data.

RIP that power adapter :joy::grimacing:

1 Like

I've been using your driver for a few weeks. The previous version did slow down my hub. .86 is running pretty damn good. I've not "felt" any slow downs, I'm not running any tests or anything but I'm no longer noticing my actions lagging.

But, there's always a "but".. I am having trouble with hue,sat,level settings. I just can't seem to get a good red. If I hit the preset for "fade to red" it looks fantastic. If I set the values manually 100/100/100 the lights just turn off. If I do 99/99/100 I get pink. I'm using the controller RGBW 5-pin device.

Thank you for the excellent work, after spending $100 on Hue and Lightify bulbs it has been immensly gratifying to take $30 and light 15 feet of cabinetry. Keep up the great work, sorry about the "but".

1 Like

I’m glad you’re not experiencing any slowdown!
I’ll see to fixing that :slight_smile:

Here is my bedroom button pushed there are no magic home devices connected to it.

Hey Adam, where you been lately?

Can I use this driver in ST? One of my friends wants led strips and I told him I knew some but not sure how to integrate them in ST.

Thanks

Developing (quietly), and a bit busier with work. :slight_smile: Not dead, I promise. Even though my lights sometimes don't work... :wink:

Not this one. I have another one that I'll send you tonight though. Your friend will need a raspberry pi, too.

1 Like

I don't think the crashes were WebSockets client specific. I've had two WS clients running since my last message in this thread and everything seems to be okay with them.

However, I believe I might have an idea of one of the reasons I have periodic crashes. I related a story here:

I didn't explicitly say why my hub crashed last night but didn't crash every other night. If my last feature request I mention that some log messages take a long time. I was debugging an interface to another vendor's hub using the WS client. Some of the responses from the WS client were pages of JSON and I was logging them in trace.

I have a feeling that either large log message or large amounts of small log messages may be the culprit in at least some of my crashes. Sort of a negative feedback loop too when it starts to slow down. For the most part I am probably more careful than 99% of HE users with my log messages. Sometimes when I'm developing a new driver I have to turn on trace level debugging though and that might be when disaster strikes. I'm going to watch it more closely now.

So, long story short... you can probably feel okay about the WS client.

1 Like

:slight_smile: We’re still looking into it. I’m using an alternative version with Telnet currently (releasing Friday if it keeps working) that doesn’t slow down. I’m using a new protocol of Socket for Hubitat here, so there may be some issues with that.

I’ll also take the logging into account. I’m out traveling this week, so I know I’d better make sure I don’t push any bad code and force the hub down while I’m gone :joy:

3 Likes

Thanks for the warning :rofl:

1 Like

@adamkempenich Adam, I have an RGB light that I'm not able to restore a previous state after capturing. I thought I remembered that you had said this was not possible, so I wasn't surprised it didn't work. But searching this thread doesn't yield any results when I look for that. Is it possible? Thanks!

1 Like

Should be possible. I haven’t experienced that bug on my devices, but I’m also not trying it with an RGB controller.

I’ll take a look into it :slight_smile:

Baby steps here... I know things have been pretty quiet with this driver.

While updating this has taken a while, it looks like we've finally caught the bug that was slowing down hubs with this driver. I've been updating the drivers, cleaning them up to match other platform drivers, and testing them.

There is a new option to choose between telnet or socket. You should use TELNET until Hub update 2.1 is officially released.

Unfortunately, Telnet won't let you refresh data from your device. Socket does, but that's where the bug was hiding.

I'll keep updating this list as time goes on, but the following devices are now on 0.87:


All devices have been updated to 0.87
--> Edit your device settings to use telnet <--
--> Optionally, reboot your hub to ensure all old connections were closed.

WW+CW Bulb drivers will need to be copied/pasted in from GitHub (the importURL was wrong)

4 Likes

0.87 is out. Telnet and new scheduler are fully in and seem robust as can be.

Please, go into each device's settings and change them to use Telnet (see last post).

1 Like

Do I need HE version 2.1 before flipping the Telnet switch?

Nope. For any version of software under 2.1, you should use Telnet.

I see that 2.1 has dropped publicly. Let me run some tests on my end and ensure everything works as expected, and I'll make sure socket is safe to use for y'all :slight_smile:

I'll be traveling for work the next couple of weeks, but each device seems stable and functional. I'll keep working on it, even from the road, but wanted to give a fair heads up that I won't be able to really do any tests for a while.

3 Likes

Just got a chance to check this thread. Any bug reports? :slight_smile:

No time to work on them (long days working here) but I’ll be able to mull them over and fix once I get back next week.

Seems to be working fine on my bulbs.
Thank you so much!

1 Like

Nothing bad to report, all good news here. Thank you for this great driver.

1 Like