Default permissions on public-directories giving white screen

Attempted Debugging

[X] I have read the debugging page

Searched GitHub Issues

[X] I have searched GitHub for the issue.

Describe the Scenario
I had a todo upgrading BookStack from v23.01.1 to v23.08.3. While doing so I had to solve some issues regarding composer and PHP version, when that was in place everything seemed to go well.
When all routines was done and I was ready to check the application, I was met with a white screen. I checked the logs for php-fpm and got this error message:
Details

#21 {main}
  thrown in /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php on line 190
[20-Sep-2023 13:09:01 Europe/Oslo] PHP Fatal error:  Uncaught ErrorException: file_put_contents(/var/www/BookStack/storage/framework/views/a626fbe2b5a63439d8e640abb3660a32dcbc7bc0.php): Failed to open stream: Permission denied in /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php:190
Stack trace:
#0 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(270): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError()
#1 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->Illuminate\Foundation\Bootstrap\{closure}()
#2 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php(190): file_put_contents()
#3 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/Compilers/BladeCompiler.php(185): Illuminate\Filesystem\Filesystem->put()
#4 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/Engines/CompilerEngine.php(62): Illuminate\View\Compilers\BladeCompiler->compile()
#5 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/View.php(195): Illuminate\View\Engines\CompilerEngine->get()
#6 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/View.php(178): Illuminate\View\View->getContents()
#7 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/View.php(147): Illuminate\View\View->renderContents()
#8 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Http/Response.php(69): Illuminate\View\View->render()
#9 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Http/Response.php(35): Illuminate\Http\Response->setContent()
#10 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Routing/ResponseFactory.php(57): Illuminate\Http\Response->__construct()
#11 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Routing/ResponseFactory.php(87): Illuminate\Routing\ResponseFactory->make()
#12 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(626): Illuminate\Routing\ResponseFactory->view()
#13 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(554): Illuminate\Foundation\Exceptions\Handler->renderHttpException()
#14 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(460): Illuminate\Foundation\Exceptions\Handler->prepareResponse()
#15 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(377): Illuminate\Foundation\Exceptions\Handler->renderExceptionResponse()
#16 /var/www/BookStack/app/Exceptions/Handler.php(66): Illuminate\Foundation\Exceptions\Handler->render()
#17 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(233): BookStack\Exceptions\Handler->render()
#18 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(210): Illuminate\Foundation\Bootstrap\HandleExceptions->renderHttpResponse()
#19 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(246): Illuminate\Foundation\Bootstrap\HandleExceptions->handleException()
#20 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(270): Illuminate\Foundation\Bootstrap\HandleExceptions->handleShutdown()
#21 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->Illuminate\Foundation\Bootstrap\{closure}()

On line 3 laravel is complaining about permissions, so I followed this routine -> filesystem-permissions
After doing so, nothing happened. I search on similar error messages where people said to clear cache both in browser and application.
I ended up clearing my browser cache and doing the following commands,
php artisan cache:clear
php artisan config:clear
php artisan view:clear

Still, I had a white screen viewing nothing. Then I did what all sysadmins are tought NOT to do, and that is to give 777 to publicly faced directories.
Then, everything worked!
BUT, I'm not happy having storage, bootstrap/cache and public/uploads with permissions set to 777.
My question now is, is this intentional? Or have I done something wrong along the upgrade?
What I did:

Snapshot of server
Updating all packages and rebooting server
Uninstalling php 7.4 and resetting PHP
Installing php 8.2 from :remi repo
Cloning a new version of BookStack, copying over .env.
Giving all directories permissions regarding the official docs.
Did the upgrade routine which is described here -> updates

Exact BookStack Version
v23.08.3
Log Content
Details

[20-Sep-2023 14:15:07 Europe/Oslo] PHP Fatal error:  Uncaught ErrorException: file_put_contents(/var/www/BookStack/storage/framework/views/a626fbe2b5a63439d8e640abb3660a32dcbc7bc0.php): Failed to open stream: Permission denied in /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php:190
Stack trace:
#0 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(270): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError()
#1 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->Illuminate\Foundation\Bootstrap\{closure}()
#2 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php(190): file_put_contents()
#3 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/Compilers/BladeCompiler.php(185): Illuminate\Filesystem\Filesystem->put()
#4 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/Engines/CompilerEngine.php(62): Illuminate\View\Compilers\BladeCompiler->compile()
#5 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/View.php(195): Illuminate\View\Engines\CompilerEngine->get()
#6 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/View.php(178): Illuminate\View\View->getContents()
#7 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/View/View.php(147): Illuminate\View\View->renderContents()
#8 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Http/Response.php(69): Illuminate\View\View->render()
#9 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Http/Response.php(35): Illuminate\Http\Response->setContent()
#10 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Routing/ResponseFactory.php(57): Illuminate\Http\Response->__construct()
#11 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Routing/ResponseFactory.php(87): Illuminate\Routing\ResponseFactory->make()
#12 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(626): Illuminate\Routing\ResponseFactory->view()
#13 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(554): Illuminate\Foundation\Exceptions\Handler->renderHttpException()
#14 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(460): Illuminate\Foundation\Exceptions\Handler->prepareResponse()
#15 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(377): Illuminate\Foundation\Exceptions\Handler->renderExceptionResponse()
#16 /var/www/BookStack/app/Exceptions/Handler.php(66): Illuminate\Foundation\Exceptions\Handler->render()
#17 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(233): BookStack\Exceptions\Handler->render()
#18 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(210): Illuminate\Foundation\Bootstrap\HandleExceptions->renderHttpResponse()
#19 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(246): Illuminate\Foundation\Bootstrap\HandleExceptions->handleException()
#20 /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(270): Illuminate\Foundation\Bootstrap\HandleExceptions->handleShutdown()
#21 [internal function]: Illuminate\Foundation\Bootstrap\HandleExceptions->Illuminate\Foundation\Bootstrap\{closure}()
#22 {main}
  thrown in /var/www/BookStack/vendor/laravel/framework/src/Illuminate/Filesystem/Filesystem.php on line 190

Hosting Environment
My Environment:
OS: Rocky Linux 8.x
Hypervisor: VMWare
PHP version: 8.2 - REMI repo
NGINX: nginx/1.14.1
Composer: 2.5.1 2022-12-22 15:33:54

so I followed this routine -> filesystem-permissions

Did you change www-data to suit your operating system?
I don't think www-data is used by RHEL based systems. You'd have to check what nginx is running as.

Yes, I'm using nginx as user and group.
My nginx.conf has nginx as system user defined. I have changed php-fpm to use nginx as user and group as well.

As you can see, my folders and files have 777. User is nginx:nginx.

If you're sure the user/group is aligned to webserver/php process owner, then the other thing it can often be on RHEL based systems is SELinux. You could try temporarily disabling SELinux to assess if that's the cause.

Hi!
SELinux is disabled on this server,
sestatus
SELinux status:                 disabled

It's not that either. What I think is weird is that the application was not responding until I set 777 on all public folders.
What's more strange is that people are not able to upload files either, some users (not all) have problems upload images to articles.

Outside of those two elements (file permissions and SELinux), I'm not sure what else it would be.
Can you upload an image then list out then ls -al that directory, to double check the user and group being used by BookStack when creating these? There could be something else involved due to the php-fpm process, rather than it just being nginx.

Hi!
I did that earlier today, and got the following output:

I'll add our folder structure as well, so you can see if anything is not correct:

The only folder that is directly affected is the 2023-09 (I did the upgrade late last week)
I checked your documentation for PHP-packages and had all required packages installed. Here is the list of installed PHP-packages,

I have also checked some parameters in php.ini. I did adjust some thresholds to upload size and execution time, despite that those settings doesn't have anything to do with permissions on folder ^^

Just as a test, do things stop working again if you set 755 permissions on that 2023-09 folder?
If not, try setting it for the whole, public/uploads folder again.
Then others, until it stops working.
I don't see why recursive nginx:nginx and 755 won't work for the required directories at this point.
One extra point, nginx would also need read+execute on all parent directories. If that's something that changed when you started setting 777, that could be the cause.

Since it's been a few weeks I'll close this off. If further insight can be provided or desired, feel free to comment and this can be re-opened if required.


ButtonBase renders differently if "href" property is present

Problem description
Browsers render <button> elements with their text vertically centered. However, <a> elements do not. Currently, the <Button> and <IconButton> components correct for this with the following styles applied to their root:
root: {
    display: 'inline-flex',
    alignItems: 'center',
    justifyContent: 'center',
}

This causes <a> elements and <button> elements to render identically, with their contents centered both horizontally and vertically. However, there are some components, like <BottomNavigation> and <Tab>, that render <ButtonBase> directly without accounting for those differences. This means they will render differently (i.e. off-center) if you add an href prop to them. I suggest moving the styles above to MuiBaseButton.root so that it will render the same no matter where it is used.
I believe this issue is related to:

