feat: 2.0.0 - Merged multi-Zigbee2MQTT #176
Conversation
|
Is this coming to windfront-edge for testing? It looks like a dream come true! |
|
As soon as it is merged yes. I'll add some details in the first post for testers to focus on (at least in the beginning). |
|
I like it. Installed the 2.0.0 Edge Add-on. The first thing I've noticed that I have a suggestion for is the Permit Join selection. For ease of use I think it would make sense to have the "All" option for the different controllers at the top. 99% of my Permit Join is to open the entire network, for the second controller I'll have to scroll through a very long list of devices before I get to the "All" for that controller. I'd also prefer if the default sort/grouping of the device list was based on name of the device. Right now the list is grouped by controller. To me the real benefit of merging the lists is to be able to see them fully merged. If I need to scroll down to see the devices of the second controller then I can just as easily switch controller. During the short period I've used the new interface my first action is to click the Friendly Name to get all devices sorted by name and not grouped by controller. |
|
In the Logs tab there is something going on with placement of a couple of selections and buttons. I don't think this is the intended layout: |
|
@KoalaWerewolf all should be fixed in the latest |
|
My feeling is that the old UI had some sort of default sorting from the config file, last device at the bottom. Windfront seem to have sorted on name by default. I think that now that you added the Source column as the first column it defaulted to a sort on that. The first controller in my Windfront config was on top. I like the new behaviour, and the Permit Join was included in that as well. |
|
With the addition of multi, it added rows for each source in succession, which resulted in a seemingly "per source" sorting. |
|
Testing on mobile right now. I think it's really great. It gets back the single view that I lost when splitting my network. Thanks! Some area for improvement:
|
|
Edge AddOn Auto-Update doesn't work, indeed I couldn't get HA to detect an update, instead I had to uninstall and reinstall AddOn. Love the combined interface! Literally a dream come true! Even if you change nothing, I'd still be happy, but here's my constructive feedback... API names are much less discoverable. It would be great to add tooltips for desktop use (e.g., on the connection column, allow-join drop-down). Took me a while to figure out what the new notification menu was, and it's the only way to find which colour is for which connection. Can I suggest you add a multi-select dropdown in the connection column header that allows you to filter by collection and simultaneously see which colour is which API (similar to the search boxes in the other headers)? Similarly, perhaps add the API to the details 'About' tab. In the 'Allow Join' dropdown having a bunch of 'All's at the top is less useful than perhaps 'All Local', 'All Upstairs', 'All Downstairs', 'All Extension', etc. which would again increase visibility of colour<->API correspondence. The clear filter icon against the column searches isn't immediately obvious. Can I suggest you replace it with a classic 'x' and either disable/hide it when the filter is empty? It would be useful to have filters for the other columns too. This can be done creatively. For example, multi-selects for connection, LQI (Red <= 74?, 74 < Yellow <= 126, White > 126), Last Seen (Just now, < 1 min, 1 - 10 min, 10min-1hr, 1hr-1day, > 1 day), Availability (Online, Offline, Disabled). If you can find a useful multiselect control it would also make the lining up more visually pleasing. And it's never gonna happen, but I can't resist asking for my number one remaining feature request, and that's groups of groups (hierarchy) - but that requires Z2m support, and needs it to maintain zigbee groups automatically (i.e. expanding out a child group). With the new merged UI, it would be awesome if it could also handle cross API grouping. I currently have 64 groups across the APIs, like All Downstairs, All Upstairs, etc. which are then grouped in HA to 'All'. But each of those groups has to manually group, the child groups. |
@thargy See 1. above for the source names. I've pushed several fixes that should now be available in latest edge. Let me know how that goes. 😉 |
|
Tried the latest edge release. The device page is ”jerky” and reloads when scrolling. It is difficult to manage to scroll to the bottom of the page. Let me know if you need any diagnostics from me. This is when testing on a mobile device, iPhone. |
I'm not observing the icon change you mention, or the new option in settings.
I'm also observing the jank that @KoalaWerewolf is reporting on the new version. Looks like devices are being lazily loaded, but not fast enough. That said, tab switching speed is much improved. Opening Devices and Groups is ~500ms, but Dashboard is still more like 2s.
Here's what I've observing with the logs:
Confirmed. |
|
@KoalaWerewolf Can you elaborate on what you mean by "difficult", is it the behavior change that caught you off-guard, or do you see actual problems with the scrolling (not loading properly, etc.)? |
That's in the frontend-specific settings (the display icon next to |
Ah hah, I see it now, yes. I was looking in
I see that now, but that's not what I was actually reporting originally. In the devices page on my phone, every device has an unlabeled colored dot next to it, indicating what instance it belongs to. On desktop, it's labelled, but not on mobile. When I first opened Windfront Edge, I had no idea what the colors meant. Even now, though, the colored dots on the Devices page don't really help my understanding on mobile because I have no idea which instance corresponds to which color. I can of course go look that up by looking on another page, opening the "permit join" drop-down, etc, but that's not a great UX. I'm extremely unlikely to remember than my A instance is yellow and my C instance is blue. |
The loading of devices seems to trigger a reload of the page and the scrolling starts from the beginning again. I recorded the behavior but I haven’t got the file below 10MB yet. |
Works greatShow source name is great! I've split my feedback into numbered subheadings to make it easier for you to reference. Issues1 - Lazy load
2 - Logs
Suggestions3 - CommitThere's no prominent place to discover which commit the edge version is we're using, I'd suggest adding a commit link under the frontend version in Settings->About, as exists for Z2m version (though tbf that usually says 'unknown' too!). That would help us submit a review more effectively, especially during rapid development. 4 - Numbering/CountWith the loss of the numbering column and the inability to filter based on API, there is no longer an easy way to see the device count per coordinator, from the devices tab. Pairing has been flaky in the past particularly on large networks or when devices require an esoteric pairing methodology. My previous practice was to see the device count on the coordinator (by looking at the numbering) and ensure it increased. The global count would also increase, but for maximise reassurance seeing the coordinator count would be helpful. I appreciate there are other methodologies, just want to explain how the change affects my usage. 5 - API InfoWould still like to see source details in 'info' tab of device (when multi-source), there's space there to show colour, API_NAME and API_URL. These should also be added to the Settings->About tab (at least the API_URL). 6 - API ConfigAuto API_NAME, as we're using the name in more places on the UI, creating a name automatically when one isn't supplied would be a good idea. The easiest way would be to take just the hostname from the URL. Where duplicates are found, you can continue to add components until they are distinguished (e.g. port, and step along the path). An alternative is to enforce naming, for example by changing the config to accept key-value pairs, e.g Enforce API URLs wrapped in double quotes Network map7 - CirclesI struggle to understand the map logic, in particular the circles. Sometimes the circles have a device name, other times it's the device name + 'Children', sometimes both exist for a device. The circles have one or more devices inside them, so they appear to be a grouping; however, that doesn't work when you switch to 3D mode (presumably they should be spheres in 3D, but they are circles on a single plane). 8 - ColoursIt appears Routers are in blue, endpoint devices (I only have a couple!) are in green, and yellow is the coordinator, but a key would help. 9 -EdgesSome parent edges appear to have arrows at both ends. What does that mean? When changing which edges are shown the node sizes can increase and overlap the arrow heads. What does the arrowhead indicate? I would expect one of the following (in preference order):
or
or
I can't tell which is true, and so a legend would help. Addendum10 - IEEEThe IEEE address is not that useful to the 'average' non-technical user. I would not have the column displayed by default on the devices page. Similarly, I wouldn't put it in the header/dropdown or the About title in the device details. That's particularly important for the About title, as it has a rename button next to it, which has nothing to do with the IEEE. Instead, I'd move the IEEE to its own detail section on the About tab. The OTA page includes the IEEE in the name, which is inconsistent with the devices page. Again, I would put it in its own column and not display it by default. Notably, it's not present at all in the dashboard (which is fine). 11 - Dashboard SearchThe Dashboard search has a big 'X' clear filter outside the box, and one that appears inside the box. This needs to be made consistent with the Devices filter style. The dashboard search only searches by friendly name. It could also search IEEE and model (as in devices). It would be nice to utilise that space with more filters (again like devices), this could be done with an 'advance search' popup. |
|
Fantastic 😃 PS: there's a small legend already, above the network map. For the arrows, e.g. "[child] EndDevice -> Coordinator", as in "EndDevice is child of Coordinator", e.g. "[parent] Coordinator -> Router", as in "Coordinator is parent of Router". The big problem is, this data relies of what devices report, and often enough, that data can be stale, or even plain wrong (Tuya...), so connections sometimes don't make sense... There isn't much we can do about that though, as "correcting" these would raise the issue of "which is right". |
|
Here's a recording of scrolling in Firefox on Mac OS. I've removed Friendly Name for privacy, you can still easily see that the page resets to the top continually. I updated the Add-on earlier today, AFAIK this is the latest code. Screen.Recording.Windfront.mov |
|
I added a few more observations to my initial feedback |
|
If I can get some quick feedback on the scrolling issues with latest |
|
Two thumbs up from me. Buttery smooth scrolling, plus page load time is now less than 500ms. New dashboard layout is a nice improvement too -- my lights are small and most of my switches are huge, and the layout looks great. |
Nailed it. Tested on edge, and HA iOS app. Scrolling is excellent on both. There is a barely perceptible delay as it loads data on edge whilst scrolling quickly, but it is hardly noticeable, on iOS it is invisible. Performance is stunning. Love the new masonry layout on the dashboard too. This is going to be a real game-changer when it goes to prod! |
|
Works great! |
|
@thargy
|
|
Great work! Here's my feedback which I hope you find constructive.
👍🏻
I looked for the connection filter in the column header, where it would make most sense, but I'm guessing the library you have doesn't support a listbox in headers? At least it's available though.
Nice update
Understood, though the use of the comma separator is a potential problem due to the URL spec. collision. It is unlikely to happen for most use cases though.
It draws a circle around groups in forceDirect2D and forceDirect3D. However, in forceDirect3D those circles are actually drawn on a plane, and as soon as you rotate the map they no longer make any sense., hence I suggested they should be a sphere in such a scenario (which I appreciate is easier said than done). Arguably, you can't use the circles in forceDirect3D, as the whole point of 3D is the rotation ability. 
Here's an example of the 3D view on rotation, note these 'circles' even disappear when you get them edge-on!
Yes, I've switched to icons by default.
Fair enough for the paginating table column, however, in the device details page, you still include the IEEE in the actual title, both of the tab and in the editable title field, even though you can't edit the IEEE. It strikes me that the IEEE should be just another detail in the table below. Note: the title's edit button appears immediately after the IEEE, which cannot be edited.
Yeah, I noticed the same thing in the filter boxes now. Have you tried something like: /* Hides the 'x' in search inputs on WebKit-based browsers (Chrome, Safari, Edge, Opera) */
input[type="search"]::-webkit-search-cancel-button {
-webkit-appearance: none;
appearance: none;
display: none;
}
/* Hides the 'x' in text inputs on Internet Explorer 10+ */
input[type="text"]::-ms-clear {
display: none;
width : 0;
height: 0;
}Which I believe hides the browser's x for all the common browsers (Firefox doesn't have a clear button I think). That means you can rely on your own
Yeah, these are great. SuggestionFiltering of devices is a common problem that applies to Devices, the Dashboard and OTA. Although you choose different filters for each view, that isn't strictly necessary; for example, searching by available firmware version may be most useful in OTA, but it's not useless in any of the other views. The column header form of filtering is currently mainly limited to text filters, with some checkboxes and buttons, and isn't available for everything. The UX style of these filters differs from that of, say, the Dashboard filters. The column filters produce fat headers. This reduces screen real estate on mobile. It may be better to have a single devices filter pop-up that is shared across each page (Devices, Dashboard, OTA). This filter could also apply across all the pages, meaning if I'm currently viewing 'Sensors', switching between the pages would not remove the filters. The filter pop-up can be opened by a button from the master header, again, reducing screen space, and can be highlighted when any filters are active. This would provide a consistent filtering experience across pages, reduce screen real estate, allow filtering to persist across views, and allow for richer filtering (e.g last update filters, more use of multi-selects (e.g. for sources, routers/end-point, features, properties, etc.) I feel like the ideal solution is to have a simple search text box that searches all text fields, and then have an advanced filters button next to that, that opens the pop-up. That pop-up would That is a commonly recognised pattern. Consider Outlook: The filter icon (which is consistent in Windows and iOS/Mac) opens the pop-up: Where you can search text fields explicitly as well as access some other useful filters. I have included a fully worked up 
|
|
@thargy About the unified filtering, this is not currently doable as the tables use a specific method of filtering. It's a pretty big refactor. |
That would be my recommendation for fixed3D
👍
Fair enough, the CSS I provided works in my testing to do that.
I suspected that might be the issue.
I've certainly been there!! I suggest we move the suggestion to an issue and put it on the backlog? I do believe it's a worthwhile enhancement, but appreciate it needs to be pushed to a major revision, as it would change the UX substantially for existing users. Putting in an issue and opening it for discussion/debate would allow the community time to feedback on a design prior to implementation, and build support, whilst reducing churn and wasted dev time. Overall, we're onto relatively minor feedback (i.e. this is polish, though the work in implementing some elements might be significant). This PR represents a huge step forward, particularly for multi-instance systems, which are required for larger networks. In my own testing the sweet-spot for devices per controller/frequency is around 70-90. The lazy loading, performance improvements and filtering will provide a win for single instance users as well. As such, we've kind of hit the limit of what a small user base is going to find in user acceptance and are probably ready for general release (maybe after implementing 10?) This is a real step forward for Z2m users and you should be applauded! |
|
@0rsa I saw you were using multi-instance. A lot has happened in that area since last release, if you want to give current |
|
Installed using Docker It's night and day in terms of performance compared to the 1.8, the UI is completely smooth, even with a large list, amazing! About the main nav: I spent some time to understand that there are 2 actions on a single item (you can click directly on the item, or click on the arrow to display a dropdown of your coordinators). The hover effect of the item does not help to understand because there is a single hover for both actions. I would say that you should at least separate the hover effect (one on the label, one on the arrow, as is done for the dropdown at the top right which allows pairing) Dropdowns do not close when you click outside and you can stack multiple dropdowns at the same time (especially when you didn't understand how the nav dropdowns work at the beginning ahah) I had an issue regarding the logs clear buttons (both: clear & clear all ; besides, I'm not sure I understand the difference between the two buttons), the UI was not refreshing but I'm currently not able to reproduce it. I will pay attention to this point to try to find the exact scenario. (update: I found a reproducible case: if you open the logs page and stay on the page during some time - few minutes -, the buttons are not working anymore without error in console) |
I just updated to the latest edge, and I'm no longer able to reproduce this. When switching log sources, all of the log lines are replaced as expected, rather than getting some from one source and some from another. |
requestAnimationFrameerror-level notification was received, as well as if an instance requires restarting (e.g. to apply settings)bridge/request,/get&/set)/get&/seterrors are parsed to only show the actual error in the toast (full message available in notifications drawer & Logs page)edgeversion based on lastmainbranch commit.Important
BREAKING:
#/device/0xbc33acfffe17628bis now#/device/0/0xbc33acfffe17628bwith the extra path used for API source indexing (as[0-9]+, always0in single-API use)Pinging some multi-instances users if I can get some in-depth testing on this and feedback on the design 😉
@thk-socal @ams2990 @KoalaWerewolf @thargy
What to lookout for when testing this?