ESOCKETTIMEDOUT and ETIMEDOUT

Not really sure what to make of these, but they appear in the error log when I attempt to change the lights. Using the iOS 10 Home app, I get a "Failed" state on Philips Hue bulbs when attempting to tap a scene. From what I can tell, it looks like this usually occurs for bulbs that are trying to change more than one parameter (e.g. hue, saturation, brightness) within on scene.
[11/10/2016, 11:31:59 AM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 11:33:59 AM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 11:58:02 AM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 12:05:58 PM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 12:10:58 PM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 12:20:14 PM] [Hue] Philips hue: hue bridge communication error Error: ETIMEDOUT

I've also noticed in the log file that bulbs appear to be changed from "0" to "false" (or vice versa), and "1" to "true". Seems like the type of a variable isn't set correctly, but I could be wrong...
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Tall: set homekit power from false to 0
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Medium: set homekit power from false to 0
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Medium: set homekit color temperature from 2000K to 3984K
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Short: set homekit power from false to 0
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Short: set homekit color temperature from 2000K to 3984K

I am running Homebridge on a Raspberry Pi 2 B+ and I have the 1st Generation Hue Hub. This is my config file:
{
	"bridge": {
		"name": "Homebridge",
		"username": "<<REDACTED>>",
		"port": <<REDACTED>>,
		"pin": "<<REDACTED>>"
	},

	"description": "Description - not very helpful...",

	"platforms": [
		{
			"platform": "Hue",
			"name": "Hue",
			"host": "<<REDACTED>>",
			"users": {
				"<<REDACTED>>": "<<REDACTED>>"
			},
			"heartrate": 5,
			"timeout": 5,
			"lights": true,
			"alllights": true,
			"groups": false,
			"sensors": true,
			"schedules": false,
			"rules": false
		}
	],

	"accessories": [
		{
			"accessory": "WUNDERGROUND",
			"name": "Weather Conditions",
			"device": "Raspberry Pi",
			"key": "<<REDACTED>>",
			"city": "<<REDACTED>>"
		},
		{
			"accessory": "people",
			"name": "People",
			"people": [
				{"name": "<<REDACTED>>", "target": "<<REDACTED>>"},
				{"name": "<<REDACTED>>", "target": "<<REDACTED>>"}
			],
			"threshold": 15
		},
		{
			"accessory": "HttpTemphum",
			"name": "Living Room Conditions",
			"url": "<<REDACTED>>",
			"sendimmediately": "",
			"http_method": "GET"
		}
	]
}

Hi @deanlyoung,
The first series of errors are network errors, timeouts homebridge-hue gets when trying to communicate with the hue bridge.  Typically these network timeouts happen when the network connection to the hue bridge is poor, or when the bridge is too busy.  If you run homebridge -D, homebridge-hue logs the requests it sends to the hue bridge, so you have an idea when the timeouts occur.  You could try increasing the timeout parameter in config.json.  Is your Raspberry Pi connected through a network cable or trough WiFi?
As to your second question: homekit defines the power or On characteristic as a Boolean, but uses values 0 and 1 instead of false and true.  To wit, if you switch off power from the iOS 10 Home app, you see a log message "homekit power changed from 1 to 0".  However some Homekit applications use false and true instead of 0 and 1, and instead you would see "homekit power changed from 1 to false" in the log.  Long story short: don't worry about this.  I'll see if I can suppress the messages in a future release.
Regards,
Erik.

Thanks for the reply, @ebaauw! I'll look into the logs some more and try out your timeout suggestion. I have my RPi connected via Ethernet.

Running homebridge -D gets me this error after initializing everything. I've seen this come up before, but that I handled error is a tricky one to track down.

events.js:154
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE :::51826
    at Object.exports._errnoException (util.js:856:11)
    at exports._exceptionWithHostPort (util.js:879:20)
    at Server._listen2 (net.js:1231:14)
    at listen (net.js:1267:10)
    at Server.listen (net.js:1363:5)
    at EventedHTTPServer.listen (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/util/eventedhttp.js:58:19)
    at HAPServer.listen (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/HAPServer.js:148:20)
    at Bridge.Accessory.publish (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/Accessory.js:468:16)
    at Server._publish (/usr/local/lib/node_modules/homebridge/lib/server.js:92:16)
    at Server.<anonymous> (/usr/local/lib/node_modules/homebridge/lib/server.js:351:14)

On mobile, so I couldn't figure out how to copy the logs from my terminal app, but here are some screenshots of the errors when attempting to update x,y bri etc.
https://imgur.com/gallery/tztiT

Hi Dean, @deanlyoung
Hmm, I think that first error is thrown by homebridge itself, not by homebridge-hue.  I think 51826 is the port you masked from your config.json.  On startup, homebridge creates at web server at that port, for your iOS devices to connect and interact with the homebridge bridge accessory.  EADDRINUSE means homebridge cannot create this web server, because the port is already used by another program.  Are you running multiple instances of homebridge?
I'm a bit puzzled by the logs from the first screenshot.  It looks like you switched light 3 on from homekit (that message should have appeared just before these), and homebridge-hue sends a put of /lights/3/state to the hue bridge to mirror that change.  However that doesn't seem to reach the bridge, due to a connection reset error.  Then the bridge justly complains that it cannot change the brightness nor colour, as the light is still off.  Now, there's more going on, the communication error occurs twice, so another command to the bridge has failed as well.  That's the joy of asynchronous I/O: the error message doesn't necessarily apply to the latest communication attempt.  I really need more of the logs.  Could you start homebridge -D > logfile.log 2>&1 to capture the logs?  You can still monitor the logs by tail -f logfile.log from another terminal session.
The real question, of course, is what causes the ECONNRESET?  It could be a network error, an error on the Pi, or an error in the hue bridge giving up because it's flooded with requests.  The first seems unlikely since you use Ethernet.  I'm unfamiliar with the Pi (as I have a mac server running), but in theory you run into a limit on number of open network sockets.  Are you running many other programmes on the Pi, under the same username.  What load do the other homebridge plug-ins generate?  For the third: are you running any other apps or programs communicating with the hue bridge? Do you have many rules on the bridge?  I really need the full logfile to assertain whether homebridge-hue is flooding the bridge.
The logs from the second screenshot look fine to me.  Homebridge-hue does a get /lights to receive the updated light states from the hue bridge and then sets the homekit characteristics to match any changes.

Ah, I think running homebridge -D while my /etc/init.d/homebridge instance is running is clogging port 51826. However, that's not the root issue here because even when only one instance of homebridge is running I still get errors changing the lights. Specifically, changing multiple characteristics at once using a scene command in the Home app.
It is possible that the other plugins are causing too much of a load on the connection... They seem to update pretty frequently, like every 20-30 seconds. I'm looking at [Living Room Conditions] as an example. That value shouldn't be changing as frequently though. I have a cron job running that generates that data from sensors every 5 minutes, so I can look into reducing the load from the HttpTemphum accessory.
In terms of rules on the bridge, I think there is only one, and it affects only the bathroom because the motion sensor is in there. The rest of my automation tasks are done through the Home app. How do I view what has been saved on the bridge itself? (This is the Hue Bridge, no Homebridge, correct?) I should also probably point out that I only have a Gen 1 Hue Bridge. Maybe there is a different behavior because of that?
The only issue I see in the second screenshot above is that of the three lights, "Tall" does not show 3 commands, while the other two do. It's missing brightness, which threw an error in screenshot one. To show you an example of outcome, I've attached a few photos below, executed via "scenes" in the Home app.
Some example taps in the Home app: (not necessarily a representation of the logfile)

start at Off
tap "Bedtime" (turn lights to 1% brightness, change color to an off-white), receive error
tap "Bedtime" again, "Bedtime" button becomes highlighted in app
tap "Good morning" (turn lights to 30% brightness, same color so no change there technically), receive error, only 1-2 lights have turned brightness up)
tap "Good morning" again, all lights turned up now, but "Good morning" button does not become highlighted in the app
tap "It's getting late" (turn lights to 1% brightness, change color to red), receive error, only 1 light turns red, brightness levels vary
tap "It's getting late" again, throws error, brightness is correct across all lights, but 1-2 remain off-white
tap "It's getting late" again, all lights are correct, button highlights in the app

From the above example, pretty consistently, the most errors get thrown (requires the most taps/retries) when the color is changing as opposed to only changing hue or saturation. Given that I could try to bump up the timeout from 10 to 15 (was previously at the default 5). The Home app reports back an error ("Failed!") well before the 10 seconds are up though.
Let me know if there is any more information I can provide. I'm sure there could always be something I'm overlooking...
Turn on to full brightness