https://github.com/callemall/material-ui/issues/5682
https://github.com/callemall/material-ui/issues/7235

Steps to reproduce
Snippet from https://material-ui-1dab0.firebaseapp.com/demos/tabs/ with slight modification:
<Tabs value={value} onChange={this.handleChange}>
    <Tab label="Item One" />
    <Tab label="Item Two" href="/this/renders/differently" />
    <Tab label="Item Three" />
</Tabs>

Versions

Material-UI: v1.0.0-beta.07
React: 15.6.1
Browser: All

I suggest moving the styles above to MuiBaseButton.root so that it will render the same no matter where it is used.

This sound good to me 👍


fix SystemError: <class 'str'> returned a result with an error set

This happens on my particular platform.
python 3.6.3 pandas 0.18.1
SystemError: <class 'str'> returned a result with an error set

there might cause issue with numpy.ndarray

double checked and it is not possible that the variable could be of type numpy.ndarray. This is only an issue with my pull request on empyrical

not hitting this error anymore. I guess is it a corner case in one of my previous code. anyway. I am closing this now


[critical] Revert require rename, fixes #4216

Changes introduced in #4213 and #4214 broke webpack -- #4216. Reverting them

Merged in 43a226e10dc5634bf144c8eaf91f3de39698876a


Language selection

It's great that you make your website available in multiple languages. It's less great that I appear to be stuck with a language I can't read. Please offer a language selection option, so I can go back to English. Thnx!

Yeah sorry about that. I pushed an update that included a few new
languages. It also included my brainwave of a change that sorted the
language list alphabetically. The first element is also implicitly used as
the default language (arabic in this case). Were you using Safari by any
chance?
I pushed the quick fix to correct the config. I'll include a fix for that
root cause in 0.11 (added a key that sets the default explicitly). If it's
still happening as of this comment, please let me know bc it means there's
something else to fix.
On Fri., Jul. 23, 2021, 04:33 Wouter van Dam, @.***>
wrote:

It's great that you make your website available in multiple languages.
It's less great that I appear to be stuck with a language I can't read.
Please offer a language selection option, so I can go back to English. Thnx!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/onetimesecret/onetimesecret/issues/177, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJUAVCDBKGNFSRZFXQA7O3TZFHQVANCNFSM5A32U5ZA
.

Thanks for the quick solution. It's looking good now. And I was indeed using Safari.


Function name error indication persists

tried to create a function with the same name and got the error indication, as expected. But then when i changed the text, the error indication persists

Dublicate: The new function name field validation alert won't disappear #727
Fixed in function-next


Concurrent work queues, less native async_send transitions

Process queues till complete
Remove the high contention locks
Reduce the calls to native async_send when not required (e.g. loop is currently processing).
From #519

There are basically two things we need to determine before merging this PR. Whether or not using a concurrent queue is faster than swapping normal queues inside a lock when consuming and always locking when adding.
I think we should separately measure the impact of tracking _loopIdle in managed code to reduce native calls to async_send.

