Hi @PunchCardPgmr
Just something you probably already know but if you highlight the logs and then click on the </> symbol it puts the highlighted text into it's own 'block' which can be scrolled up and down.
It keeps the post smaller. 
1 Like
Good suggestion from @bobbles. Also, sometimes, a screenshot of the logs is easier to read than a cut & paste of text.
2 Likes
Ahhh, no didn't know that trick yet.
Thanks.
Edit: OK guys, call me blind or old....either works, but I'm not getting the cut html block step you described.
Whoops, nevermind....got it.
dev:2562022-02-20 13:13:20.549 errorjava.lang.NumberFormatException: For input string: "228.03" on line 268 (method parse)
dev:2562022-02-20 13:13:20.541 traceLUM28D : processMap() : [raw:9BFA0104000A000021565E, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:5E56, clusterInt:1024, attrInt:0]
Oh man, watch out boys...old dog learns new tricks !
3 Likes
Oh, I see what's happening here - thank you for the debug and trace logs, that's the ticket! We've fixed one problem and bumped into the next, caused by the previous driver, I believe.
You were using Markus's driver before? Regardless, whichever driver it was reported the lux values with a decimal point, which is incompatible with what's expected in HE. This previous lux value was retained even when the driver is switched and caused updating of the lux reading on my driver to fail as the variable types are not the same.
All this is a longwinded way of saying "try v1.09". It should deal with the issue by resetting the previous value to zero when receiving a decimal lux reading. If for some reason it errors out again, hit Configure one more time and the illuminance values should be forcibly reset to zero.
4 Likes
Whoohoooo !!! Now we're talkin !
Thanks!
Now you're going to be sorry you got this working on mine as I come up with a short list to get this to quiet down to less frequent reporting and work only on a delta/threshold, and do so quickly enough to catch the flash of a flashlight or headlights passing through the sensor's field of view. From what I have seen so far I think I had too high an expectation for that.
Thanks a bunch for sticking with this for me. Such a good feeling to not have this have been a waste of time and money. Not to mention the collegial collaboration of folk across the pond to make it work! Great stuff in this Community.
----------------for your full cycle look back---------------------------
Leaving you the log from the last lux posting from that other driver (Markus spinoff) through the change over to yours.
dev:2562022-02-21 09:50:26.809 debugLUM28D : Lux : Darkening from 8 to 7 lux.
dev:2562022-02-21 09:50:26.806 traceLUM28D : processMap() : [raw:9BFA0104000A0000214723, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2347, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:50:26.804 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:50:26.801 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214723, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4723
dev:2562022-02-21 09:50:02.046 traceLUM28D : checkPresence() : Report interval is 3600000 ms, timeout is 8400000 ms.
dev:2562022-02-21 09:50:02.044 traceLUM28D : checkPresence() : 1645462202025 - 1645462137193 = 64832
dev:2562022-02-21 09:50:02.042 debugLUM28D : Presence : Last presence report 64 seconds ago.
dev:2562022-02-21 09:48:57.212 debugLUM28D : Lux : Brightening from 7 to 8 lux.
dev:2562022-02-21 09:48:57.201 traceLUM28D : processMap() : [raw:9BFA0104000A0000214725, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2547, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:48:57.198 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:48:57.196 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214725, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4725
dev:2562022-02-21 09:48:27.328 debugLUM28D : Lux : Darkening from 8 to 7 lux.
dev:2562022-02-21 09:48:27.325 traceLUM28D : processMap() : [raw:9BFA0104000A0000214723, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2347, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:48:27.322 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:48:27.320 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214723, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4723
dev:2562022-02-21 09:47:42.517 debugLUM28D : Lux : Variance of 0 (previously 9543, now 9543) is within tolerance.
dev:2562022-02-21 09:47:42.515 traceLUM28D : processMap() : [raw:9BFA0104000A0000214725, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2547, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:47:42.512 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:47:42.510 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214725, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4725
dev:2562022-02-21 09:46:12.840 traceLUM28D : Splurge! : [raw:catchall: 0000 0006 00 00 0040 00 9BFA 00 00 0000 00 00 DDFDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DD, FD, FF, 04, 01, 01, 19, 00, 00]]
dev:2562022-02-21 09:46:12.838 warnLUM28D : Received : endpoint: null, cluster: null, clusterId: 0006, attrId: null, command: 00 with value: null and 9 bits of data: [DD, FD, FF, 04, 01, 01, 19, 00, 00]
dev:2562022-02-21 09:46:12.836 warnLUM28D : UNKNOWN DATA! Please report these messages to the developer.
dev:2562022-02-21 09:46:12.829 traceLUM28D : processMap() : [raw:catchall: 0000 0006 00 00 0040 00 9BFA 00 00 0000 00 00 DDFDFF040101190000, profileId:0000, clusterId:0006, clusterInt:6, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DD, FD, FF, 04, 01, 01, 19, 00, 00]]
dev:2562022-02-21 09:46:12.827 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:46:12.825 traceLUM28D : parse() : catchall: 0000 0006 00 00 0040 00 9BFA 00 00 0000 00 00 DDFDFF040101190000
dev:2562022-02-21 09:45:43.015 debugLUM28D : Lux : Darkening from 14 to 8 lux.
dev:2562022-02-21 09:45:42.999 traceLUM28D : processMap() : [raw:9BFA0104000A0000214725, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2547, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:45:42.996 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:45:42.994 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214725, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4725
dev:2562022-02-21 09:45:13.056 debugLUM28D : Lux : Brightening from 10 to 14 lux.
dev:2562022-02-21 09:45:13.053 traceLUM28D : processMap() : [raw:9BFA0104000A000021F12D, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:2DF1, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:45:13.050 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:45:13.048 traceLUM28D : parse() : read attr - raw: 9BFA0104000A000021F12D, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: F12D
dev:2562022-02-21 09:44:43.182 debugLUM28D : Lux : Brightening from 0 to 10 lux.
dev:2562022-02-21 09:44:43.179 traceLUM28D : processMap() : [raw:9BFA0104000A000021AE28, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:28AE, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:44:43.176 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:43.174 traceLUM28D : parse() : read attr - raw: 9BFA0104000A000021AE28, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: AE28
dev:2562022-02-21 09:44:17.239 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:17.236 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 2100, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[21, 00]]
dev:2562022-02-21 09:44:17.234 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:17.232 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 2100
dev:2562022-02-21 09:44:15.112 infoLUM28D : Configuration : Received by device.
dev:2562022-02-21 09:44:15.105 traceLUM28D : processMap() : [raw:catchall: 0104 0001 01 01 0040 00 9BFA 00 00 0000 07 01 00, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
dev:2562022-02-21 09:44:15.102 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:15.101 traceLUM28D : parse() : catchall: 0104 0001 01 01 0040 00 9BFA 00 00 0000 07 01 00
dev:2562022-02-21 09:44:13.645 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.642 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1E00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1E, 00]]
dev:2562022-02-21 09:44:13.640 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.638 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1E00
dev:2562022-02-21 09:44:13.505 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.502 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1D00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1D, 00]]
dev:2562022-02-21 09:44:13.500 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.498 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1D00
dev:2562022-02-21 09:44:13.475 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.472 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1C00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1C, 00]]
dev:2562022-02-21 09:44:13.470 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.468 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1C00
dev:2562022-02-21 09:44:13.240 debugLUM28D : Skipped : Bind Response
dev:2562022-02-21 09:44:13.237 traceLUM28D : processMap() : [raw:catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1B00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9BFA, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[1B, 00]]
dev:2562022-02-21 09:44:13.234 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:13.232 traceLUM28D : parse() : catchall: 0000 8021 00 00 0040 00 9BFA 00 00 0000 00 00 1B00
dev:2562022-02-21 09:44:12.967 traceLUM28D : Trace Logging : true
dev:2562022-02-21 09:44:12.966 debugLUM28D : Debug Logging : true
dev:2562022-02-21 09:44:12.965 infoLUM28D : Info Logging : true
dev:2562022-02-21 09:44:12.964 infoLUM28D : Preferences Updated
dev:2562022-02-21 09:44:12.905 infoLUM28D : Configuration : Hub settings complete.
dev:2562022-02-21 09:44:12.844 traceLUM28D : sendZigbeeCommands received : [zdo bind 9BFA 0x01 0x01 0x0000 {54EF4410000C218C} {}, zdo bind 9BFA 0x01 0x01 0x0001 {54EF4410000C218C} {}, zdo bind 9BFA 0x01 0x01 0x0003 {54EF4410000C218C} {}, zdo bind 9BFA 0x01 0x01 0x0400 {54EF4410000C218C} {}, zdo bind 0x9BFA 0x01 0x01 0x0001 {54EF4410000C218C} {}, delay 2000, he cr 0x9BFA 0x01 1 32 32 3600 3600 {} {}, delay 2000, zdo bind 0x9BFA 0x01 0x01 0x0400 {54EF4410000C218C} {}, delay 2000, he cr 0x9BFA 0x01 1024 0 33 3 3600 {C800} {}, delay 2000]
dev:2562022-02-21 09:44:11.864 infoLUM28D : Trigger : Button Pressed
dev:2562022-02-21 09:44:11.861 traceLUM28D : processMap() : [raw:catchall: 0104 0003 01 FF 0040 00 9BFA 01 00 0000 01 00 , profileId:0104, clusterId:0003, clusterInt:3, sourceEndpoint:01, destinationEndpoint:FF, options:0040, messageType:00, dni:9BFA, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:00, data:[]]
dev:2562022-02-21 09:44:11.858 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:11.857 traceLUM28D : parse() : catchall: 0104 0003 01 FF 0040 00 9BFA 01 00 0000 01 00
dev:2562022-02-21 09:44:08.354 debugLUM28D : Lux : Darkening from 100 to 0 lux.
dev:2562022-02-21 09:44:08.343 traceLUM28D : processMap() : [raw:9BFA0104000A0000210000, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:0000, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:44:08.340 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:44:08.338 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000210000, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 0000
dev:2562022-02-21 09:43:38.495 debugLUM28D : Lux : Brightening from 0 to 100 lux.
dev:2562022-02-21 09:43:38.482 traceLUM28D : processMap() : [raw:9BFA0104000A0000214C4E, dni:9BFA, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:4E4C, clusterInt:1024, attrInt:0]
dev:2562022-02-21 09:43:38.469 debugLUM28D : Parse : Processing against Zigbee cluster specification.
dev:2562022-02-21 09:43:38.466 traceLUM28D : parse() : read attr - raw: 9BFA0104000A0000214C4E, dni: 9BFA, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 4C4E
dev:2562022-02-21 09:43:35.383 traceLUM28D : Trace Logging : true
dev:2562022-02-21 09:43:35.382 debugLUM28D : Debug Logging : true
dev:2562022-02-21 09:43:35.380 infoLUM28D : Info Logging : true
dev:2562022-02-21 09:43:35.379 infoLUM28D : Preferences Updated
dev:2562022-02-21 09:42:33.738 infoLUM28D: Illuminance is 101.02 lux
1 Like
Questions:
- Can the device be told to only report upon reaching a delta value from current value (or recent average). In my case I might not care to hear from the device unless say a 25 point increment or decrement has been indicated.
This appears to be discussed in this other thread from this point down:
- Experimenting I have seen the device screen update the lux value in as short as about 8 seconds and as high as about 15 seconds. What do you all know about what may be going on within the device with respect to sampling rate, and reporting. Do you think it is seeing every little flash (increment/decrement) and then either sending on a fixed sampling rate, waiting for stability, or averaging across a period.
I'm also a little confused by this discussion, when I had this driver in there I didn't see these interval settings having any effect:
I bring these questions up seeking to understand if everything that can be orchestrated on board this device is being taken advantage of.
Why?
Well, I realize most are using these devices to sense not-so-brief instances of lux changes dawn/sunset transitions, daylight, overcast, or even approximating cumulative luminance (i.e. light exposure per day in a greenhouse)... and step changes like lights being on.
BUT WHAT IF these could be used as preemptive or corroborating security alerts along with other sensors. Think of them like motion sensors for light. For example, picking up the brief flash of headlights down a drive, shining onto a building, or at gate at a time there shouldn't be (ignore having to deal with lightening for now but even that is an interesting application in itself, i.e. "flash counter"). Or how about triggering on a flashlight beam "spuriously illuminating" the interior of a building where complete darkness is the norm between hours x to y.
Yes, I hit that problem when I first tried to use them in a Rule. I set the "number of decimals" setting to 0. Later on I changed away from that driver.
1 Like
@birdslikewires Do you know if this driver works with the similar looking Xiaomi Mi light sensor? People have reported not being able to get them to work in this other thread:
(Especially since the Mijia light sensor seems discontinued)
Well, yes, in theory - though in practice it's something I'd prefer to avoid dealing with in the driver. My take on a driver is that the device should report in with the best, most accurate and timely data that it can and only "degrade" this if it clearly has a negative impact, say on the battery life of the device, or if the device needs "debouncing" in way that can't be handled by its firmware.
In this instance I'd say the delta is best dealt with in an app or rule. That way end users can have rules which are very responsive and ones that are more tolerant, all running from the same device.
As these are powered by one CR2450 cell my guess is that there's a sample-compare-transmit-sleep cycle going on. I think we're already at the limit of the transmission frequency (the driver asks for reports every 3 seconds, but the highest frequency I've ever seen is similar to yours, maybe every 6-8 seconds if the light level is constantly changing).
I don't think the GZCGQ01LM does see every change, but rather checks its sensor on a fixed interval. As radio transmission is likely the most energy demanding task it performs, it probably uses the tolerance and reporting interval to determine if it should bother "shouting out" the new value. If you flash a bright light at the sensor at just the right moment (when it takes its sample) then you'll get that big momentary jump in reported lux. But it is possible to shine a bright light at it for two or three seconds, remove the source and see no transmitted report at all.
I think you could achieve something approaching this, so long as your source was present for at least 5 seconds, and assuming any of my supposition above is correct. There's definitely a hysteresis to the light sensor, so a bright source shone and then removed may well be sampled as a small ~200 lux variation.
So, headlights coming up a dark driveway? Yes, I think it would be reliable. Lightning? No chance. That's beyond the granularity the device can handle given the choices made in circuit design and firmware to achieve the very impressive battery life.
1 Like
It should work perfectly with the one I can see in that thread. Mijia and Mi are one and the same; all of mine say "Mi" on the back. From Xiaomipedia:
Sadly I do suspect they've discontinued the sensor, I couldn't find any more on AliExpress, which is usually a sign, though they could simply be manufacturing higher volume items right now. Also, Mi/Mijia are not solely about home automation, perhaps it's a device they want to roll in to the Aqara ecosystem. Just guessing though.
Nice they're still in stock somewhere, though. 
1 Like
I just ordered a couple of the the Xiaomi light sensors from here.
I have never ordered from techinn.com before, so I can't vouch for them. I placed the order on Sunday and received notification today (Monday) that they have shipped. I'll update this thread once they arrive and I've had a chance to test them.
Marc
I'm curious where they will ship from and at what shipping charge.
I'll let you know how this goes...right now I'm betting a lightening storm would play havoc and cause false triggering on any rule not accommodating it (even if that means having current weather as a input to cause triggers to be disregarded).
Thus the challenge... is that first flash one from a flashlight, headlight, or lightening. Might be a matter of sussing out signature, duration & more importantly lux level; if that hysteresis doesn't muddle things. Certainly the lightening lux level is going to be above all else in the shortest amount of time. But all three sources could "flash" and be done in 3 seconds or less.
Am I being over simplistic, but wouldn't having more than one sensor make this more do-able?
A rule to compare the values of the two data sources in a set time period, and react accordingly?
Two carefully positioned sensors pointing "x" degrees away from each other. Lightning would trigger a massive lux increase on both sensors simultaneously. Headlamps would either trigger one more than the other, or (as the vehicle moved) would sweep across the two. A flashlight would probably be more random in its movement between the two.
1 Like
Not sure where they ship from yet. The shipping charge was $9 for 1; $10 for 4. (I order 2 for myself and 2 for a friend). They are supposed to arrive sometime between Mon. 28 Feb. and Fri. 04 Mar.
Marc
That's an idea worth trying if @marcaronson408 has found a trust-able source for more of these!
One site is a greenhouse with a covering that readily disperses incident light, so it's not so clear as headlights being a "point source". The flashlight case would certainly be more localized.
I think you are absolutely onto something with respect to differentiating from lightening because as you said, it would light EVERYTHING equally in a high lux FLASH (so to speak). The problem there might be the time it takes the devices to recognize such a short change and report it. But then maybe that's one way to have lightening ignored 
Never written a rule with such real time comparative value assessment. Fun to be had.
Thanks for the brainstorming!
1 Like
Tracking shows that they shipped from Spain and are now in the Netherlands. I'll post updates as things materially progress.
A bit more info - I just learned that the tracking number is recognized by USPS. So it looks like the package started in the postal system in Spain, is now in a centralize sorting station run by the Netherlands postal service and will ultimately be delivered by USPS.
I've registers with USPS to get regular updates on the package's progress.
Kind of interesting how well these various national postal systems are integrated...
Marc
It actually is amazing how well, and how long back in time, these systems worked together. Hope the Customs Clearance is pain free for you.
Yes, that is where it could get hung up. I've had a couple of other international orders from various sources clear customs without a problem, including batteries from Hobbyking's international warehouse and items from Amazon Germany.
We shall see how this one goes.
Another tracking site ("Spring GDS") has more granular info, and shows it is now OTB (OuTward Bound). Hopefully that means enroute to the United States, but time will tell.
Marc
Just want to substantiate something that others have said, and for those that come behind.
I just switched this sensor to another hub running the latest FW and paired it. While it paired just as quickly as on the other hub (older FW) I experience the randomness seemingly delayed reactions in configuring this GZCGQ01LM device. [EDIT: It seems there is a good explanation]
The following is ALL that first showed up. It took the Battery data about an hour later to populate. Now that was after placing the sensor out of the proximity of the hub and likely now on an Ikea repeater (but I did not check) some 80' away from the device.