Turn down lights and make them red, error

Tap the same scene one more time, still throwing an error

logfile.txt

Hi Dean, @deanlyoung
Nice lamps!
The logfile is very insightful, thanks.  When activating a homekit scene, the homekit app sends an event to homebridge-hue for each characteristic in the scene.  That's three characteristics for each light (brightness, hue, and saturation, even though the app might show them as one colour). On each event, homebridge-hue checks whether the characteristic value has changed and if so, issues a put request to the hue bridge.  By design, homebridge-hue sends these requests asynchronously, that is, it doesn't wait for the response from the hue bridge, but continues handling the next event.  Consequently, the hue bridge receives the next request(s) when it's still processing the previous one(s).
I've done some testing on my old gen1 bridge, and I consistently get ECONNRESET when the homekit scene contains 8 characteristics.  With 7 characteristics, everything works fine.  With three lights times three characteristics, the math doesn't really work in our favour.
I tried the same on my gen2 bridge, with up to 24 characteristics per scene: no problem.  I read the gen1 bridge was less powerful than the gen2 bridge, but I didn't expect such a huge difference.
So what could we do about this (short from upgrading to a gen2 bridge)?

I double-checked the source for the other plugin, homebridge-philipshue.  As far as I can tell, it actually works the same as homebridge-hue: sending a separate put request to the bridge for each characteristic.  It does however check specifically for ECONNRESET and, instead of logging the error, it silently (!) resends the put request after 300ms. As a result, the whole scene would eventually be activated, but the lights wouldn't change at the same time (I also noticed that when testing). I could implement something similar in homebridge-hue (but I would probably still log the ECONNRESET).
Alternatively, I could make homebridge-hue throttle the requests to the hue bridge, making sure there's no more than seven the outstanding requests to a gen1 bridge, preventing the ECONNRESET in the first place.  Again this would cause the lights to react at different times.
As mentioned in issue #16, I could make homebridge-hue collect all the changes to a single light and combine them in one request to the hue bridge.  That would help your case with only three lights in a homekit scene, but the problem would still occur for scenes with more than seven lights.
You could create a group on the hue bridge, containing all lights of the homekit scene.  Change homebridge-hue's config.json to expose groups and put that group in the homekit scene instead of the individual lights. This is actually the reason why homebridge-hue supports groups in the first place: to limit the interaction with the hue bridge.  Unfortunately, neither the old (v1) nor new (v2) official Philips Hue app supports creating groups. You would have to use another app, or do that manually using the bridge's built-in API debugger, see http://www.developers.meethue.com/documentation/getting-started
You could use a scene on the hue bridge, instead of a homekit scene.  To activate that scene from homekit, you would create a CLIPGenericFlag sensor on the hue bridge, and a rule that activates the scene when the sensor's flag changes.  Homebridge-hue exposes the CLIPGenericFlag as a Switch to homekit.  This is the setup I use at home, actually, using a flag per room.  I'm setting the same flag from the room's Hue Dimmer switch and/or Hue Motion Sensor.  This is quite elaborate configuration on the hue bridge.  I'm actually using a series of shell scripts to maintain the groups, sensors, and rules (posting those on GitHub might very well be my next project).

