Noted, Is it the driver issue?
I have contacted the seller to send me the latest driver
My both H801’s are going crazy with log message in “Super Lan Connect”.
Any one has any idea what’s happening? or how can I stop it?
37825957-69d1-436d-b46a-38cf394d9ebb 9:16:37 AM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:37 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e6237111 in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F237111, networkAddress:C0A8019A, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e6237111, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:36 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:36 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
37825957-69d1-436d-b46a-38cf394d9ebb 9:16:34 AM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:34 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e6237111 in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F237111, networkAddress:C0A8019A, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e6237111, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:33 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:33 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:32 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:32 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
37825957-69d1-436d-b46a-38cf394d9ebb 9:16:30 AM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:30 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e6237111 in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F237111, networkAddress:C0A8019A, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e6237111, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:29 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:29 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:26 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:26 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
37825957-69d1-436d-b46a-38cf394d9ebb 9:16:26 AM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:26 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e6237111 in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F237111, networkAddress:C0A8019A, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e6237111, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:22 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:22 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
37825957-69d1-436d-b46a-38cf394d9ebb 9:16:21 AM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:21 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e6237111 in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F237111, networkAddress:C0A8019A, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e6237111, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
cdd5438c-71b7-4f04-a914-8965422de8d9 9:16:19 AM: debug Device data: (192.168.1.155:80) - reporting data: (192.168.1.155:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:19 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e623733c in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F23733C, networkAddress:C0A8019B, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e623733c, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
37825957-69d1-436d-b46a-38cf394d9ebb 9:16:18 AM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
91a5a34b-ec9c-471c-be63-b006bfa7cee9 9:16:18 AM: trace Received message from uuid:38323636-4558-4dda-9188-cda0e6237111 in ssdpHandler, parsedEvent: [devicetype:04, mac:5CCF7F237111, networkAddress:C0A8019A, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:38323636-4558-4dda-9188-cda0e6237111, ssdpTerm:urn:schemas-upnp-org:device:Basic:1, ssdpNTS:null, hub:f6c012fd-302d-42fd-983b-c257740b9f5e]
If I turn off both H801’s this log message stops, as soon as I connect them, they go crazy. fill up all the log message.
I am using latest device driver,smart app code and firmware binary. In fact just to be sure, I did all upgrade once more today.
Hemanshu
Yes, it is basically ping commands sent from the H801s to SmartThings. They are probably a bit more frequent than they need to be, but they are there to ensure that device status remains accurate. You can easily filter for the correct device so it hopefully doesnt matter too much, but if it bothers you then you can remove the trace command out of the device (just put a // at the start of line 644 in the smart app when logged into your SmartThings portal - This is the location in the SmartApp https://github.com/erocm123/SmartThingsPublic/blob/master/smartapps/erocm123/smartlife-rgbw-light-connect.src/smartlife-rgbw-light-connect.groovy#L644 )
Oh man, when I read your message I was thinking hundreds of messages a minute (not one or two every couple of minutes). Yeah, what you are seeing is normal.
Sorry.
But they are more than one.
On average I’m receiving one per 3-6 seconds from the datetime value in log.
Here’s just the time portion from the logs from just one H801
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:37 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:37 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:36 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:32 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:32 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:30 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:28 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:26 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:25 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:24 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:21 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:21 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:18 AM
91a5a34b-ec9c-471c-be63-b006bfa7cee9 10:41:15 AM
Unless something has changed with the ssdp library, it should only be sending out broadcasts every few minutes.
Mine also sends every few seconds and I’m on firmware from February. Doesn’t bother me as i always filter the logs by device but it’s not just him. Can’t imagine it has an adverse effect on anything as very low processing overhead.
What does the log for SmartLife (Connect) report? I am using a newer firmware, but both super Lan and SmartLife (Connect) are showing every few minutes an ssdp broadcast.
Here’s log from one of the two.
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:54 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:52 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:50 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:46 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:43 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:39 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:21:35 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
37825957-69d1-436d-b46a-38cf394d9ebb 12:20:21 PM: debug Device data: (192.168.1.154:80) - reporting data: (192.168.1.154:80).
I have a question about the huesatToRGB function in the DH. I’m using google assistant and it seems it is sending hue and saturation to define colors I name. For example, when I tell my aquarium to change to ‘fuchsia’, I see hue: 83 and sat: 55. Google is clearly sending the hue on a 0-100 scale (instead of 0-360). The DH seems to treat the hue as if it were on a 360 scale. Because of this; when the huesatToRGB function translates the hue/sat to rgb, it comes up with a color close to #c9ff73. This color should be closer to #fc73ff (basically lime green vs hot pink… not even close). In general, the math in the huesatToRGB function happens to work with a hue on a 100 scale instead of 360 but sometimes it just fails spectacularly.
I’d like to suggest (unless there is a specific reason for the math you have now) an updated huesatToRGB function based on the following calculations:
http://www.rapidtables.com/convert/color/hsv-to-rgb.htm
It seems to work for me… my question is… does anything pass the DH a hue based on a 360 scale? At any rate here is what I’m using now:
def huesatToRGB(float hue, float sat) {
if (hue <= 100) {
hue = hue * 3.6
}
sat = sat / 100
float v = 1.0
float c = v * sat
float x = c * (1 - Math.abs(((hue/60)%2) - 1))
float m = v - c
int mod_h = (int)(hue / 60)
int cm = Math.round((c+m) * 255)
int xm = Math.round((x+m) * 255)
int zm = Math.round((0+m) * 255)
switch(mod_h) {
case 0: return [cm, xm, zm]
case 1: return [xm, cm, zm]
case 2: return [zm, cm, xm]
case 3: return [zm, xm, cm]
case 4: return [xm, zm, cm]
case 5: return [cm, zm, xm]
}
}
Another question with the DH is on lines 463 - 465. Is the reason you are truncating the RGB values below 40 (0x28) just due to the inaccuracy of color found in most RGB strips… it’s a pretty ingenious hack if so… if not… what’s it for?
It’s random but typically mine are showing up a couple, three times per minute but not every minute because sometimes a minute or two break between polls.
That is what I see as well (which is what I expect).
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:46:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:43:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:41:16 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:38:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:36:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:33:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:31:16 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:28:18 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:26:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:23:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:21:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:18:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:16:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:13:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:11:16 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:08:18 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:06:16 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:03:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 10:01:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:58:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:56:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:53:18 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:51:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:48:18 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:46:16 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:43:18 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:41:16 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:38:19 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:36:15 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:33:18 AM:
d9f90b06-3854-4ba6-be78-7e3ef0fe6f80 9:31:16 AM:
I would recommend that anyone that is seeing this try the following in order (if it is bothering them):
- reboot H801
- reboot AP / Router
- reboot SmartThings Hub
I actually got that method from SmartThings (like most of my color conversion methods). I will test out your proposed changes, but seems good to me.
As for the truncating, I am mostly trying to achieve a more “pure” color before scaling the color and adjusting it for the current level (if I remember correctly). It has been a while since I implemented it so not sure how much of a necessity it is.
Makes sense. I’m going to try and implement that function to ncorporate the current level into the calculation.
My guess is the Phillips Hue bulbs have a weird color skew that this function works with… or, really, reading some of the smaratthings postings, the hex value is kind of just ignored in most places as zigbee seems to use hue and sat directly and not rgb.
Another thing I’m working on is an external program controller that tracks the location of the sun in the sky and calculates the rgb values of the sunrise/sunset… it’s a 24 hour long program that changes its transition times. So, the program function in the firmware won’t work to “program” this. (I actually already have this setup and running through an Arduino controlling the LED strip but want to add it to ST). I guess what I really need is some toggle variable that the program can check in the JSON API to see if it should update the color to the new sunrise/sunset color or if I’m running a different color scheme through ST (and a way to update that variable on/off in ST). I was thinking of using one of the config values (like default color or something) but can I control those like an on off switch?
I cannot get the SmartLife app to discover the device. I flashed the h801, it was sucessful. I Connected to it, got the box that showed to configure it. I selected my network, entered the password, and a few seconds later the box disapeard. I can no longer see the device in my available network connections. Is this normal? Any other advice?
You might try to reset the wifi settings.
Modified instructions from post #194 by erocm1231
The firmware has two methods of accomplishing a factory reset.
Method 1.) This method requires you to cycle power on the H801. The H801's green terminal blocks can be easily unplugged from the H801 while leaving any field wiring intact. So this is an easy way to cycle the H801 power by unplugging the green terminal block where your 12v power is connected. . Unplug controller and plug back in. Within 2 - 5 seconds after plugging in, unplug and plug back in. Repeat this process 4 times. You can know you are doing it correctly because on the second plug in the LED Strip will light up GREEN, the third it will light up BLUE, and the fourth it will light up RED. After it turns RED, you can just leave it alone. The little red led will blink 5 times slowly and then the RED LED strip will start to flash as the storage is being wiped.
Method 2) After the device is turned on, jump J3 for a) between 10-20 seconds will reset the WiFi. If you reset the wifi correctly the little RED LED will blink 3 times quickly. b) between 20-60 seconds will reset everything. If you reset all the device settings correctly the little RED LED will blink 5 times slowly.
@erocm1231 what IDE and Framework are you using to create the firmware? Is it platform.io, arduino, etc? Do you have the source ino anywhere?
Sorry, I don’t know for certain. Just that lots of reports around that particular model with the “05” printed on back being less than reliable updates
I would do like @daved314 suggests and do a reset if you can’t access it from the IP address. It is possible you entered the credentials incorrectly so it isn’t connecting to anything so a reset can fix that.
Have you checked if your H801 is listed in your router list of connected devices?