Both faster, but I won't be offended :D
The queue issue is all the writes contending on the lock rather than the swapping; which is probably quite efficient.
The async_send issue is the managed->native transition being expensive as it does stack prep-work; e.g. for Buffer.BlockCopy just calling its native counterpart (https://github.com/dotnet/coreclr/issues/2430#issuecomment-166594959)

There doesn't appear be any transition cost but Buffer::BlockCopy's function prolog takes 11.3%. Not surprising considering that it stores 7 registers to stack - that's 56 bytes of stores in a function that's supposed to copy, say, 16 bytes.

Also validation on the Safehandles, the return values and the jit not being able to optimize the native call to anything better, inline it etc.

i.e. on the swapping if it was a single writer and single reader; rather than many writers and one reader then the swap would probably be better - but then the lock would also only need to exist on the swap; not on add

dev:
Running 10s test @ http://<IP_ADDRESS>:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.73ms    5.44ms 239.17ms   94.31%
    Req/Sec    36.83k     1.86k   59.48k    85.32%
  11813916 requests in 10.10s, 1.45GB read
Requests/sec: 1169764.49
Transfer/sec:    147.26MB

Running 10s test @ http://<IP_ADDRESS>:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.79ms    6.16ms 290.01ms   96.14%
    Req/Sec    36.91k     2.87k   73.88k    95.12%
  11820562 requests in 10.10s, 1.45GB read
Requests/sec: 1170379.09
Transfer/sec:    147.33MB

Running 10s test @ http://<IP_ADDRESS>:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.53ms    4.48ms 274.42ms   96.42%
    Req/Sec    36.90k     1.74k   61.62k    85.45%
  11844142 requests in 10.10s, 1.46GB read
Requests/sec: 1172712.52
Transfer/sec:    147.63MB

benaadams/work-queue-merged:
Running 10s test @ http://<IP_ADDRESS>:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.39ms    3.16ms  76.18ms   94.44%
    Req/Sec    37.03k     2.65k   78.47k    95.15%
  11860835 requests in 10.10s, 1.46GB read
Requests/sec: 1174346.96
Transfer/sec:    147.83MB

Running 10s test @ http://<IP_ADDRESS>:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.30ms    2.64ms 234.58ms   93.71%
    Req/Sec    37.06k     2.87k   76.10k    95.96%
  11864330 requests in 10.10s, 1.46GB read
Requests/sec: 1174694.86
Transfer/sec:    147.88MB

Running 10s test @ http://<IP_ADDRESS>:5001/plaintext
  32 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.70ms    6.36ms 154.95ms   95.57%
    Req/Sec    37.04k     3.55k   97.62k    96.54%
  11843404 requests in 10.10s, 1.46GB read
Requests/sec: 1172695.07
Transfer/sec:    147.62MB

The removed locks do seem ever-so-slightly faster, and I personally don't see any race condition in this PR. Still, when I forwarded this PR out to @GrabYourPitchforks (best writer of lock-free code I know) to verify the correctness, his first response is it really worth removing the locks which make this obviously correct. I'm inclined to agree. The locks make me much more warm and fuzzy inside since it's easier for me to reason about than access to a volatile variable.

Was this a comparison of current dev (faster); to branch (older)?
Regardless, this would probably be an unsensible time to merge it*
*As I imagine people will freeze to the RTM in production so as you and @davidfowl had mentioned previously; stability and security (or fixes for bad perf; rather than to make great perf better :grin: )

No. I merged this change into dev and then ran the test.
I'm glad you agree. Like I said, I think this change is good, but I don't want any uncertainty.


suggestion: remove sun/moon and horizon?

way to remove sun and moon and horizon, fog effects vanish at night and during this times.

Should be easy enough to add.
Thank you for the suggestion.
Sorry about replying so late.


Fibaro Door/Window Sensor FGK-10x

Hello,
I have a Problem with the Fiabro Door/Window Sensor:
I included it in ZWay and it appears as a set of different devices like Alarm, temperatures, etc.
The Problem is, that homebridge only recognizes the temperature device (I installed a DS18B20 to the sensor to report the temperature) and a "General Purpose Alarm" which is show as a window sensor in HomeKit but does only reflect the Tamper Sensor and not the reed contact of the sensor.
The status of the Window (reed sensor) is reported in an alarm device (in my case with ID ZWayVDev_zway_13-0-113-6-Door-A), which is not shown in HomeKit.
I tried some combination of homebridge tags to make it visible in HomeKit like "Homebridge.IsPrimary", "Homebridge.Service.Type:value" and also "Homebridge.Characteristic.Type:value" with different values (SensorBinary, Window, Door, ...).
As a result of these tags, the temperature sensor disappears (I guess because I made an other device primary) and an "unsupported Device" appears in HomeKit with no functionality.
So my question: How do I get the Window Sensor working with homebridge? I want to see both, the temperature and the status of the window.
Thanks in advance for your support!

Hi, can I see the section of your devices.json that defines this device?

Of course, here you go:
{"data":{"structureChanged":true,"updateTime":1480500425,"devices":[{"creationTime":1479335991,"creatorId":13,"deviceType":"switchBinary","h":2095255578,"hasHistory":false,"id":"HTTP_Device_switchBinary_13","location":0,"metrics":{"icon":"switch","title":"HTTP: Tado Off / Auto","level":"off"},"permanently_hidden":false,"probeType":"","tags":["Homebridge.Skip"],"visibility":true,"updateTime":1480462200},{"creationTime":1478968141,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery digest 7","level":66},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477058743,"creatorId":1,"deviceType":"sensorMultilevel","h":1303304277,"hasHistory":false,"id":"ZWayVDev_zway_2-0-50-0","location":4,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":3.73,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>) Küche"},"permanently_hidden":false,"probeType":"meterElectric_kilowatt_hour","tags":[],"visibility":true,"updateTime":1480500000},{"creationTime":1477058743,"creatorId":1,"deviceType":"sensorMultilevel","h":1303304279,"hasHistory":false,"id":"ZWayVDev_zway_2-0-50-2","location":4,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Leistung Licht Küche Wand/Reagl"},"permanently_hidden":false,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1480500001},{"creationTime":1478962149,"creatorId":1,"deviceType":"sensorBinary","h":-1997775972,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-4-2-A","location":4,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478962149,"creatorId":1,"deviceType":"sensorBinary","h":-1994078044,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-8-6-A","location":4,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Power Management Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478962149,"creatorId":1,"deviceType":"switchBinary","h":1078449915,"hasHistory":false,"id":"ZWayVDev_zway_2-0-37","location":4,"metrics":{"icon":"switch","title":"Licht Küche 2.0","level":"off"},"permanently_hidden":true,"probeType":"","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478962151,"creatorId":1,"deviceType":"switchBinary","h":1078479706,"hasHistory":false,"id":"ZWayVDev_zway_2-1-37","location":4,"metrics":{"icon":"switch","title":"Licht Küche","level":"off"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480489999},{"creationTime":1478962152,"creatorId":1,"deviceType":"switchBinary","h":1078509497,"hasHistory":false,"id":"ZWayVDev_zway_2-2-37","location":4,"metrics":{"icon":"switch","title":"Licht Küche Decke","level":"off"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480467082},{"creationTime":1477058986,"creatorId":1,"deviceType":"sensorMultilevel","h":-1248873822,"hasHistory":false,"id":"ZWayVDev_zway_3-0-49-4","location":1,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Fibar Group Power (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"energy","tags":[],"visibility":true,"updateTime":1480500001},{"creationTime":1477058989,"creatorId":1,"deviceType":"sensorMultilevel","h":-1248852684,"hasHistory":false,"id":"ZWayVDev_zway_3-0-50-0","location":1,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":2.01,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"meterElectric_kilowatt_hour","tags":[],"visibility":true,"updateTime":1480499401},{"creationTime":1477058989,"creatorId":1,"deviceType":"sensorMultilevel","h":-1248852682,"hasHistory":false,"id":"ZWayVDev_zway_3-0-50-2","location":1,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1480500002},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2003788317,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-4-2-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2007484323,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-8-4-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.4)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2007485284,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-8-5-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.5)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2007486245,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-8-6-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2007488167,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-8-8-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.8)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2007489128,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-8-9-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.9)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477059632,"creatorId":1,"deviceType":"sensorBinary","h":2008404961,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-9-1-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group System Alarm (<IP_ADDRESS>.1)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477058989,"creatorId":1,"deviceType":"switchMultilevel","h":1107079067,"hasHistory":false,"id":"ZWayVDev_zway_3-0-38","location":1,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (3.0)","level":0},"permanently_hidden":true,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477058991,"creatorId":1,"deviceType":"switchMultilevel","h":1107108858,"hasHistory":false,"id":"ZWayVDev_zway_3-1-38","location":1,"metrics":{"icon":"multilevel","title":"Licht Wohnzimmer","level":0},"permanently_hidden":false,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480467100},{"creationTime":1477059044,"creatorId":1,"deviceType":"sensorMultilevel","h":-1220244671,"hasHistory":false,"id":"ZWayVDev_zway_3-1-49-4","location":1,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Leistung Dimmer Deckenlicht WZ"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1480499404},{"creationTime":1477058993,"creatorId":1,"deviceType":"switchMultilevel","h":1107138649,"hasHistory":false,"id":"ZWayVDev_zway_3-2-38","location":1,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (3.2)","level":0},"permanently_hidden":true,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123416,"creatorId":1,"deviceType":"sensorMultilevel","h":493936513,"hasHistory":false,"id":"ZWayVDev_zway_4-0-49-4","location":3,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Leistung Dimmer Schlafzimmer"},"permanently_hidden":true,"probeType":"energy","tags":[],"visibility":true,"updateTime":1480499401},{"creationTime":1477123421,"creatorId":1,"deviceType":"sensorMultilevel","h":493957651,"hasHistory":false,"id":"ZWayVDev_zway_4-0-50-0","location":3,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":0.83,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"meterElectric_kilowatt_hour","tags":[],"visibility":true,"updateTime":1480500001},{"creationTime":1477123421,"creatorId":1,"deviceType":"sensorMultilevel","h":493957653,"hasHistory":false,"id":"ZWayVDev_zway_4-0-50-2","location":3,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Leistung Dimmer"},"permanently_hidden":true,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1480498801},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1710385310,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-4-2-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1714081316,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-8-4-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.4)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1714082277,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-8-5-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.5)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1714083238,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-8-6-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1714085160,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-8-8-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.8)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1714086121,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-8-9-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.9)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123423,"creatorId":1,"deviceType":"sensorBinary","h":1715001954,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-9-1-A","location":3,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group System Alarm (<IP_ADDRESS>.1)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123434,"creatorId":1,"deviceType":"switchMultilevel","h":1135708218,"hasHistory":false,"id":"ZWayVDev_zway_4-0-38","location":3,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (4.0)","level":0},"permanently_hidden":true,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477123430,"creatorId":1,"deviceType":"switchMultilevel","h":1135738009,"hasHistory":false,"id":"ZWayVDev_zway_4-1-38","location":3,"metrics":{"icon":"multilevel","title":"Licht Schlafzimmer","level":0},"permanently_hidden":false,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480490145},{"creationTime":1478165020,"creatorId":1,"deviceType":"sensorMultilevel","h":522565664,"hasHistory":false,"id":"ZWayVDev_zway_4-1-49-4","location":3,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Leistung Dimmer Schlafzimmer"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1480497442},{"creationTime":1477123450,"creatorId":1,"deviceType":"switchMultilevel","h":1135767800,"hasHistory":false,"id":"ZWayVDev_zway_4-2-38","location":3,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (4.2)","level":0},"permanently_hidden":true,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477239825,"creatorId":1,"deviceType":"switchBinary","h":1164337368,"hasHistory":false,"id":"ZWayVDev_zway_5-0-37","location":2,"metrics":{"icon":"switch","title":"Fibar Group Switch (5.0)","level":"off"},"permanently_hidden":true,"probeType":"","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478967085,"creatorId":1,"deviceType":"sensorMultilevel","h":-2058199310,"hasHistory":false,"id":"ZWayVDev_zway_5-0-50-0","location":2,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":0,"icon":"meter","title":"Fibaro Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":false,"probeType":"meterElectric_kilowatt_hour","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478967085,"creatorId":1,"deviceType":"sensorMultilevel","h":-2058199308,"hasHistory":false,"id":"ZWayVDev_zway_5-0-50-2","location":2,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Leistung Licht Esstisch"},"permanently_hidden":false,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478967085,"creatorId":1,"deviceType":"sensorBinary","h":1416982303,"hasHistory":false,"id":"ZWayVDev_zway_5-0-113-4-2-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":true,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1478967085,"creatorId":1,"deviceType":"sensorBinary","h":1420680231,"hasHistory":false,"id":"ZWayVDev_zway_5-0-113-8-6-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Power Management Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":true,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477239826,"creatorId":1,"deviceType":"switchBinary","h":1164367159,"hasHistory":false,"id":"ZWayVDev_zway_5-1-37","location":2,"metrics":{"icon":"switch","title":"Licht Esstisch","level":"off"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480467076},{"creationTime":1477239826,"creatorId":1,"deviceType":"switchBinary","h":1164396950,"hasHistory":false,"id":"ZWayVDev_zway_5-2-37","location":2,"metrics":{"icon":"switch","title":"Wandlampen","level":"off"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480467076},{"creationTime":1477317806,"creatorId":1,"deviceType":"switchMultilevel","h":1192966520,"hasHistory":false,"id":"ZWayVDev_zway_6-0-38","location":2,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (6.0)","level":0},"permanently_hidden":true,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477317802,"creatorId":1,"deviceType":"sensorMultilevel","h":-315410113,"hasHistory":false,"id":"ZWayVDev_zway_6-0-49-4","location":2,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Fibar Group Power (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"energy","tags":[],"visibility":true,"updateTime":1480461222},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorMultilevel","h":-315388975,"hasHistory":false,"id":"ZWayVDev_zway_6-0-50-0","location":2,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":1.96,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"meterElectric_kilowatt_hour","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorMultilevel","h":-315388973,"hasHistory":false,"id":"ZWayVDev_zway_6-0-50-2","location":2,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1123579296,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-4-2-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1127275302,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-8-4-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.4)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1127276263,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-8-5-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.5)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1127277224,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-8-6-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1127279146,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-8-8-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.8)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1127280107,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-8-9-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.9)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317805,"creatorId":1,"deviceType":"sensorBinary","h":1128195940,"hasHistory":false,"id":"ZWayVDev_zway_6-0-113-9-1-A","location":2,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group System Alarm (<IP_ADDRESS>.1)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317808,"creatorId":1,"deviceType":"switchMultilevel","h":1192996311,"hasHistory":false,"id":"ZWayVDev_zway_6-1-38","location":2,"metrics":{"icon":"multilevel","title":"Licht Esszimmer","level":0},"permanently_hidden":false,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480467076},{"creationTime":1477317945,"creatorId":1,"deviceType":"sensorMultilevel","h":-286780962,"hasHistory":false,"id":"ZWayVDev_zway_6-1-49-4","location":2,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Leistung Dimmer Esszimmer"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1477317809,"creatorId":1,"deviceType":"switchMultilevel","h":1193026102,"hasHistory":false,"id":"ZWayVDev_zway_6-2-38","location":2,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (6.2)","level":0},"permanently_hidden":true,"probeType":"multilevel","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323824,"creatorId":1,"deviceType":"sensorBinary","h":-1456740559,"hasHistory":false,"id":"ZWayVDev_zway_13-0-48-1","location":5,"metrics":{"probeTitle":"General purpose","scaleTitle":"","icon":"motion","level":"off","title":"Fibaro General purpose (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1480500000},{"creationTime":1479323823,"creatorId":1,"deviceType":"sensorMultilevel","h":-1456739598,"hasHistory":false,"id":"ZWayVDev_zway_13-0-49-1","location":5,"metrics":{"probeTitle":"Temperature","scaleTitle":"°C","level":17.1200016,"icon":"temperature","title":"Temperatur Bad"},"permanently_hidden":false,"probeType":"temperature","tags":[],"visibility":true,"updateTime":1480499399},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2108136022,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-4-2-A","location":5,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":true,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2108132178,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-4-6-A","location":5,"metrics":{"icon":"alarm","level":"off","title":"Fibaro Heat Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":true,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":1594949884,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-6-Door-A","location":5,"metrics":{"icon":"door","level":"off","title":"Fenster Bad"},"permanently_hidden":false,"probeType":"alarm_door","tags":["Homebridge.Characteristic.Type:sensorBinary"],"visibility":true,"updateTime":1480462200},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2105364498,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-7-3-A","location":5,"metrics":{"icon":"smoke","level":"on","title":"Fibaro Burglar Alarm (<IP_ADDRESS>.3)"},"permanently_hidden":true,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1480462200},{"creationTime":1479323835,"creatorId":1,"deviceType":"sensorBinary","h":-2103519378,"hasHistory":false,"id":"ZWayVDev_zway_13-0-113-9-1-A","location":5,"metrics":{"icon":"alarm","level":"off","title":"Fibaro System Alarm (<IP_ADDRESS>.1)"},"permanently_hidden":true,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323823,"creatorId":1,"deviceType":"battery","h":507194638,"hasHistory":false,"id":"ZWayVDev_zway_13-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":66,"icon":"battery","title":"Fibaro Battery (13.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1480461223},{"creationTime":1479323842,"creatorId":1,"deviceType":"sensorBinary","h":146374528,"hasHistory":false,"id":"ZWayVDev_zway_13-0-156-0-A","location":5,"metrics":{"icon":"alarm","level":"on","title":"Fibaro General Purpose alarm Alarm (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1480498020},{"creationTime":1478964001,"creatorId":1,"deviceType":"sensorBinary","h":-12100485,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-4-254-A","location":4,"metrics":{"icon":"alarm","level":"on","title":"Fibaro Heat Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480498800},{"creationTime":1478964001,"creatorId":1,"deviceType":"sensorBinary","h":-757053057,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-8-254-A","location":4,"metrics":{"icon":"alarm","level":"on","title":"Fibaro Power Management Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1480500005},{"creationTime":1477059600,"creatorId":1,"deviceType":"sensorBinary","h":1495451324,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-4-254-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480500002},{"creationTime":1477059601,"creatorId":1,"deviceType":"sensorBinary","h":750498752,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-8-254-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480500002},{"creationTime":1477059601,"creatorId":1,"deviceType":"sensorBinary","h":1638002433,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-9-254-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group System Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480500003},{"creationTime":1477127403,"creatorId":1,"deviceType":"sensorBinary","h":-1291964163,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-4-254-A","location":3,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480500003},{"creationTime":1477127403,"creatorId":1,"deviceType":"sensorBinary","h":-2036916735,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-8-254-A","location":3,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480500004},{"creationTime":1477127403,"creatorId":1,"deviceType":"sensorBinary","h":-1149413054,"hasHistory":false,"id":"ZWayVDev_zway_4-0-113-9-254-A","location":3,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group System Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1480500004}]},"code":200,"message":"200 OK","error":null}

Any idea??

I have the same problem but this sensor is the only one, I'm working with at the moment.
When starting home bridge manually, I get an error immediately after the scan-code is shown:
events.js:160
throw er; // Unhandled 'error' event
^
Error: listen EADDRINUSE :::51826
at Object.exports._errnoException (util.js:1022:11)
at exports._exceptionWithHostPort (util.js:1045:20)
at Server._listen2 (net.js:1262:14)
at listen (net.js:1298:10)
at Server.listen (net.js:1376:9)
at EventedHTTPServer.listen (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/util/eventedhttp.js:60:19)
at HAPServer.listen (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/HAPServer.js:158:20)
at Bridge.Accessory.publish (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/lib/Accessory.js:496:16)
at Server._publish (/usr/lib/node_modules/homebridge/lib/server.js:114:16)
at Server. (/usr/lib/node_modules/homebridge/lib/server.js:372:14)
This is the devices file:
{"data":{"structureChanged":true,"updateTime":1482939725,"devices":[{"creationTime":1482937461,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear Expert User","text":"If you still want to use ExpertUI please go, after you are successfully logged in, to  Menu > Devices > Manage with ExpertUI   or call  http://MYRASP:8083/expert  in your browser.  You could hide or remove this widget in menu Apps > Active Tab. ","icon":"app/img/logo-z-wave-z-only.png"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1482937461},{"creationTime":1482932339,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery digest 7","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933380,"creatorId":1,"deviceType":"sensorBinary","h":-1248874786,"hasHistory":false,"id":"ZWayVDev_zway_3-0-48-1","location":1,"metrics":{"probeTitle":"General purpose","scaleTitle":"","icon":"motion","level":"on","title":"Fibaro General purpose (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933389,"creatorId":1,"deviceType":"sensorBinary","h":-1124283479,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-6-Door-A","location":0,"metrics":{"icon":"door","level":"on","title":"SchlafzimmerFenster"},"permanently_hidden":false,"probeType":"alarm_door","tags":["Homebridge.Service.Type:ContactSensor"],"visibility":true,"updateTime":1482937462},{"creationTime":1482933389,"creatorId":1,"deviceType":"sensorBinary","h":2006559841,"hasHistory":false,"id":"ZWayVDev_zway_3-0-113-7-3-A","location":1,"metrics":{"icon":"smoke","level":"off","title":"Fibaro Burglar Alarm (<IP_ADDRESS>.3)"},"permanently_hidden":true,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933379,"creatorId":1,"deviceType":"battery","h":-40289343,"hasHistory":false,"id":"ZWayVDev_zway_3-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":100,"icon":"battery","title":"Fibaro Battery (3.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1482937462},{"creationTime":1482933394,"creatorId":1,"deviceType":"sensorBinary","h":-667222861,"hasHistory":false,"id":"ZWayVDev_zway_3-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibaro General Purpose alarm Alarm (<IP_ADDRESS>)"},"permanently_hidden":true,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1482937462}]},"code":200,"message":"200 OK","error":null}
I cannot retrieve accessories....
Any idea?

@WolfgangDomroese In your case it seems you have another instance of Homebridge running already, which is using the port it expects to run on:
Error: listen EADDRINUSE :::51826
Try ps -ef | grep homebridge and see if you have another process running that you don't expect. If so, kill that process and try again.

@TS-Tec Back to your original issue, it seems that that sensor is no longer reporting itself as door-window, but is now only reporting itself as several different alarm_* types :-/. Unsure if this is due to a firmware update on the device or a Z-Way server version update--they changed a bunch of probeTypes in the latest version 😠  (can you tell me your version of Z-Way Server?).
I'll have to work in a fix, but this is a little tricky...many other devices publish those alarm types and they mean something slightly different, usually (you can turn on/off triggering of the alarm channel)...so I don't want a change to interfere with the way other devices work.

@WolfgangDomroese Try running homebridge in Debug mode, with one of the following methods:
homebridge -D
DEBUG=* homebridge
DEBUG=ZWayServer homebridge

See the Homebridge project's page for more info. If you see something amiss, probably open a new issue at this point, we're mixing things up with the original bug now.

I can confirm that this behavior still exists on my side too. Running newest versions of z-way, Homebridge and Homebridge-zway etc.
certain contact sensors do not show up anymore, while some still do. Really strange.

I opened a new issue with the complete debug-message. The part regarding
ZWayServer is here:
ZWayServer Authenticating... +256ms
ZWayServer Authenticated. Resubmitting original request... +69ms
ZWayServer Device ZWayVDev_zway_3-0-48-1 skipped!  +50ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +1ms
ZWayServer Device ZWayVDev_zway_3-0-113-7-3-A skipped!  +5ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +0ms
ZWayServer Device ZWayVDev_zway_3-0-156-0-A skipped!  +1ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +1ms
ZWayServer Got grouped device BatteryPolling_7 consisting of devices:
+1ms
ZWayServer BatteryPolling_7 - battery.Battery +5ms
ZWayServer WARN: Didn't find suitable device class! +0ms
ZWayServer Got grouped device InfoWidget_5_Int consisting of devices:
+0ms
ZWayServer InfoWidget_5_Int - text +0ms
ZWayServer WARN: Didn't find suitable device class! +1ms
ZWayServer Got grouped device ZWayVDev_3-0 consisting of devices: +0ms
ZWayServer ZWayVDev_zway_3-0-113-6-Door-A - sensorBinary +0ms
ZWayServer ZWayVDev_zway_3-0-128 - battery.Battery +0ms
ZWayServer WARN: Didn't find suitable device class! +0ms
Am 03.01.17 um 07:10 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Try running
homebridge in Debug mode, with one of the following methods:
|homebridge -D DEBUG=* homebridge DEBUG=ZWayServer homebridge |
See the Homebridge project's page for more info. If you see something
amiss, probably open a new issue at this point, we're mixing things up
with the original bug now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-270056493,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiMpadvvc7GfKLX-85i6atChGHazQks5rOeY_gaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

@SphtKr
same behaviour on 2.2.4 and 2.2.5
Thanks for your support!

Can somebody try the diff in the above commit fc5ffeb ? That may do the trick.
Also, @TS-Tec I noticed that you had tagged your sensor with Homebridge.Characteristic.Type:sensorBinary , but that's not right, you probably mean Homebridge.Characteristic.Type:ContactSensor, or Homebridge.Characteristic.Type:Door.

Sorry, I'm out of home. I could change the file but as the pi is now in
another place, obviously apples home-kit does not work at all. And I do
not know, how to reset.....
So, we have to wait until Friday afternoon CET.
Am 05.01.17 um 07:40 schrieb SphtKr:

Can somebody try the diff in the above commit fc5ffeb
https://github.com/SphtKr/homebridge-zway/commit/fc5ffeb12bdbdaf785ed906caa72720f504ba556
? That may do the trick.
Also, @TS-Tec https://github.com/TS-Tec I noticed that you had
tagged your sensor with |Homebridge.Characteristic.Type:sensorBinary|
, but that's not right, you probably mean
|Homebridge.Characteristic.Type:ContactSensor|, or
|Homebridge.Characteristic.Type:Door|.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-270575112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiHPjAx4q-cVXZqqRmChSMGYf1uP4ks5rPJBNgaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

Hold on, not quite, also requires 2f7f54d . But I'm pretty sure that fixes it.

I think this is now fixed in 0.5.0-rc1, everyone update to that version (and restart Homebridge) and see if it solves your issues.
I was able to test this by Homebridge.Skipping the regular door-window device on one of my Devolo door sensors which left only the alarm_door sensor like the Fibaros have, and it seems to be working.

Sorry - I still do not get it. Here is the DEBUG output. There is still
a Warning....
There are two sensors included, but one is not working (absent).
pi@pi_1_zwave:~ $ DEBUG=ZWayServer homebridge
*** WARNING *** The program 'nodejs' uses the Apple Bonjour
compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see
http://0pointer.de/avahi-compat?s=libdns_sd&e=nodejs
*** WARNING *** The program 'nodejs' called 'DNSServiceRegister()' which
is not supported (or only supported partially) in the Apple Bonjour
compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see
http://0pointer.de/avahi-compat?s=libdns_sd&e=nodejs&f=DNSServiceRegister
[2017-01-06 19:49:18] Loaded plugin: homebridge-contactsensor
[2017-01-06 19:49:18] Registering accessory
'homebridge-contactsensor.ContactSensor'
[2017-01-06 19:49:18] ---
[2017-01-06 19:49:19] Loaded plugin: homebridge-zway
[2017-01-06 19:49:19] Registering accessory 'homebridge-zway.ZWayServer'
[2017-01-06 19:49:19] Registering platform 'homebridge-zway.ZWayServer'
[2017-01-06 19:49:19] ---
[2017-01-06 19:49:19] Loaded config.json with 1 accessories and 1 platforms.
[2017-01-06 19:49:19] ---
[2017-01-06 19:49:19] Loading 1 platforms...
[2017-01-06 19:49:19] Initializing ZWayServer platform...
ZWayServer Fetching Z-Way devices... +0ms
[2017-01-06 19:49:19] Loading 1 accessories...
[2017-01-06 19:49:19] [DummySensor] Initializing ContactSensor accessory...
contact sensors { '22':
Service {
displayName: 'Dummy 1',
UUID: '00000080-0000-1000-8000-0026BB765291',
subtype: 'Dummy 1',
iid: null,
characteristics: [ [Object], [Object] ],
optionalCharacteristics: [ [Object], [Object], [Object], [Object],
[Object] ] },
'24':
Service {
displayName: 'Dummy 2',
UUID: '00000080-0000-1000-8000-0026BB765291',
subtype: 'Dummy 2',
iid: null,
characteristics: [ [Object], [Object] ],
optionalCharacteristics: [ [Object], [Object], [Object], [Object],
[Object] ] } }
ZWayServer Authenticating... +246ms
ZWayServer Authenticated. Resubmitting original request... +71ms
ZWayServer Device ZWayVDev_zway_3-0-48-1 skipped!  +54ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +1ms
ZWayServer Device ZWayVDev_zway_3-0-113-7-3-A skipped!  +5ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +0ms
ZWayServer Device ZWayVDev_zway_3-0-156-0-A skipped!  +2ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +0ms
ZWayServer Device ZWayVDev_zway_4-0-48-1 skipped!  +1ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +6ms
ZWayServer Device ZWayVDev_zway_4-0-113-7-3-A skipped!  +2ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +0ms
ZWayServer Device ZWayVDev_zway_4-0-156-0-A skipped!  +2ms
ZWayServer { permanently_hidden: true,
ZWayServer   Skip: false,
ZWayServer   Include: false,
ZWayServer   opt_in: undefined } +0ms
ZWayServer Got grouped device InfoWidget_5_Int consisting of devices:
+2ms
ZWayServer InfoWidget_5_Int - text +0ms
ZWayServer WARN: Didn't find suitable device class! +1ms
ZWayServer Got grouped device BatteryPolling_7 consisting of devices:
+3ms
ZWayServer BatteryPolling_7 - battery.Battery +1ms
ZWayServer WARN: Didn't find suitable device class! +1ms
ZWayServer Got grouped device ZWayVDev_3-0 consisting of devices: +0ms
ZWayServer ZWayVDev_zway_3-0-113-6-Door-A - sensorBinary +0ms
ZWayServer ZWayVDev_zway_3-0-128 - battery.Battery +0ms
ZWayServer WARN: Didn't find suitable device class! +1ms
ZWayServer Got grouped device ZWayVDev_4-0 consisting of devices: +0ms
ZWayServer ZWayVDev_zway_4-0-113-6-Door-A - sensorBinary +0ms
ZWayServer ZWayVDev_zway_4-0-128 - battery.Battery +0ms
ZWayServer WARN: Didn't find suitable device class! +1ms
Scan this code with your HomeKit App on your iOS device to pair with
Homebridge:
Am 06.01.17 um 06:13 schrieb SphtKr:

I think this is now fixed in 0.5.0-rc1, everyone update to that
version (and restart Homebridge) and see if it solves your issues.
I was able to test this by |Homebridge.Skip|ping the regular
|door-window| device on one of my Devolo door sensors which left only
the |alarm_door| sensor like the Fibaros have, and it seems to be working.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-270833036,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiMpJigROsRDMk9TgeUntsLicx_Beks5rPc2PgaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

@SphtKr
Tested your commits and can say that the sensor is now handled by HomeKit but:

it is shown as a door and can not be configured as window
it offers an function to open and close (to a percent value) which leads to an "transition" state in home kit like "opening" or closing" which does not make sense for a passive sensor

Is there a chance that it could be handled like a passive door/window sensor which only shows its state without possibility to change its value in HomeKit??
But thanks for the great work until here!!
P.S.: I changed the ZWay Tag to Homebridge.Characteristic.Type:ContactSensor

@TS-Tec That line was correct, you need to instead add the tag Homebridge.Service.Type:ContactSensor or another value--see the documentation on this. I think that once you specify the Homebridge.Service.Type then you should not need to specify Homebridge.Characterisic.Type like you were doing--it should figure out the right Characteristic type.
Also be aware that those changes will always require restarting Homebridge, and may actually not reflect in your HomeKit app immediately (this is tricky, sometimes turning WiFi off/on causes an update, other times you have to wait...strictly speaking, I don't think changing Service type of an accessory is really supported in HomeKit, but it usually works eventually).
@WolfgangDomroese Hmm...that's puzzling, specifically because @TS-Tec seems to be working now. I admit I was guessing which of the four devices was actually going to be updated by default, but if it's working for him...that's odd. I have assumed that the cause of this problem in the first place was a firmware update on the Fibaro device...I wonder if you two have different firmware versions.
In any case, I don't think I've seen your devices JSON, so: could you try and capture your devices JSON data, and do it while the contact sensor is open, so I can see which device it is and which attributes it has? Thanks!

BTW: I tried to get the "General Purpose" to work as it is bridged to
homekit. But I did not succeed. Whenever I try to set hardware
configuration No 1 (operation mode) from  Door/Window to External Switch
I get an error on saving. But why the hell do I have 4 logical devices
when I get only one to work????
Looking at the device Type Info I get:
6.51.06    Fibaro     FGK-10x     3.2     Unknown device type: 7
I tried to find additional Information on Fibaro Site but I did not find
anything besides theire centarl control unit. So, I do not know if
firmware 3.2. is latest. Do you have additional sources?
The devices JSON is as follows:
Contact on Hardware open:
Showing:
Access Control on
Burglar Alarm off
General Purpose Alarm on
General Purpose on
{"data":{"structureChanged":true,"updateTime":1483863807,"devices":[{"creationTime":1483802057,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear
Expert User","text":"If you still want to use ExpertUI please
go, after you are successfully logged in, to  Menu > Devices

Manage with ExpertUI   or call
http://MYRASP:8083/expert  in your browser.  You
could hide or remove this widget in menu Apps > Active
Tab.

","icon":"app/img/logo-z-wave-z-only.png"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483811172},{"creationTime":1483802057,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery
digest
7","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802176,"creatorId":1,"deviceType":"sensorBinary","h":1303282175,"hasHistory":false,"id":"ZWayVDev_zway_2-0-48-1","location":1,"metrics":{"probeTitle":"General
purpose","scaleTitle":"","icon":"motion","level":"on","title":"Fenster_SZ"},"permanently_hidden":false,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-613749302,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-6-Door-A","location":1,"metrics":{"icon":"door","level":"on","title":"Fibaro
Access Control Alarm
(<IP_ADDRESS>.Door)"},"permanently_hidden":false,"probeType":"alarm_door","tags":[],"visibility":true,"updateTime":1483863751},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-1995004448,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-7-3-A","location":1,"metrics":{"icon":"smoke","level":"off","title":"Fibaro
Burglar Alarm
(<IP_ADDRESS>.3)"},"permanently_hidden":false,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802176,"creatorId":1,"deviceType":"battery","h":-927793024,"hasHistory":false,"id":"ZWayVDev_zway_2-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":100,"icon":"battery","title":"Fibaro
Battery
(2.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802190,"creatorId":1,"deviceType":"sensorBinary","h":1129728498,"hasHistory":false,"id":"ZWayVDev_zway_2-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibaro
General Purpose alarm Alarm
(<IP_ADDRESS>)"},"permanently_hidden":false,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1483811173}]},"code":200,"message":"200
OK","error":null}
Contact on Hardware closed:
Showing:
Access Control off
Burglar Alarm off
General Purpose Alarm on
General Purpose on
{"data":{"structureChanged":true,"updateTime":1483864071,"devices":[{"creationTime":1483802057,"creatorId":5,"deviceType":"text","h":-1261400328,"hasHistory":false,"id":"InfoWidget_5_Int","location":0,"metrics":{"title":"Dear
Expert User","text":"If you still want to use ExpertUI please
go, after you are successfully logged in, to  Menu > Devices

Manage with ExpertUI   or call
http://MYRASP:8083/expert  in your browser.  You
could hide or remove this widget in menu Apps > Active
Tab.

","icon":"app/img/logo-z-wave-z-only.png"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483811172},{"creationTime":1483802057,"creatorId":7,"deviceType":"battery","h":-592588978,"hasHistory":false,"id":"BatteryPolling_7","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery
digest
7","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802176,"creatorId":1,"deviceType":"sensorBinary","h":1303282175,"hasHistory":false,"id":"ZWayVDev_zway_2-0-48-1","location":1,"metrics":{"probeTitle":"General
purpose","scaleTitle":"","icon":"motion","level":"on","title":"Fenster_SZ"},"permanently_hidden":false,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-613749302,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-6-Door-A","location":1,"metrics":{"icon":"door","level":"off","title":"Fibaro
Access Control Alarm
(<IP_ADDRESS>.Door)"},"permanently_hidden":false,"probeType":"alarm_door","tags":[],"visibility":true,"updateTime":1483864001},{"creationTime":1483802185,"creatorId":1,"deviceType":"sensorBinary","h":-1995004448,"hasHistory":false,"id":"ZWayVDev_zway_2-0-113-7-3-A","location":1,"metrics":{"icon":"smoke","level":"off","title":"Fibaro
Burglar Alarm
(<IP_ADDRESS>.3)"},"permanently_hidden":false,"probeType":"alarm_burglar","tags":[],"visibility":true,"updateTime":1483811173},{"creationTime":1483802176,"creatorId":1,"deviceType":"battery","h":-927793024,"hasHistory":false,"id":"ZWayVDev_zway_2-0-128","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","level":100,"icon":"battery","title":"Fibaro
Battery
(2.0)"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1483830700},{"creationTime":1483802190,"creatorId":1,"deviceType":"sensorBinary","h":1129728498,"hasHistory":false,"id":"ZWayVDev_zway_2-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"on","title":"Fibaro
General Purpose alarm Alarm
(<IP_ADDRESS>)"},"permanently_hidden":false,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1483811173}]},"code":200,"message":"200
OK","error":null}
Am 08.01.17 um 05:24 schrieb SphtKr:

@TS-Tec https://github.com/TS-Tec That line was correct, you need to
instead add the tag |Homebridge.Service.Type:ContactSensor| or another
value--see the documentation on this
https://github.com/SphtKr/homebridge-zway/#doorwindow-sensor-service.
I /think/ that once you specify the |Homebridge.Service.Type| then you
should not need to specify |Homebridge.Characterisic.Type| like you
were doing--it should figure out the right Characteristic type.
Also be aware that those changes will always require restarting
Homebridge, and may actually not reflect in your HomeKit app
immediately (this is tricky, sometimes turning WiFi off/on causes an
update, other times you have to wait...strictly speaking, I don't
think changing Service type of an accessory is really supported in
HomeKit, but it usually works eventually).
@WolfgangDomroese https://github.com/WolfgangDomroese Hmm...that's
puzzling, specifically because @TS-Tec https://github.com/TS-Tec
seems to be working now. I admit I was guessing which of the four
devices was actually going to be updated by default, but if it's
working for him...that's odd. I have assumed that the cause of this
problem in the first place was a firmware update on the Fibaro
device...I wonder if you two have different firmware versions.
In any case, I don't think I've seen your devices JSON, so: could you
try and capture your devices JSON data
https://github.com/SphtKr/homebridge-zway/#getting-zautomationapiv1devices,
and do it /while the contact sensor is open/, so I can see which
device it is and which attributes it has? Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-271128957,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiOWV5Ui3tGirVSsYcXZskPT0n0gkks5rQGUagaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

@WolfgangDomroese Okay: After staring at this a bit, I think I see what's going on.
In 0.5.0-rc1 I added the alarm_door probeType as being able to create a Door/Window/ContactSensor. But, I obviously had to leave in the ability for it to bridge a general_purpose probeType device for other hardware models, and in fact those general_purpose devices is preferred. In your case--for whatever reason--your hardware is publishing both of these, and only updating the alarm_door one. I'm not sure if this is a firmware difference or device configuration difference or something else entirely, but that's what it's doing.
Fortunately, I think I know how you can fix this: Just add the tag Homebridge.Skip to the general_purpose one, that is the one titled "Fenster_SZ". After that (and restarting Homebridge) it should ignore that skipped device, only see the alarm_door one that is updating, and you should be good.
Let me know if that fixes your issue!

Thanks - but at moment, there is nothing working at all. Yesterday I
tried to get two PI with homebridge on each to work. One with
"homebridge-contactsensor" and one with zway. So, I made some changes in
config.json. Suddently zway does not show anything in iOS. I do not find
any hint in DEBUG mode. So, I did uninstall and install again of
homebridge-zway. No success. I think, I have to start with a new SD-Card
this afternoon....
Am 12.01.17 um 07:51 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Okay: After
staring at this a bit, I think I see what's going on.
In 0.5.0-rc1 I added the |alarm_door| probeType as being able to
create a Door/Window/ContactSensor. But, I obviously had to leave in
the ability for it to bridge a |general_purpose| probeType device for
other hardware models, and in fact those |general_purpose| devices is
preferred. In your case--for whatever reason--your hardware is
publishing /both/ of these, and only updating the |alarm_door| one.
I'm not sure if this is a firmware difference or device configuration
difference or something else entirely, but that's what it's doing.
Fortunately, I think I know how you can fix this: Just add the tag
|Homebridge.Skip| to the |general_purpose| one, that is the one titled
"Fenster_SZ". After that (and restarting Homebridge) it should ignore
that skipped device, only see the |alarm_door| one that is updating,
and you should be good.
Let me know if that fixes your issue!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-272090172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiCjICitKvTlpSLTb1G1Vyhh8omgtks5rRc2LgaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

It's not OK:
The general_purpose device is skipped but now no other dive is shown.
When debugging, there is no more init-process of a device....
Am 12.01.17 um 07:51 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Okay: After
staring at this a bit, I think I see what's going on.
In 0.5.0-rc1 I added the |alarm_door| probeType as being able to
create a Door/Window/ContactSensor. But, I obviously had to leave in
the ability for it to bridge a |general_purpose| probeType device for
other hardware models, and in fact those |general_purpose| devices is
preferred. In your case--for whatever reason--your hardware is
publishing /both/ of these, and only updating the |alarm_door| one.
I'm not sure if this is a firmware difference or device configuration
difference or something else entirely, but that's what it's doing.
Fortunately, I think I know how you can fix this: Just add the tag
|Homebridge.Skip| to the |general_purpose| one, that is the one titled
"Fenster_SZ". After that (and restarting Homebridge) it should ignore
that skipped device, only see the |alarm_door| one that is updating,
and you should be good.
Let me know if that fixes your issue!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-272090172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiCjICitKvTlpSLTb1G1Vyhh8omgtks5rRc2LgaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

I'm one step ahead.
After studying docs and source code and doing a little bit debugging, I
think:
The problem is to find the primaryDevice! The code looks through all
virtual devices and the first primaryDevice is schown as accessory. In
my case, "general-purpose" is the first. May be, in other firmware this
is changed.
The solution for this is simple: I set a tag "Homebridge.IsPrimary" for
the door-device. I found this in source code - but I did not see it
before in the documentation :-(
Setting a second Tag "Homebridge.Service.Type:ContactSensor" makes
(nearly) all fine. The sensor is shown perfectly in homekit - but I
still do not see any change in state. Having a look at the zwave.me
interface, the access sensor reacts perfectly. But nothing happens on iOS.
Any idea?
Am 12.01.17 um 07:51 schrieb SphtKr:

@WolfgangDomroese https://github.com/WolfgangDomroese Okay: After
staring at this a bit, I think I see what's going on.
In 0.5.0-rc1 I added the |alarm_door| probeType as being able to
create a Door/Window/ContactSensor. But, I obviously had to leave in
the ability for it to bridge a |general_purpose| probeType device for
other hardware models, and in fact those |general_purpose| devices is
preferred. In your case--for whatever reason--your hardware is
publishing /both/ of these, and only updating the |alarm_door| one.
I'm not sure if this is a firmware difference or device configuration
difference or something else entirely, but that's what it's doing.
Fortunately, I think I know how you can fix this: Just add the tag
|Homebridge.Skip| to the |general_purpose| one, that is the one titled
"Fenster_SZ". After that (and restarting Homebridge) it should ignore
that skipped device, only see the |alarm_door| one that is updating,
and you should be good.
Let me know if that fixes your issue!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SphtKr/homebridge-zway/issues/69#issuecomment-272090172,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOtuiCjICitKvTlpSLTb1G1Vyhh8omgtks5rRc2LgaJpZM4K1AF6.

--
Wolfgang Domröse
Von Eichendorff-Str. 23
37539 Bad Grund (Harz)

You said you might have to start with a new SD card...did you have to reinstall? If so are you sure you got v0.5.0-rc1?
I think you may still need the Homebridge:Skip tag. The Homebridge.IsPrimary will make that device be used to decide what kind of Service to publish, but the general_purpose device may still get picked for the Characteristic to use within the Door service.
You can tell which VDev is being used by running
DEBUG=ZWayServer homebridge

(If you're not doing that already.) In the console output, before the PIN code is shown, look for something like:
[1/2/2017, 12:08:30 PM] Initializing platform accessory 'Front Door'...
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Position" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Position State" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Target Position" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Obstruction Detected" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "Door" for vdev "ZWayVDev_zway_6-0-48-10" with typeKey "sensorBinary.Door/Window"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Battery Level" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Charging State" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Status Low Battery" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "BatteryService" for vdev "ZWayVDev_zway_6-0-128" with typeKey "battery.Battery"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-1"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Temperature" for vdev "ZWayVDev_zway_6-0-49-1"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "TemperatureSensor" for vdev "ZWayVDev_zway_6-0-49-1" with typeKey "sensorMultilevel.Temperature"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-3"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Ambient Light Level" for vdev "ZWayVDev_zway_6-0-49-3"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "LightSensor" for vdev "ZWayVDev_zway_6-0-49-3" with typeKey "sensorMultilevel.Luminiscence"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Loaded services for Front Door

You can look at which VDev identifier is used for your service, and see if that's the right or wrong one.
I will have to test this. I'm making good progress on a unit testing setup that will let me simulate some of these situations by putting your devices JSON directly through the code and seeing what happens.

Thanks. Working now!
Wolfgang Domröse
(mobile)

Am 12.01.2017 um 20:50 schrieb SphtKr<EMAIL_ADDRESS>You said you might have to start with a new SD card...did you have to reinstall? If so are you sure you got v0.5.0-rc1?
I think you may still need the Homebridge:Skip tag. The Homebridge.IsPrimary will make that device be used to decide what kind of Service to publish, but the general_purpose device may still get picked for the Characteristic to use within the Door service.
You can tell which VDev is being used by running
DEBUG=ZWayServer homebridge
(If you're not doing that already.) In the console output, before the PIN code is shown, look for something like:
[1/2/2017, 12:08:30 PM] Initializing platform accessory 'Front Door'...
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Position" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Position State" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Target Position" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Obstruction Detected" for vdev "ZWayVDev_zway_6-0-48-10"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "Door" for vdev "ZWayVDev_zway_6-0-48-10" with typeKey "sensorBinary.Door/Window"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Battery Level" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Charging State" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Status Low Battery" for vdev "ZWayVDev_zway_6-0-128"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "BatteryService" for vdev "ZWayVDev_zway_6-0-128" with typeKey "battery.Battery"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-1"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Temperature" for vdev "ZWayVDev_zway_6-0-49-1"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "TemperatureSensor" for vdev "ZWayVDev_zway_6-0-49-1" with typeKey "sensorMultilevel.Temperature"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Name" for vdev "ZWayVDev_zway_6-0-49-3"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Configured Characteristic "Current Ambient Light Level" for vdev "ZWayVDev_zway_6-0-49-3"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Found and configured Service "LightSensor" for vdev "ZWayVDev_zway_6-0-49-3" with typeKey "sensorMultilevel.Luminiscence"
Mon, 02 Jan 2017 11:08:30 GMT ZWayServer Loaded services for Front Door
You can look at which VDev identifier is used for your service, and see if that's the right or wrong one.
I will have to test this. I'm making good progress on a unit testing setup that will let me simulate some of these situations by putting your devices JSON directly through the code and seeing what happens.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@SphtKr Just recognized that commit 2f7f54d is not included in the latest release!
Therefore, it still do not work until code is manually added. After it works as before!

@TS-Tec 😕 😱 😖 😳 🤦♂ It's in the master branch properly! No idea how that happened, but you're right. Now I gotta compare and see if anything else is missing.

0.5.0-rc2 is published now which adds the missing commit and and another small fix for WindowCovering devices. I think I see now where my workflow messed up last time, should get it right from now on.


Package installs as "src" from PyPi

When I install this via pip install it puts itself in a package called src rather than mkdocs-plugin-inline-svg-mod, making it essentially anonymous and possibly conflicting with other packages.
I'm not sure how the wheel on PyPi is built but possibly the repo just needs a pyproject.toml?

Thanks. I have updated the build process. Hope this helps!


feat(clerk-js,localizations): Nav to reset-password from pass-form …

…if sign_in.needs_new_password
If password_settings.enforce_on_sign_in is true, then it will be possible for a password sign-in to succeed but require a new password that conforms to updated password requirements.
Hence, if sign_in.needs_new_password is true, the password form will navigate to reset-password.
Since we are reusing a flow initially created for resetting passwords after an oauth flow, the error message has been made more generic.
Description
See above
Checklist

[x] npm test runs as expected.
[x] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[x] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

!preview

Hey @octoper, your preview is currently deploying and should be available shortly.

Status
Preview
Updated (UTC)

:cook: Deploying...
Inspect
Mar 12, 2024 11:34 PM


Tracking some tasks for Go Agent

This issue will track some Go Agent related tasks, including:

[x] Documenting Go Agent
[ ] Documenting essential tags for OAP analyzing
[x] Update readme
[ ] agent document
[ ] Update components-libraries.yml

Notice, as Go Agent is manually instrumentation, please say that explicitly. Also, at agent setup page, you need to refer to the original repo and your go document

Go agent has been working well.


How can I force the row to update?

After editted in a popup window, the data in the grid did not update, how can I force it to update?

// updated should include the primaryKey to let grid know which row should be patched.
gridView.trigger('didEdit', updated);

Check the document:
https://microsoft.github.io/projection-grid/GridView.html#refresh__anchor
gridView.refresh(true);


Flutter run fails when an activity-alias is used in the Android manifest

Explanation
When using an <activity-alias> in the AndroidManifest.xml the command futter run is unable to build the app (I guess because it cannot find the activity in the manifest).
<activity-alias> in the AndroidManifest.xml is for example typically used in the case of an app-update where the name of the launcher activity (e.g. MainActivity) has changed (e.g. NewMainActivity). It seems that flutter run cannot handle this and fails to build/run the app.
More info on the activity-alias tag in the AndroidManifest can be found here
Sample project:
See https://github.com/PieterAelse/flutter_android_activity_alias_issue .
And specifically this commit where the activity-alias changes are highlighted.
Steps to Reproduce

Create a new flutter project using flutter create
Try flutter run with an Android device attached/emulated, it will succeed.
Add an <activity-alias> for the used Activity and remove the <intent-filter> used as launcher for the Activity itself (otherwise you'll see 2 launcher icons when installing the app).
Try flutter run with an Android device attached/emulated, it will fail with the error:

package identifier or launch activity not found.
Please check
[redacted_path]/flutter_android_activity_alias_issue/android/app/src/main/AndroidManifest.xml for errors.
No application found for TargetPlatform.android_x86.
Is your project missing an android/app/src/main/AndroidManifest.xml?
Consider running "flutter create ." to create one.

Logs

Logs
[redacted]:flutter_android_activity_alias_issue pieter$ flutter run
Launching lib/main.dart on sdk gphone x86 in debug mode...
package identifier or launch activity not found.
Please check
[redacted_path]/flutter_android_activity_alias_issue/android/app/src/main/AndroidManifest.xml for errors.
No application found for TargetPlatform.android_x86.
Is your project missing an android/app/src/main/AndroidManifest.xml?
Consider running "flutter create ." to create one.

Flutter doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.3, on macOS 11.2.3 20D91 darwin-x64, locale
    en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] IntelliJ IDEA Community Edition (version 2021.1)
[✓] Connected device (3 available)

• No issues found!

The issue is "fixed" when some build data is already there, for example when running flutter build apk --debug and then flutter run.

Example build and then run output
MACC02XF4FFJGH5:flutter_android_activity_alias_issue pieter$ flutter build apk --debug
Running Gradle task 'assembleDebug'...
Running Gradle task 'assembleDebug'... Done                        33.2s
✓ Built build/app/outputs/flutter-apk/app-debug.apk.
MACC02XF4FFJGH5:flutter_android_activity_alias_issue pieter$ flutter run
Using hardware rendering with device sdk gphone x86. If you notice graphics
artifacts, consider enabling software rendering with
"--enable-software-rendering".
Launching lib/main.dart on sdk gphone x86 in debug mode...
Running Gradle task 'assembleDebug'...
Running Gradle task 'assembleDebug'... Done                        15.6s
✓ Built build/app/outputs/flutter-apk/app-debug.apk.
Installing build/app/outputs/flutter-apk/app.apk...                 1.0s
Waiting for sdk gphone x86 to report its views...                    8ms
Syncing files to device sdk gphone x86...                          366ms

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h Repeat this help message.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).
An Observatory debugger and profiler on sdk gphone x86 is available at:
http://<IP_ADDRESS>:60650/3epvlPSac4E=/

But, after running flutter clean you will again run into the error when using flutter run..

Hi @PieterAelse
activity-alias not yet supported
I see there's an open issue addressing the case you described.
Please follow up on that issue, Closing as duplicate of https://github.com/flutter/flutter/issues/38965
If you disagree, please write in the comments and I will reopen it.
Thank you


Don't draw widgets when the draw area is small

When the user minimizes the dragsplit area, all the widgets get drawn even though the constraint size is zero.
Skip drawing widgets when the size is small. However, we should still call layout to handle user inputs, so skipping the drawing entirely is not an option.

Closing this as there are far more important things to do.


Add LiveData filter, merge, and map.

Add LiveData Extensions filter, merge, and map.
It's just a copied from an In-house project. 🙏

🙏


G so c final

Some last minute changes before GSoC final evaluation.
Adds support to change number of systems, and allows more than 2 spawn configs to be present on the screen at once without hindering with the other UI.

Uh oh, something went wrong with the build. Need to check on that

Hooray Jenkins reported success with all tests good!


Is maximumSelectionLength and closeOnSelect used on same time ?

Prerequisites

[-] I have searched for similar issues in both open and closed tickets and cannot find a duplicate
[ ] The issue still exists against the latest master branch of Select2
[ ] This is not a usage question (Those should be directed to the community)
[ ] I have attempted to find the simplest possible steps to reproduce the issue
[ ] I have included a failing test as a pull request (Optional)

Steps to reproduce the issue

set options maximumSelectionLength:2, closeOnSelect: false for select tag with multiple attribute.
closeOnSelect:false is working fine but the maximumSelectionLength:2 is not working.
able to select all the options in dropdown.
maximumSelectionLength error message displays when i delete the options from input box
Please find the attachment. the error message displays when i delete the options

Expected behavior and actual behavior
When I follow those steps, I see, able to select all the options in dropdown
I was expecting, close the dropdown after select 2 options
Environment
Browsers

[-] Google Chrome
[-] Mozilla Firefox
[ ] Internet Explorer

Operating System

[ ] Windows
[-] Mac OS X
[ ] Linux
[ ] Mobile

Libraries

jQuery version: 1.11.3
Select2 version: 4.0.2

Isolating the problem

[ ] This bug happens on the examples page
[-] The bug happens consistently across all tested browsers
[ ] This bug happens when using Select2 without other plugins
[ ] I can reproduce this bug in a jsbin

This is a duplicate of #3514.


Missed type for type: ['array'], produces unknown[]

Description
Hi,
Thank you for great package. It is a lifesaver.
I've found a quite critical bug, it can't work with array of string, number, etc.
{
  "type": [
    "array"
  ],
  "items": {
    "type": [
      "string"
    ]
  }
}

It will produce prop: unknown[] instead of prop: string[].
There is a hack, if we will change to type: 'string', then it works as expected. But code generator does not do that for openapi schema :(
{
  "type": "array",
  "items": {
    "type": [
      "string"
    ]
  }
}

Same situation with type: ['object']
Can you please fix it or give a workaround?
OpenAPI specification (optional)
{
  "policies": {
    "type": [
      "object"
    ],
    "additionalProperties": {
      "type": [
        "string"
      ]
    }
  },
  "roles": {
    "type": [
      "array"
    ],
    "items": {
      "type": [
        "string"
      ]
    }
  }
}

Configuration
No response
System information (optional)
No response

Hey @ianberdin, does your OpenAPI specification pass the validator?

Yes, redoc, scalar, swagger ui works.
Proof:

An additional issue, possibly related: if we add a nullable field, the array type becomes unknown again.

Interesting, since Swagger itself says that

type as a list is not valid in OpenAPI (even though it is valid in JSON Schema)

I'll have a look anyway. Can you also share how you're defining nullable field?

Nullable array.
Actually that is why array schema used by openapi, in order to add null there.
{
  "roles": {
    "type": [
      "array",
      "null"
    ],
    "items": {
      "type": [
        "string"
      ]
    }
  }
}

I use @anatine/zod-openapi to generate schema from zod.
Playground

Thank you, I'll fix it

I can help you if you will point me where to look for?

I worry I'd need to walk you through the internal Model interface. It's either going to be incorrectly parsed there as this is an OpenAPI 3.1 feature, or in the TypeScript Compiler API producing the final output. I'll have a look at it this week though

@ianberdin This is fixed in v0.43.1, please open a new issue if you run into any more problems!

Wow! I can't contain my excitement, I'm so happy.
Thank you so much for your hard work. I really appreciate it.