Please let me know what you think.  4 is probably easiest and quickest to implement, if you're comfortable typing json by hand.  Implementing 1 or 2 would be relatively easy for me, but I'd rather focus on the dynamic accessory model (and issue #16).  I do think I should implement 2 eventually anyway, probably making the number of parallel requests a config parameter.

I stand corrected: 1 was easiest to implement, just published version 0.0.12.  @deanlyoung could you see if that version solves this issue for you?

One more thing, @deanlyoung , I wouldn't worry about the other plugins. Once every 20-30 seconds is peanuts compared to the load to the hue bridge.
For something completely different: how about creating a CLIPTemperature and a CLIPHumidity sensor on the hue bridge?  Homebridge-hue exposes these CLIP sensors to homekit. These could then be updated periodically from Wunderland from a cron job.  This job would be a simple script doing an http get on wunderland.com, extracting the temperature and humidity values from the response, and two http puts to send these values the hue bridge.

@ebaauw it's definitely more stable, but that "It's getting late" scene is being really stubborn. I forgot to mention that that scene does in fact control more than just the 3 hue color lights. It also turns every other light off connected to the bridge, so 5 others, in addition to controlling the 3 color ones, 8 total. However, when I remove control of all other lights (except turning off an additional bedroom light) it still performs the same way. It just doesn't show the ECONNRESET now in the logs, which is a step in the right direction!
Another upside is that the other scenes seem to work properly now and show up highlighted in the Home app after tapping them. Yay! (whereas, the "It's getting late" scene highlights, then un-highlights when it realizes the scene hasn't actually finished)
Unfortunately, I can't seem to get homebridge -D > logfile.log 2>&1 to restart homebridge after stopping it at this time (so as not to clog the port again). Not sure what's going on, but another thing for me to look into... I was able to copy this from Terminal though:
I've also noticed, maybe anecdotally, that only the "Tall" light is usually the one that doesn't turn red, but tapping the scene again eventually gets it to change, and yet still no recognition by the Home app that it's in fact completing the scene now.
Anyway, that's all to say that I think I can live with it the way it is now, versus the extra effort/debugging/development it would take to track down the issue more. Happy to keep trying things, but I don't want to waste too much of your time :)
THANK YOU!
As for the other plugins, I was mistaken. 20-30 seconds was actually how often I was going back into the Home app while testing, and the HttpTemphum plugin only runs when you open the app (I noticed from watching the logs). And as to converting them to CLIP sensors... well, they've actually sensors hard-wired to my RPi, so I have to run a Python script to pull the data and expose the data to the web (in my case). I'll read up on CLIP more, but these are sensors attached via GPIO. What you suggested might also be beyond my understanding at this point, and I could just be missing your point.

Hi Dean, @deanlyoung
I find homekit sometimes reverts changes I make to scenes or rules when syncing with my other devices over iCloud.  I'd double check that the changes to the getting late scene have been propagated to your other devices.
I now log a debug message on ECONNRESET, so you would only see it with homebridge -D.  I tested with 16 characteristics in a scene.  Some updates actually cause an ECONNRESET on the first retry as well, but eventually work on the second retry.
The CLIP sensors on the hue bridge aren't real sensors, they're more like variables where you can store  sensor output.  So instead of exposing the data to the web, your Python script would do an http put to the hue bridge to update the CLIP sensor value.

Ah, gotcha! I'm currently reading through the Hue API documentation. Really good stuff!

Hi @ebaauw !
Thank you for all the work you've done on this hue homebridge plugin.
I too ran into the ECONNRESET issue and worked on a solution locally. I'm running a Hue 1st Gen bridge and noticed that error appeared when I loaded a scene that required many API calls (turn on, set brightness, set color, etc. on 5-6 lights). When I googled the error, I found information about a limitation in 1st Gen bridges:
http://www.developers.meethue.com/faq-page

How many commands you can send per second?
You can send commands to the lights too fast. If you stay roughly around 10 commands per second to the /lights resource as maximum you should be fine. For /groups commands you should keep to a maximum of 1 per second.

My solution was to write a request cache loop that makes a maximum N requests per T milliseconds, repeating until the cache is empty. When I set it to 10 requests per 1000 milliseconds, I still got errors, though fewer of them. Through trial and error I found that 5 requests per second works reliably on my setup. The only time I still have failures is when a change request is made on a light that is in the off state (ex: requesting set brightness to 30% when light is off). The Hue bridge complains about an invalid API request in those situations.
I didn't realize that you were also working on the problem (though was happy to see an open source project that was so active). The changes I made were to version 0.0.11 and was planning to incorporate them in version 0.0.12 with the 300ms request retry. Would you be interested in reviewing my changes? I could fork your project and submit a PR.

btw, @ebaauw (and @fedhat) it seems that by hardcoding a group for my three color lights via Hue's API, I was able to fully solve this issue. The transitions are much faster and I haven't seen an issue yet. @ebaauw, I'm not sure if you want to leave this issue open in light of that insight you gave me, but maybe there are some refinements to the module you want to take note of. We discussed a lot... :) Thanks again!

Hi @fedhat,
Yes, I know that FAQ. It refers to the limitations of the Zigbee network, the Hue bridge sending commands to the lights; the ECONNRESET is a limitation on the IP side, homebridge-hue sending requests to the Hue bridge.  On that side, a PUT /group is just as resource intensive as a PUT /light; on the Zigbee network, a group command is a broadcast, whereas a single light command is a unicast, hence the difference in number of requests between lights and groups.  Also note that the bridge caches the light states, to a GET /lights wouldn't even result in any Zigbee traffic.
The IP problem is not so much the number of requests per second, but the number of parallel requests.  As homebridge-hue sends requests to the Hue bridge asynchronously, the bridge receives the next request before it has responded to the previous.  The 1st Gen bridge cannot seem to handle more that 6 open requests.  Consequently, we need to limit the number of open requests to the bridge (option 2 in my earlier comment), rather than the rate of these requests.  As all requests go through HueBridge.request() the implementation would be relatively straightforward.  Keep a counter on the number of open requests.  Queue a new request when too many are open and check for queued requests when a request is resolved or rejected.  Probably combined with a config parameter for the threshold how many requests might be open.

That's good to hear, @deanlyoung.  I'll keep the issue open, until I have implemented the limit on number of open requests.

Thank you, @ebaauw. I didn't realize that the FAQ referred to the limitation of the Zigbee network, nor that the actual limitation of the 1st Gen bridge is the number of open requests.
For my own edification, I'll update the request cache system I added to account for open requests, rather than requests per second. My modifications are built around HueBridge.request(), and as you said, it's pretty straightforward.
@deanlyoung thank you as well. I'll keep that in mind.

@ebaauw (and @deanlyoung in case you're curious)
I submitted a pull request that implements the request cache I described earlier, except that I updated the logic to limit concurrent/unresolved requests rather than requests per second. After making the change, updates to scenes and lights happen very quickly and I get 0 ECONNRESET errors.

I get a this at least once a day, seems to resolve itself (after one hour, looking at the logs):

[2016-12-30 15:16:38] [Hue] Bridge Maurice: hue bridge communication error ETIMEDOUT
[2016-12-30 15:16:38] [Hue] undefined
[2016-12-30 15:16:41] [Hue] Bridge Maurice: hue bridge communication error EHOSTDOWN
[2016-12-30 15:16:41] [Hue] undefined

This is the pattern, which is repeating every [heartbeat] seconds.

Hi Joost, @jojost1
Please ignore the undefined messages.  This are caused by a cosmetic error in homebridge-hue, which I'll correct in the next version.
The ETIMEDOUT and EHOSTDOWN errors indicate that homebridge-hue cannot connect to the Hue bridge, typically because the Hue bridge or the network connection the Hue bridge is down.  It's generated on every communication attempt with the Hue bridge, which is every heartbeat seconds when homebridge-hue polls the Hue bridge.
What type of server do you run homebridge on?  Is this server connected to the network by wire or by WiFi?  What is your home bridge configuration?  What is your Hue bridge config?

Running it on an iMac, connected by wire. Homebridge-hue settings in config are all default.
Unrelated question: There is no way to hide the hue-bridge and/or daylight sensor right? Kind of useless for those to be there ;-)

Could it be related to the iMac sort of sleeping and suspending its network interface?
No, there isn't.  I don't think they're useless.  The bridge accessory will be used to persist the bridge username, so you wouldn't need to edit config.json to add it manually, once I'll have moved to dynamic platform accessories (see issue #4).  Currently, it supports dumping the bridge state on Identify for troubleshooting.  The daylight sensor accessory could be used for HomeKit rules in other apps than the iOS Home app.  There should probably be a way to suppress it, see issue #7.
Are you running into the 99 bridged accessories limit?  Otherwise, just create a dummy room in HomeKit and move all the accessories you don't use there (including the accessory for homebridge itself).  Be sure to unmark them as favourite.

Could it be related to the iMac sort of sleeping and suspending its network interface?
Maybe, but don't think so. I'll look into that.

For the other issue: thanks for the info!

Are you running into the 99 bridged accessories limit? Otherwise, just create a dummy room in HomeKit and move all the accessories you don't use there (including the accessory for homebridge itself). Be sure to unmark them as favourite.

Nope don't have +99 accessories, I already unmarked them and made a separate room. Thanks!

i'm also receiving this message often on every heart beat currently set to 5 seconds.
Philips hue: hue bridge communication error ETIMEDOUT
Homebridge server is running over wifi.

@pponce You don't get any EHOSTDOWN errors?  My best guess is hiccups in your WiFi network.  Do you see lost packets when you do a ping -s 1472 from on homebridge server to your hue bridge?
Do you also get these errors when connecting the homebridge server by wire instead of over WiFi?  When only using the homebridge-hue plugin?  If so, than please attach a full debug log and your config.json here.  See Troubleshooting in the README.

Running the pings now for the last 10 minutes and no lost packets yet.
I'll try and do more troubleshooting over the weekend.
I'll give wired connection a try.
I also have the homebridge-philipshue plugin running along side this one.
I'm using ha-bridge to expose my harmony remote activities to homebridge.
I could not get homebridge-hue to recognize the ha-bridge so i reverted back to homebridge-philipshue for just connecting to ha-bridge. I use homebridge-hue to connect to my real philips v2 hub.
I'll try and remove the philipshue plugin and see if that helps too.

On a heartbeat, homebridge-hue issues a GET /api/<username> to the Hue bridge to retrieve the full bridge state.  I did some more checks at home using Wireshark: the Hue bridge responds with the full bridge state in a single TCP packet.  In my case, that's 118894 bytes, which get fragmented into 186 ethernet frames.  The GET itself doesn't contain a body and fits comfortably in a single frame.  It's hard to simulate this using ping -s <packetsize>, as ping uses the same size for the ping request and the ping response.  But it would be more realistic to use a (way) larger packetsize than 1472 when hunting for intermittent network issues.
Alternatively, you could use curl to emulate the heartbeat in a shell loop:
while true ; do
  curl http://<bridge_ip>/api/<username> > /dev/null
  sleep <timeout>
done

On my Mac server as well as on my Raspberry Pi curl displays some transfer statistics when its output is redirected:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  116k    0  116k    0     0   102k      0 --:--:--  0:00:01 --:--:--  102k

If the issues are indeed network related, I would expect variation in Average Speed Dload and Current Speed.  Also, these numbers should improve when using a wired connection, instead of WiFi.

I could not get homebridge-hue to recognize the ha-bridge so i reverted back to homebridge-philipshue for just connecting to ha-bridge.

I'm unfamiliar with ha-bridge.  Do I understand correctly that you want homebridge-hue to connect to the ha-bridge as if it were a Philips Hue bridge?  Some thoughts on this:

Homebridge-hue only discovers Hue bridges through the meethue portal, not (yet) through UPnP (see issue #6).  If ha-bridge doesn't register itself with the meethue portal, you would have to specify the ha-bridge ip address in config.json: "host": "192.168.x.x";
I assume ha-bridge exposes the emulated Hue api on port 80?  Homebridge-hue provides no way to specify a different port as the Philips Hue bridge always uses this port.  Afaik, neither does homebridge-philipshue.
For every bridge it discovers/configured, homebridge-hue does an unauthenticated GET /api/config (instead of GET /api/<username>/config) to get the bridge name, serial number, version, and API version.  Glancing through ha-bridge on Github, it doesn't seem like they provide this API call.

Thanks for taking the time to help me out.
I will try and play around with curl to see if perhaps it's my network after trying out wired first.
You are correct about HA-bridge. It pretends to be a hue bridge. I'm pretty sure It does not register itself with Philips. It is configured to run on port 80.  It also by default will accept all any username for authentication purposes. I made one up with the homebridge-philipshue plugin and it works.
-Question about your host parameter. If i only enter the host IP for the HA-Bridge would your plugin still find my real hue bridge? Or is there a way to configure two host ip's?
-How would i configure the "users" value for the HA-bridge given it automatically accepts any username for authentications purposes. (I'm using HA-Bridge as a temp solution until homebridge-harmonyhub works without crashing homebridge).

Question about your host parameter. If i only enter the host IP for the HA-Bridge would your plugin still find my real hue bridge? Or is there a way to configure two host ip's?

By design, the host parameter disables automatic discovery.  Currently homebridge-hue either connects to a single bridge specified in config.json, or it connects to as many bridges as returned from the meethue portal.
I could probably without too much effort add a hosts parameter to config.json, that takes an array of hostnames/ipaddresses.

How would i configure the "users" value for the HA-bridge given it automatically accepts any username for authentications purposes. (I'm using HA-Bridge as a temp solution until homebridge-harmonyhub works without crashing homebridge).

Just specify any username in the users for the bridge ID that HA-Bridge exposes.
I hope HA-Bridge uses a different bridge ID than your Hue bridge, otherwise homebridge-hue will think it's the same bridge with a new IP address.  In that case, I see no other workaround than running two instances of homebridge, one where homebridge-hue connects to the HA-Bridge, and one where homebridge-hue connects to the real Hue bridge.
Homebridge-hue does the unauthenticated GET /api/config to retrieve the bridge ID, so it knows which username from config.json to use.  I'm afraid HA-Bridge will take this as a request for the full bridge state for username config.  Homebridge-hue wouldn't know how to handle the corresponding response.  If you post the homebridge -D output here, I could have a look what's happening.  Please upgrade to<EMAIL_ADDRESS>before capturing the output, as that version provides more useful error messages (see issue #42), also for the ETIMEDOUT errors.

Initially i thought i had to edit config.json with a separate config platform section just for HA-bridge as i suspected only one host could be used at a time.  When i ran it with two configs for homebridge-hue (one for ha bridge and the other for my real hue bridge) I did get a different bridge id back.  The HA-Bridge did appear to return a different bridge ID than the real hue.  this is what the ha-bridge returned "B827EBFFFE906FD2": "961f615166664b86a5803b75d0db6de0"
If you supported multiple host ID's perhaps it would just work?
I can create a different thread for this request so as to keep this issue about the timeout errors.

this is what the ha-bridge returned "B827EBFFFE906FD2": "961f615166664b86a5803b75d0db6de0"

Indeed, that's not a Philips Hue bridge ID.  It's derived from the Mac address of your Raspberry Pi, courtesy of HA-Bridge, I assume.  Where did that username come from?  Did you (do the equivalent of) press(ing)  the link button on HA-Bridge at homebridge-hue's request?

If you supported multiple host ID's perhaps it would just work?

Version 0.1.10 supports multiple values for host.

Tested 0.1.10. seems to work. Now just getting the HA-bridge errors.
I never had to press any links. Supposedly it "auto presses" and can accept any username.
my working config for the homebridge-philipshue plugin was
{
"platform": "PhilipsHue",
"name": "HA-Bridgee",
"ip_address": "<IP_ADDRESS>",
"username": "my-homebridge"
},

My issue with ETIMEDOUT errors i believe has resolved.
It was probably because my Philips hub was connected  via powerline.
Once i connected straight to router the timeouts went away.

@pponce that's an interesting point about connecting via powerline. I have my RPi connected to the router via powerline (as opposed to wireless, which is flakey on a 2B with a USB wifi stick), and my bridge connected directly. I wonder if I'm getting the Philips hue: hue bridge communication error ESOCKETTIMEOUT for the same reason (albeit, the other way around). For the most part, my requests go through and things are generally stable, but I see the error pop up about every minute. It does seem to coincide with updates to the ambient light sensor on the Hue motion sensor, but that could be a coincidence instead of causation until I can look into it more.

I bet it's the powerline. I decided to connect everything (pi3 and hue hub) direct to the router and the timeout went away. I had originally been running wifi on pi3 and powerline to philips hub. I had the timeout issues like crazy. Once i hooked it all up direct i was able to do the 2 second heartbeat with no timeout issues.
I'm cutting back on powerline use as much as i can.

@pponce I can safely conclude, the powerline ethernet was the issue. No errors occurring whatsoever now. That's exciting, while at the same time depressing that it was that "simple". (cc: @ebaauw)

I've also had luck improving homekit related networking issues by turning on IGMP proxy and IGMP snooping on your router if you have those options.
Worth a shot.  For me it improved things noticeably.

I double checked the documentation and code of request, the npm module homebridge-hue uses to send commands to the Hue bridge:

ETIMEDOUT is returned, when request doesn't receive any answer from the Hue bridge within the specified timeout period.  This period is specified using the timeout parameter in config.json, 5 seconds by default.
ESOCKETTIMEDOUT is returned when part of the answer was received, but the next part takes too long.  Not sure, but I think request uses the same timeout setting for this.
ECONNRESET is returned when the Hue bridge "hangs up" on homebridge-hue.

For all these errors, home bridge-hue was able to open a network connection to the Hue bridge, but received no timely response.  ETIMEDOUT and ESOCKETTIMEDOUT could indicate network hick-ups, but could also indicate that the Hue bridge is too busy with other stuff, like processing a homebridge-hue heartbeat, processing requests from other Hue apps, doing firmware updates, whatever.
I've only seen ECONNRESET when sending too many parallel requests to the Hue bridge (I still need to implement request throttling to prevent that).
You could try and increase timeout to get rid of the ETIMEDOUT and ESOCKETTIMEDOUT errors, but you're fighting the symptom.  When the Hue bridge doesn't respond within 5 seconds, your lights will appear unresponsive.
To check for network problems, you could try ping or curl as I described above.  Wired ethernet is more reliable than Wifi or powerline.  In my experience, powerline is more reliable than Wifi, but your mileage may vary.
To check for a busy bridge, run homebridge -D and observe when the errors occur: how many open requests, during a heartbeat, etc.  You could try and reduce the heartrate.
I started out retrieving the full bridge state on each heartbeat (with a single request get /).  Then I moved to using separate requests get /sensors, get /lights, etc, but only when homebridge-hue is actually exposing the corresponding resources (issue #3).  That caused startup issues (#26) so I moved back to using a single get /.
I should probably do a full state request only on startup and move back to separate (sequential!) requests on the heartbeat.  This would result in more requests, but probably on the Hue bridge and less network traffic (especially with a lot of unexposed rules).  My next idea is using different heartrates for sensors (react quickly to buttons) vs other resources (react more slowly to light changes to take it easier on the bridge).

v0.3.5 again does separate requests per resource type on heartbeat.

Finally, homebridge-hue v0.3.7 throttles requests to the Hue bridge, see point 2 in https://github.com/ebaauw/homebridge-hue/issues/15#issuecomment-260449243.  homebridge-hue will issue maximum 3 requests in parallel to a v1 (round) bridge, and maximum 10 parallel requests to a v2 (square) bridge.  This can be changed in config.json using the parallelRequests parameter.
The throttling is implemented using deferred.gate().  @fedhat, thanks again for introducing me to that package.
v0.3.5 re-introduced separate requests per resource type on heartbeat (issue #3 and #26).
Since v0.2.4, homebridge-hue  collects multiple HomeKit updates to the same light into a single bridge request (issue #59 and point 3 in https://github.com/ebaauw/homebridge-hue/issues/15#issuecomment-260449243).
@pponce, @deanlyoung, this is all I can think off to improve homebridge-hue's performance.  Please let me know if you see any improvements.

My issues were almost completely solved by not using wifi or powerline instead hooking up direct via ethernet.
IGMP snooping and proxy settings enabled on the routerI  believe also helped but that might be a placebo effect not sure.
The last two ESOCKETTIMEDOUT errors i saw were both for /sensor requests (i can now tell because of your resent update to request by resource type).
I have 8 dimmers and 1 tap switch. Plus a daylight sensor and 2 led strips for lights that i'm using the plugin for. The rest of my lights (over 20) are exposed by the hue bridge directly.
I'll monitor to see if my sensor request timedout errors go away with 0.3.7. But even those were not happening often.
Assuming my switches and tap switch count as sensors i do have more of those than lights being exposed by homebridge-hue so that may be why it's the sensor request that is timing out.

Thanks, @pponce.

IGMP snooping and proxy settings enabled on the router I believe also helped but that might be a placebo effect not sure.

IGMP snooping is a technique for a network router/switch to reduce the network traffic to hosts that do not need multicast traffic, used e.g. for IPTV, but also for UPnP.  Basically, a multicast server sends messages to a special broadcast address per service (e.g. <IP_ADDRESS> for UPnP).    With IGMP snooping, the router/switch forward the multicast messages only to ports connected to a host that actually wants them, reducing the network traffic on the other ports.
All power-line connected hosts connect to the router/switch using the same port (connected to the power-line adapter).  If one of those hosts subscribes to e.g. IPTV, the corresponding multicast stream is forwarded to all power-line connected hosts.

Assuming my switches and tap switch count as sensors i do have more of those than lights being exposed by homebridge-hue so that may be why it's the sensor request that is timing out.

Yes they do.  Additionally, the Hue app or some other app for the Hue bridge might have created CLIP sensors working in conjunction with the rules for these switches.
Homebridge-hue does an http get of /sensors and an http get of /lights.  The bridge responds with all sensors and all lights respectively, not just the ones exposed by homebridge-hue.  You can use the API debugger on your Hue bridge to issue those requests manually and see the corresponding Hue bridge responses.
By my count you have 24 lights (20 exposed by the Hue bridge and 2x2 for the LED strips) and at least 10 sensors (8 dimmers, 1 tap, and the built-in daylight sensor).  Depending on the amount of CLIP sensors, the response for the get /lights could very well be larger than the response for get /sensors.
On heartbeat, homebridge-hue sends the get requests sequentially, i.e. it only sends the second request after it has received the response for the first request.  This is different from update requests, which are sent in parallel, i.e. the second request is sent before the response of the first request is received.  When a get request returns an error, the remaining requests for that heartbeat are skipped (no need to worsen a bad situation).  As homebridge-hue issues the get /sensors before the get /lights, you'll more likely see the ETIMEDOUT or ESOCKETTIMEDOUT for that request.

@ebaauw as always, you da man! I'm installing now and will keep an eye on performance. Really helps that you walked us through the technical aspects of all this, too. I certainly learned some things and can understand how to better optimize my setup because of that., and not just think "I don't know why it works, but it works". The biggest thing was understanding how power-line sends all requests through the same port.
Even before the latest updates, I can still say that performance was drastically improved by connecting the RPi running Homebridge directly to the router improved speed and reliability. Most noticeable with changing multiple lights' hue/saturation/brightness at the same time. Before, I'd have to trigger a Scene 3 times to get the lights to change "all the way" (i.e. usually only one light, or one state would take effect - only color changed, only brightness changed, etc.).

@ebaauw Yes thanks for all the detail.
Is there a somewhat easy way to clean up the config on the hue-bridge?  I see a ton of whitelisted users and would like to delete some of them and any associated rules/configs/sensors associated to those users.

Never mind. i see how i can do it one by one.
thanks for pointing me to the debug tool and api.

Indeed, one by one is the only way supported by the Hue API.


Support ordering of model/relations

Problem
Original discussion: https://prisma.slack.com/archives/CKQTGR6T0/p1585298279075900
Imagine a schema like:
model Checklist {
    id            String          @default(cuid()) @id
    items         ChecklistItem[]
}
model ChecklistItem {
    id          String              @default(cuid()) @id
    content     String
    checklist   Checklist
}

Currently, there is not guaranty as to the order of ChecklistItem. The current work around is to create an ordering column and order by this column. It would be awesome if prisma could have a way to somewhat automatically do that.
Propositions

Order the virtual relation:
A new directive could be added: @ordered(by: String). This would be applied to the virtual relation  items ChecklistItem[] and would reference an explicit column in the model ChecklistItem. This still leaves use with the problem of filling the column though and maintaining the order.
Order the model:
A new directive could be added: @order. This would be applied to an Int column on the ChecklistItem. When creating a new item, prisma would make sure to insert the item at the right place and manage the int placed in it. See proposition 3 to see how.
Order via the client:
New arguments could be added to create and update (delete can be managed internally) inside ChecklistItemCreateArgs and ChecklistItemUpdateArgs. Those would be placement constraint for the model: after and/or before. Each one would be a new type that would be something like:

export type ChecklistItemOrderUniqueInput = {
  id?: number | null
}

A user could then specify between each currently created items he wants to place this new item or move an existing item. For example:
prisma.checklistItem.create({ data: { content: "My new item" }, after: { id: 5 } })

Great elaboration @Sytten
I would just like to point out that internally, it may be handled as linked lists rather than storing indexes since the index will also change every time one of the elements is deleted from the list.
It is something like the problem which I have mentioned in this issue: https://github.com/prisma/prisma-client-js/issues/589

Does anyone have examples of other ORMs or database clients implementing something like this?

No idea about ordering in other ORMs but I had to implement that in my rust codebase a little while ago.
I view that feature similar to cursor based support that prisma is kinda unique in providing.
You have globally two of approaches to do this that avoid write amplification (aka you don't need to update all siblings):

Lexical ordering. Atlassian Lexorank is a good place to get started on that topic. You can avoid rebalancing if you accept infinite strings.
Fractions ordering. Pinterest is kinda doing that. You can store them in very large int or float.

I decided to go with lexical because it is the simplest (I built a custom rust one but mudders exists), but you might prefer the numerical way.


Update ImageResizer sample, remove System.Drawing

Since automatic NuGet restore now works, remove the commented out code that used System.Drawing. Also cleaned up "using" statements that weren't needed.

👍 looks good


ServiceDefinition:NamedElementNameString doesn't allow ':' (colon) in name

cscfg scheme doesn't allow a colon : inside settings name, e.g.:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="OrangeJuice.Server.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
  <WebRole name="MyService" vmsize="Small">
    <ConfigurationSettings>
      <Setting name="test:a" />
    </ConfigurationSettings>
  </WebRole>
</ServiceDefinition>

Causing compiler error:

The XML specification is not valid: The 'name' attribute is invalid - The value 'test:a' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:NamedElementNameString' - The Pattern constraint failed.

@abatishchev This repo is actually for the MAML client libraries but I'll forward this thread to the Azure SDK team responsible for the cscfg schema internally.

+1 for this, it's a major pain as Serilog uses colon, I've currently having to build a special addition to use another character.
Be good to know the reason or if there was a way to protect the colon.

Any update on this, please?

This shouldn't be a blocking issue.  Just remove that colon from your setting, for eg., ,you can simply use yourConfigmanager.AppSettings["testa"]

This is the blocking issue if I want to use ns:test and there is no reason me to be disallowed to do so, should be I?

Any response, please?

Any update on this, please?

Any update on this, please?

@abatishchev Please file a support ticket for resolution on this. This repo is not manned by folks implementing the cscfg schema.

@singhkays hi Kay, is there a repo where this issue can be discussed, and maybe addressed?

@abatishchev Don't think the PaaS SDK is open sourced so there currently isn't a repo. Other than support, uservoice is probable a better venue for this feedback so that folks can vote on it and it gives the team a prioritization signal. https://feedback.azure.com/forums/169386-cloud-services-web-and-worker-role


Update TimeSeries stage to also work with Production DFP

Description

Update TimeSeries stage to also work with Production DFP pipeline instead of Starter DFP. Now accepts MultiMessage instead of MultiResponseMessage. Remove use of hard-coded event_dt and replace with config.ae.timestamp_column_name.
Tested updated TimeSeries stage with Duo and Azure production DFP pipelines.
As part of a Starter CloudTrail DFP pipeline, TimeSeries stage runs into issues when processing multiple batches, i.e. when repeat option in CloudTrailSourceStage is increased (increase input data size) or pipeline batch size is decreased. Pipeline either errors out or not all data is processed. Remove TimeSeries stage from AutoEncoder E2E benchmark for now and will create separate issue for this.

Fixes #1107
Checklist
[x] I am familiar with the Contributing Guidelines.
[x] New or existing tests cover these changes.
[x] The documentation is up to date with these changes.

/ok to test

/merge


Timestamptz lacks arithmetic (and more) operations

As described in the document both timestamp and timestamp with time zone can be operated with arithmetic operations, but diesel implements Add and Sub only ofr Timestamp. Similarly, as reported in #1514 , now should be able to be treated as timestamp with time zone.
I'll implement it, if it is acceptable.

:)

Resolved in #1657


Incorrect (NaN) Roughness after importing DAE's from Blender

Not sure if the problem is in this specific line, but it may as well be.
https://github.com/godotengine/godot/blob/9f479f096cb50fa8d1215e68c262f110116114ef/editor/import/editor_import_collada.cpp#L483
Blender has Hardness value ranging from 1 to 511. In Godot 3.0 it's 0 to 1. (I noticed, that Godot 2.1 has a different structure for this, as there is no numerical value to input for material roughness, and may or may not be because of this, it imports the same .dae file absolutely correct).
     So, the problem is that for bigger values of Hardness in Blender, Godot can't calculate Roughness to import. Material with Hardness 45 is imported all right. But the next one, with Hardness 325 returns "-nan".

Which makes the model all black.
     (If you are experiencing the same problem, for now this may be corrected by manually imputing Roughness value in Godot. (Below Roughness is changed from "-nan(ind)" to "1"))

Looks like I was right.

This only makes sence for values from 1 to 256, but making it /9 solves the problem and extends the function to 512.

I am preparing a PR for this.

Also, it is wrong, because the more Hardness you set in Blender, the less Rough it will be in Godot.
Will it be okay to fix this within the same issue?

The most obvious solution for this would be as follows:

1 in Blender is 0 in Godot and 511 in Blender is 1 in Godot.
But this also continues the old way, where the change from 1 to 8 in Blender covers 1/5 of the Godot range (0->0.2), which is the same (0.8->1) as from 399 to 511 in Blender. Is there any reason why this function is not linear?

More about flipping. I see that it says "shininess" in code, but I also see that it actually works as hardness.
So I think this should probably be corrected as well.

On the second thought, I should probably not mess with the code, as I can't test it, and problem may be deeper.
The correct code for .dae's from Blender 2.79b would be:
float roughness = - Math::sqrt(1.0 - ((Math::log(effect.shininess) / Math::log(2.0)) / 9.0)) + 1;
material->set_roughness(roughness);

But it may actually should be:
if it_is_actually_shininess && 256:
	roughness = Math::sqrt(1.0 - ((Math::log(effect.shininess) / Math::log(2.0)) / 8.0))

if it_really_is_hardness && 256:
	roughness = - Math::sqrt(1.0 - ((Math::log(effect.shininess) / Math::log(2.0)) / 8.0)) + 1

if it_is_actually_shininess && 512:
	roughness = Math::sqrt(1.0 - ((Math::log(effect.shininess) / Math::log(2.0)) / 9.0))

if it_really_is_hardness && 512:
	roughness = - Math::sqrt(1.0 - ((Math::log(effect.shininess) / Math::log(2.0)) / 9.0)) + 1

material->set_roughness(roughness)

I have no idea, how to implement this and whether it is actually needed (need to know, how Collada works). So any insights would be appreciated.

This an exported Test Sphere.zip test file with 3 spheres. From left to right with increasing hardness of 005, 250 and 450.
Also, I opened .dae files, and found out, that they do really use term "shininess" in them, while describing hardness. Both Default and Better.

Seems to me you just need to divide by 9.0 rather than 8.0
also to make it more correct (such that 511 maps to 0 exactly), you can multiply effect.shininess by (512.0/511.0)

"exact" meaning as far as floating point arithmetic goes

@tagcup Blender only sets it from 1 to 511. And the result is clearly reversed.

Yes, this is why you need to do
float roughness = Math::sqrt(((Math::log(effect.shininess * (512.0/511.0)) / Math::log(2.0)) / 9.0))

such that shininess = 1 maps to 0 roughness and shininess = 511 maps to 1 roughness

Please look, why this is not a good solution.

_https://www.desmos.com/calculator_
I didn't see at first, that you have aslo removed "1-" from under the square, but this is what I don't approve. The function is already diminishing towards the bigger numbers, which basically makes all values of Blender hardness above 400 nonimportant. But what you propose, extends it even further. At value 10 your function covers 0.6 of Godot space, at 150 already returns 0.9, and at 400 basically reaches 1. The transformation is correct, but values are just not satisfying.
     Also, about 511 and 512. Godot only calculates roughness as x.xx, so anything, which is biger than 0.995 is 1. I see now, why you are not happy, because in my case we only reach 0.98, as 512, where we should get 1, can never be inputed. But considering everything else, I see this as good result. Especially comparing to current one. You can easily understand, after importing, that your roughness is not what you were expecting, and tweak it. But it took me quite some time to just realise, the the problem IS in roughness, as I was just getting black meshes for no reason.
     On this problem, I can answer you with this function:

which reaches 0.9999 (which is 1) at 511, preserving all other transformations. This is less elegant, but it is as good, as it gets, in my opinion.
We may also try to summon @reduz on this issue, as it was he, who introduced both the code and the comment in this https://github.com/godotengine/godot/commit/6f2e16306a6552d704fb2346c9abdd26e0e523b7 commit. But I'm not sure if this is going to be considered.

The reason why numbers larger than 400 aren't important is because that's log scale. Roughness can be 0.999, you're confusing UI with the code.
And you can't arbitrarily add and remove a number under different powers because that introduces nonlinear artifacts.
Anyway I don't see why you're making such a big deal out of it. Your PR is wrong, I already explained why three times. Do whatever you want to do, I'm done

My thoughts exactly, I already provided everything I could. I know that this value is calculated once per import, and that math is correct. So nothing wrong can happen to it.
I am just waiting for people, who will make the decision.


MDT version for Win10 v1909

MDT build 8456, as of today 12/31/2019, does not list ADK 1903 as supported. So, what version of MDT and ADK should be used for ConfigMgr 1906 or 1910 to deploy Win10 v1909?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: dc732ec0-eb14-8da2-7688-dd74a72cdae5
Version Independent ID: a93682ff-2984-38e0-5a0d-6f77c1c9e5db
Content: Support for Windows 10 - Configuration Manager
Content Source: sccm/core/plan-design/configs/support-for-windows-10.md
Product: configuration-manager
Technology: configmgr-other
GitHub Login: @mestew
Microsoft Alias: mstewart

Hi @say2wc, please see this FAQ: https://docs.microsoft.com/configmgr/mdt/release-notes#bkmk_note2
I'm closing this issue, as this article is strictly about ConfigMgr support for Windows 10. For MDT support, see the MDT release notes.


Minimum requirements to compile ScottPlot 4.1.60 ?

I am looking to download the source from github and step thru the winform demos after running the executable demos.  Will ScottPlot4.sln compile in Visual Studio 2019 ?

Hello, it should work fine and without modification on Visual Studio 2022 (and presumably Rider), as the issues come from newer language features. There is a post on developing with VS19, as well as I believe a python script to automate the changes: https://scottplot.net/faq/environment/
If you only need to compile, I believe dotnet build should work fine.


Using a proxy server when getting options data

Hi, is it possible to specify a proxy server with "yf.Ticker('AAPL')"?
I am downloading options data and would like to use a proxy.
Thank you.

Yeah, I want to know if this is a feasible option. Download option data is too bulk of data and it is better to do with proxy.


Update knownfolders_getfolderforuserasync_705109113.md

Added specific details about what "current user" means.

@laurenhughes : PR passed acceptance checklist. Please evaluate further. Thanks!


Reorganize repo to put types near the corresponding classes

types are bucketed together in types.py, but should be spread out to be associated with the objects they refer to (e.g. wallets should be with agents, MarketState should be with market, etc)

Added in #235


render() method should return a valid template in flowWizardRouter

Hey James, great stuff. I was looking at the code, and noticed this:
https://github.com/tsalb/lwc-utils/blob/09ceedcd361ed552f7e44e25c9e8c9deb0c1e2cf/force-app/main/default/lwc/flowWizardRouter/flowWizardRouter.js#L24
which returns null for some conditions, but that is not longer valid code in later version of LWC.
normally, what you can do now is to have a HTML file with empty template. import it, and return it instead of null, that should have the same effect.

Thanks @caridy, I hacked the router together yesterday night and I wasn't quite sure of the behavior of templating when none were desire - but it's good to have confirmation from the source.
Will update accordingly soon.


Crowdsourced "grading" of transformations

Let's face it, some of the synopsis transformations are better than others (looking at you, Tarzan). It would be great to have a large corpus of potential movies for people to guess from, but rating those transformations could be a lot of work for one person to do. We could create another page on the app that allows people to "grade" a transformation as either Good, Neutral, or Bad/Unintelligible, and then use that to assign a small weight to the likelihood of that movie coming up in the other experiences on the page.
Note: I would want to have a cap on how good or bad something could be, say 3 points, for example. That way, even if a movie is rated good 100 times, it still only has the weight of 3. This would keep any one movie from taking over and coming up every time.
Another note: If we only have a hundred different movies to choose from, then this wouldn't be a big deal. We really just need it if we have too many movies to manually review and quality control. If we get a large number of movies that are terrible, then the rules probably need to be revised.

I just used Tortus to do this myself and separate them into Good, Okay, and Bad quality groups. I'm still open to this, but it's not necessary for the app to work well.

Didn't mean to close it. I'm not planning to work it, but I thought I'd leave it open so I don't forget the idea.


Feature/gen 297

All about sales

Looks good on first read!  I think there're a few typos, though.  For example:
"The Data Control Center is a materialization of the data control plane, which more of an abstract notion."  The wording is amazing-- it concisely conveys our passion and excitement about the tech we work with-- but it needs an "is..!"
I'll take another pass at it once the network's back up!

Looks good on first read! I think there're a few typos, though. For example: "The Data Control Center is a materialization of the data control plane, which more of an abstract notion." The wording is amazing-- it concisely conveys our passion and excitement about the tech we work with-- but it needs an "is..!" I'll take another pass at it once the network's back up!

I am not sure what you are referencing (but I can search). To make it easier, you can start a review and make the suggestion inline to show where it belongs. Then submit the review with one of the options. That will also give you the credit for reviewing.

Looks good on first read! I think there're a few typos, though. For example: "The Data Control Center is a materialization of the data control plane, which more of an abstract notion." The wording is amazing-- it concisely conveys our passion and excitement about the tech we work with-- but it needs an "is..!" I'll take another pass at it once the network's back up!

I am not sure what you are referencing (but I can search). To make it easier, you can start a review and make the suggestion inline to show where it belongs. Then submit the review with one of the options. That will also give you the credit for reviewing.

Ah, you were reading the product roadmap, which wasn't changed for this PR. So useful but unrelated.


_posts/0000-01-02-jjsmith1.md

Add jjsmith1's file
created a branch, created a file and made a commit, and opened a pull request

Proper filename correction to _posts/0000-01-02-jjsmith1.md

attempting to commit

lab for module 2 complete !!!!!!


App Freezing due to keyboard not closing on page change on device.

App Freezing due to keyboard not closing on page change on device.
Ionic Info
Ionic:

   ionic (Ionic CLI)             : 4.5.0 (/home/optima/.nvm/versions/node/v10.3.0/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.0.0-beta.16
   @angular-devkit/build-angular : 0.10.6
   @angular-devkit/schematics    : 7.0.6
   @angular/cli                  : 7.0.6
   @ionic/angular-toolkit        : 1.2.0

Cordova:

   cordova (Cordova CLI) : 8.1.2<EMAIL_ADDRESS>   Cordova Platforms     : android 7.1.3
   Cordova Plugins       : cordova-plugin-ionic-keyboard 2.1.3, cordova-plugin-ionic-webview 2.2.5, (and 6 other plugins)

System:

   Android SDK Tools : 26.1.1 (/home/optima/Android/Sdk)
   NodeJS            : v10.3.0 (/home/optima/.nvm/versions/node/v10.3.0/bin/node)
   npm               : 6.1.0
   OS                : Linux 4.15

Describe the Bug
My app freezes whenever i submit a form which navigates to another page without closing the keyboard that pops up after tapping the input field. I have tested it numerous times, my app freezes only when i don't close the keyboard before submitting the form.
Has never happened to me before, i don't know if this is the real reason. Or is it because of the beta ??
Steps to Reproduce
Steps to reproduce the behavior:

Go to any form page  '...'
put random input fields '....'
before you submit your form don't close the keyboard '....'
navigate to another page after that

Could you please create a repo for that? My app not freezes when I submit a form and the keyboard is open


unityplayer.dll error ZZZ

Checklist

[X] I have already read docs/Tips.md, but my question is not solved.
[X] My question was not mentioned by others, and it is not a duplicate question.

Description

Starward Version
0.12.0
Windows Version
22631.2861
Log
No response
Additional Context
No response

星穹铁道也遇到了类似情况

Try repair game.

Try repair game.


Error Navigate to other children of GetPage

Describe the bug
i have route like this

manage user

new user

registered user

saved user

details user
in the app pages i have GetPage contains that 4 children. when i am in the "/manage user/new user" then get.to("/manage user/details user") its return error child == _child : is not true

**Reproduction code
in my app_pages.dart
GetPage(
        name: _Paths.MANAGE_USER,
        page: () => ManageUserView(),
        binding: ManageUserBinding(),
        children: [
          GetPage(
            name: _Paths.REGISTERED_USER,
            page: () => RegisteredUserView(),
            binding: RegisteredUserBinding(),
          ),
          GetPage(
            name: _Paths.NEW_USER,
            page: () => NewUserView(),
            binding: NewUserBinding(),
          ),
          GetPage(
            name: _Paths.SAVED_USER,
            page: () => SavedUserView(),
            binding: SavedUserBinding(),
          ),
          GetPage(
            name: _Paths.DETAILS_USER,
            page: () => DetailsUserView(),
            binding: DetailsUserBinding(),
          ),
        ]),

final http.Response response =
          await FarmerRegisterRepository.upload(data, onSend);
      if (response.statusCode! >= 200 && response.statusCode! < 300) {
        if (response.data["status"] == "success") {
           //the error will show up when below executed
           //MANAGE_USER = "/manage-user" DETAILS_USER = "/details-user"
          Get.toNamed(Routes.MANAGE_USER + Routes.DETAILS_USER);
          //  /manage-user/new-user ==> /manage-user/details-user
        }
      }

To Reproduce
Steps to reproduce the behavior:
the new-user page contains form (to register user)
4. See error
======== Exception caught by widgets library =======================================================
The following assertion was thrown while finalizing the widget tree:
Duplicate GlobalKeys detected in widget tree.

The following GlobalKeys were specified multiple times in the widget tree. This will lead to parts of the widget tree being truncated unexpectedly, because the second time a key is seen, the previous instance is moved to the new location. The keys were:
- [GlobalKey#c247d]
  [LabeledGlobalKey<OverlayState>#d5ee0]
This was determined by noticing that after widgets with the above global keys were moved out of their respective previous parents, those previous parents never updated during this frame, meaning that they either did not update at all or updated before the widgets were moved, in either case implying that they still think that they should have a child with those global keys.
The specific parents that did not update after having one or more children forcibly removed due to GlobalKey reparenting are:
- IgnorePointer(ignoring: false, renderObject: RenderIgnorePointer#0f539 NEEDS-LAYOUT NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE DETACHED)
  UnmanagedRestorationScope
A GlobalKey can only be specified on one widget at a time in the widget tree.
When the exception was thrown, this was the stack:
#0      BuildOwner.finalizeTree.<anonymous closure> (package:flutter/src/widgets/framework.dart:2939:15)
#1      BuildOwner.finalizeTree (package:flutter/src/widgets/framework.dart:2964:8)
#2      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:879:19)
#3      RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:330:5)
#4      SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1143:15)
#5      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1080:9)
#6      SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996:5)
#10     _invoke (dart:ui/hooks.dart:164:10)
#11     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:259:5)
#12     _drawFrame (dart:ui/hooks.dart:127:31)
(elided 3 frames from dart:async)
====================================================================================================

Expected behavior
A clear and concise description of what you expected to happen.
I test to change the route to other route like Routes.SETTINGS and its no problem.
Screenshots

Flutter Version:
LATEST
Getx Version:
4.3.4
Describe on which device you found the bug:
Redmi 8
Minimal reproduce code

This does not appear to be a GetX related error. Check the Widget Form's GlobalKey. If the route is called a second time and is still in Flutter's navigation stack, the GlobalKey will repeat and the error occurs.

Describe the bug
i have route like this

manage user

new user

registered user

saved user

details user
in the app pages i have GetPage contains that 4 children. when i am in the "/manage user/new user" then get.to("/manage user/details user") its return error child == _child : is not true

**Reproduction code
in my app_pages.dart
GetPage(
        name: _Paths.MANAGE_USER,
        page: () => ManageUserView(),
        binding: ManageUserBinding(),
        children: [
          GetPage(
            name: _Paths.REGISTERED_USER,
            page: () => RegisteredUserView(),
            binding: RegisteredUserBinding(),
          ),
          GetPage(
            name: _Paths.NEW_USER,
            page: () => NewUserView(),
            binding: NewUserBinding(),
          ),
          GetPage(
            name: _Paths.SAVED_USER,
            page: () => SavedUserView(),
            binding: SavedUserBinding(),
          ),
          GetPage(
            name: _Paths.DETAILS_USER,
            page: () => DetailsUserView(),
            binding: DetailsUserBinding(),
          ),
        ]),

final http.Response response =
          await FarmerRegisterRepository.upload(data, onSend);
      if (response.statusCode! >= 200 && response.statusCode! < 300) {
        if (response.data["status"] == "success") {
           //the error will show up when below executed
           //MANAGE_USER = "/manage-user" DETAILS_USER = "/details-user"
          Get.toNamed(Routes.MANAGE_USER + Routes.DETAILS_USER);
          //  /manage-user/new-user ==> /manage-user/details-user
        }
      }

To Reproduce
Steps to reproduce the behavior:
the new-user page contains form (to register user)
4. See error
======== Exception caught by widgets library =======================================================
The following assertion was thrown while finalizing the widget tree:
Duplicate GlobalKeys detected in widget tree.

The following GlobalKeys were specified multiple times in the widget tree. This will lead to parts of the widget tree being truncated unexpectedly, because the second time a key is seen, the previous instance is moved to the new location. The keys were:
- [GlobalKey#c247d]
  [LabeledGlobalKey<OverlayState>#d5ee0]
This was determined by noticing that after widgets with the above global keys were moved out of their respective previous parents, those previous parents never updated during this frame, meaning that they either did not update at all or updated before the widgets were moved, in either case implying that they still think that they should have a child with those global keys.
The specific parents that did not update after having one or more children forcibly removed due to GlobalKey reparenting are:
- IgnorePointer(ignoring: false, renderObject: RenderIgnorePointer#0f539 NEEDS-LAYOUT NEEDS-PAINT NEEDS-COMPOSITING-BITS-UPDATE DETACHED)
  UnmanagedRestorationScope
A GlobalKey can only be specified on one widget at a time in the widget tree.
When the exception was thrown, this was the stack:
#0      BuildOwner.finalizeTree.<anonymous closure> (package:flutter/src/widgets/framework.dart:2939:15)
#1      BuildOwner.finalizeTree (package:flutter/src/widgets/framework.dart:2964:8)
#2      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:879:19)
#3      RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:330:5)
#4      SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1143:15)
#5      SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1080:9)
#6      SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:996:5)
#10     _invoke (dart:ui/hooks.dart:164:10)
#11     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:259:5)
#12     _drawFrame (dart:ui/hooks.dart:127:31)
(elided 3 frames from dart:async)
====================================================================================================

Expected behavior
A clear and concise description of what you expected to happen.
I test to change the route to other route like Routes.SETTINGS and its no problem.
Screenshots

Flutter Version:
LATEST
Getx Version:
4.3.4
Describe on which device you found the bug:
Redmi 8
Minimal reproduce code

1- you can not add empty spaces on route name
2- you can not to use Get.to to namedRoutes (use Get.toNamed)


Sort submission list in the react app by id just as the submission list view

The view at /apply/submissions/all/ sort submission by submission id.
The react app at /apply/rounds//? sort the submissions in the left column by latest activity.
We would like that to sort by submission id as well so the list is sorted the same in different views. Makes it easier to locate submissions.

@frjo if the issue is finding things in the list would we be better places to provide some means of search?

Search would be good as well but they really want the lists to be ordered the same way. Seems to be important for their workflow.
Sent with GitHawk

Chris to check both instances of the listings and confirm the sort order on both (list view e.g. https://test-apply.opentech.fund/apply/rounds/732/ and the sort order within a grouping on the detail view e.g. ordering within 'Accepted' status on https://test-apply.opentech.fund/apply/rounds/732/?submission=17).
Following this we will confirm with @fourthletter what the correct sort order should be and adjust one of the lists.

Hi @fourthletter
Following on from Maya's comment above I can confirm the:

list view default ordering is by last updated
grouping on the detail view has no default ordering applied

Would you like the grouping on the detail view to be ordered by last updated or do you have another preference?

@chris-lawton "grouping on the detail view to be ordered by last updated" would be great. Thanks!
The use case is Person A uses the list view to facilitate a meeting and lead the discussion while Person B uses the detail view for note-taking. We do not need these views to be mirror images or exact replicas, but it difficult for Person B to write notes about what Person A is discussing when the order is completely different. Confusion occurs when several applications are being discussed.

Ready for internal testing on dev.
Example:
Ordering of items here (by last updated) - https://dev-apply.opentech.fund/apply/rounds/732/?status=dismissed&query= should now be reflected in the 'dismissed' column here https://dev-apply.opentech.fund/apply/rounds/732/?submission=3

Looks good, this can be deployed to test

Features are functional during test. Thanks! 💥


Use multiple GPUs per node in YARN mode

The documentation for MNIST EC2 example states that we can set the NUM_GPU environment variable to specify how many GPUs we want to be used per node. Is the same true for Hadoop based YARN clusters as well?

The --num_gpus flag can be passed to the yarn application to specify the number of GPUs to be used per node.


Use private for private members in classes instead of #

PR-Codex overview
This PR updates code across multiple packages to replace # with private for private members in classes.
Detailed summary

Replaced # with private for private members in classes across various files
Updated classes: EngineWallet, GcpKmsWallet, CoinbasePayIntegration, SignerWallet, FrameConnector, InjectedConnector, EthersWallet, Cache, AsyncWallet, PrivateKeyWallet, TransactionError, BasicLogger, PhantomConnector, RainbowConnector, MetaMaskConnector, AwsKmsWallet

The following files were skipped due to too many changes: packages/wallets/src/evm/wallets/aws-kms.ts, packages/wallets/src/evm/connectors/paper/index.ts, packages/wallets/src/evm/connectors/magic/index.ts, packages/wallets/src/evm/connectors/local-wallet/index.ts, packages/wallets/src/evm/connectors/signer/index.ts, packages/wallets/src/evm/wallets/local-wallet.ts, packages/wallets/src/evm/connectors/embedded-wallet/index.ts, packages/wallets/src/evm/wallets/base.ts, packages/wallets/src/evm/wallets/aws-secrets-manager.ts, packages/wallets/src/evm/connectors/coinbase-wallet/index.ts, packages/wallets/src/evm/connectors/blocto/index.ts, packages/wallets/src/evm/wallets/wallet-connect.ts, packages/wallets/src/core/WalletConnect/WalletConnectV2Handler.ts, packages/wallets/src/evm/connectors/wallet-connect/index.ts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

/release-pr


Problems running Jupyter and python file

Does not allow to install python libs for jupyter notebook runs

/needsMoreInfo


[Fix] indentation for deploy, ds and pod annotations

Fix issue introduced by myself in #179, which I fix in local but forgot to commit, sorry about that.
Setting podAnnotations or lapi.podAnnotations  break the manifest because of a bad indentation and {{-, so it produce something like this:
values.yaml
podAnnotations:
  allPods: test

agent:
  daemonsetAnnotations:
    agentDs: test
  podAnnotations:
    agentPod: test
  acquisition:
    - namespace: ingress-nginx
      podName: ingress-nginx-controller-*
      program: nginx

lapi:
  deployAnnotations:
    lapiDeploy: test
  podAnnotations:
    lapiPod: test

result
[...]
spec:
  template:
    metadata:
      annotations:
        checksum/agent-secret: 33b575d4037387fc40a4e87bf644d8ef410d911d42cf9ac5c16c81f6f9208cd7
        checksum/lapi-secret: 6a759b5ae3a48ec705b7af68a0947c9e286ccae6d02a73f922e32d0fe88bfc4c
        checksum/lapi-configmap: f1c5b812195242564e3d57e5d84245ceb46d079f41fa31843ec56f51d011b77e        allPods: test        lapiPod: test
[...]

Sorry again about that issue.

/kind fix
/area configuration


Fix: Incident but by updating user_id path

Summary | Résumé
Updated path to user id from body

I believe source issue came from here: https://github.com/cds-snc/sre-bot/blob/a65e7fab2f1687204aa3db7efb5fdac1f43e24ca/app/commands/incident.py#L182

Fixes: https://github.com/cds-snc/sre-bot/issues/133


Adding logic to handle prop that end in "ref(s)"

Resolves issue #46
If substring "ref(s)" in the property name, it generates a ListProperty with a subclass of ReferenceProperty, solving the ValueError. It detects the valid_type by looking at the spec's stix-type

Codecov Report

Merging #47 (38dbd3a) into main (04df298) will decrease coverage by 0.05%.
Report is 2 commits behind head on main.
The diff coverage is 77.77%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##             main      #47      +/-   ##
==========================================
- Coverage   90.54%   90.50%   -0.05%
==========================================
  Files          35       35
  Lines        3470     3474       +4
==========================================
+ Hits         3142     3144       +2
- Misses        328      330       +2

Files
Coverage Δ

stix2generator/stixcustom.py
88.70% <77.77%> (-2.67%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Thanks for the bug report and the PR! The build failure is caused by a style issue:

./stix2generator/stixcustom.py:75:1: W293 blank line contains whitespace