Homebridge startup exists without error after initializing the z-way devices

Hi all,
when starting up homebridge, the process initializes the z-way devices but then quits without error message.
Debug Log:
root@raspberrypi:/tmp#  DEBUG=* homebridge -U ~/.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>
[2016-03-17 14:01:09] Loaded plugin: homebridge-zway
[2016-03-17 14:01:09] Registering accessory 'homebridge-zway.ZWayServer'
[2016-03-17 14:01:09] Registering platform 'homebridge-zway.ZWayServer'
[2016-03-17 14:01:09] ---
[2016-03-17 14:01:09] Loaded config.json with 0 accessories and 1 platforms.
[2016-03-17 14:01:09] ---
[2016-03-17 14:01:09] Loading 1 platforms...
[2016-03-17 14:01:09] Initializing ZWayServer platform...
  ZWayServer Fetching Z-Way devices... +0ms
  ZWayServer Authenticating... +255ms
  ZWayServer Authenticated. Resubmitting original request... +111ms
  ZWayServer Got typeKey battery.Battery for vdev BatteryPolling_8 +66ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
  ZWayServer Got typeKey sensorMultiline.Temperature for vdev OpenWeather_20 +125ms
  ZWayServer { deviceType: 'sensorMultiline', probeTitle: 'Temperature', probeType: '' } +0ms
  ZWayServer Got typeKey toggleButton for vdev LightScene_13 +3ms
  ZWayServer { deviceType: 'toggleButton', probeTitle: undefined, probeType: '' } +1ms
  ZWayServer Got typeKey toggleButton for vdev LightScene_14 +2ms
  ZWayServer { deviceType: 'toggleButton', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey buttonControl for vdev ZWayVDev_zway_Remote_2-1-1-B +2ms
  ZWayServer { deviceType: 'buttonControl', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey buttonControl for vdev ZWayVDev_zway_Remote_2-124-1-B +2ms
  ZWayServer { deviceType: 'buttonControl', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey sensorBinary.General purpose for vdev ZWayVDev_zway_2-0-48-1 +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: 'General purpose', probeType: 'general_purpose' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +3ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +1ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +2ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
  ZWayServer Got typeKey sensorBinary.alarmSensor_general_purpose for vdev ZWayVDev_zway_2-0-156-0-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarmSensor_general_purpose' } +0ms
  ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +2ms
  ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_3-0-49-4 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_3-0-50-0 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_3-0-50-2 +3ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
  ZWayServer Got typeKey switchBinary for vdev Sonos_Device_Play_<IP_ADDRESS>_22 +2ms
  ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +2ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_4-0-49-4 +8ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_4-0-50-0 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_4-0-50-2 +6ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_heat for vdev ZWayVDev_zway_4-0-113-4-2-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_heat' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-4-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-5-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-6-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-8-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-9-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_system for vdev ZWayVDev_zway_4-0-113-9-1-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_system' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +2ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-2-38 +3ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_4-1-49-4 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_heat for vdev ZWayVDev_zway_4-0-113-4-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_heat' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_system for vdev ZWayVDev_zway_4-0-113-9-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_system' } +1ms
  ZWayServer Got grouped device BatteryPolling_8 consiting of devices: +1ms
  ZWayServer BatteryPolling_8 - battery.Battery +1ms
  ZWayServer WARN: Didn't find suitable device class! +0ms
  ZWayServer Got grouped device OpenWeather_20 consiting of devices: +1ms
  ZWayServer OpenWeather_20 - sensorMultiline.Temperature +0ms
  ZWayServer WARN: Didn't find suitable device class! +0ms
  ZWayServer Got grouped device LightScene_13 consiting of devices: +0ms
  ZWayServer LightScene_13 - toggleButton +1ms
  ZWayServer WARN: Didn't find suitable device class! +0ms
  ZWayServer Got grouped device LightScene_14 consiting of devices: +0ms
  ZWayServer LightScene_14 - toggleButton +1ms
  ZWayServer WARN: Didn't find suitable device class! +0ms
  ZWayServer Got grouped device ZWayVDev_zway_Remote_2-1-1-B consiting of devices: +0ms
  ZWayServer ZWayVDev_zway_Remote_2-1-1-B - buttonControl +0ms
  ZWayServer WARN: Didn't find suitable device class! +1ms
  ZWayServer Got grouped device ZWayVDev_zway_Remote_2-124-1-B consiting of devices: +0ms
  ZWayServer ZWayVDev_zway_Remote_2-124-1-B - buttonControl +0ms
  ZWayServer WARN: Didn't find suitable device class! +0ms
  ZWayServer Got grouped device ZWayVDev_2-0 consiting of devices: +1ms
  ZWayServer ZWayVDev_zway_2-0-48-1 - sensorBinary.General purpose +0ms
  ZWayServer ZWayVDev_zway_2-0-49-1 - sensorMultilevel.Temperature +0ms
  ZWayServer ZWayVDev_zway_2-0-49-3 - sensorMultilevel.Luminiscence +0ms
  ZWayServer ZWayVDev_zway_2-0-128 - battery.Battery +1ms
  ZWayServer ZWayVDev_zway_2-0-156-0-A - sensorBinary +0ms
  ZWayServer Got grouped device ZWayVDev_3-0 consiting of devices: +1ms
  ZWayServer ZWayVDev_zway_3-0-37 - switchBinary +0ms
  ZWayServer ZWayVDev_zway_3-0-49-4 - sensorMultilevel.Power +1ms
  ZWayServer ZWayVDev_zway_3-0-50-0 - sensorMultilevel.Electric +0ms
  ZWayServer ZWayVDev_zway_3-0-50-2 - sensorMultilevel.Electric +0ms
  ZWayServer Got grouped device Sonos_Device_Play_<IP_ADDRESS>_22 consiting of devices: +1ms
  ZWayServer Sonos_Device_Play_<IP_ADDRESS>_22 - switchBinary +1ms
  ZWayServer Got grouped device Sonos_Device_Volume_<IP_ADDRESS>_22 consiting of devices: +0ms
  ZWayServer Sonos_Device_Volume_<IP_ADDRESS>_22 - switchMultilevel +1ms
  ZWayServer Got grouped device ZWayVDev_4-0 consiting of devices: +0ms
  ZWayServer ZWayVDev_zway_4-0-49-4 - sensorMultilevel.Power +0ms
  ZWayServer ZWayVDev_zway_4-0-50-0 - sensorMultilevel.Electric +0ms
  ZWayServer ZWayVDev_zway_4-0-50-2 - sensorMultilevel.Electric +1ms
  ZWayServer ZWayVDev_zway_4-0-113-4-2-A - sensorBinary +1ms
  ZWayServer ZWayVDev_zway_4-0-113-8-4-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-113-8-5-A - sensorBinary +1ms
  ZWayServer ZWayVDev_zway_4-0-113-8-6-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-113-8-8-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-113-8-9-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-113-9-1-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-38 - switchMultilevel +1ms
  ZWayServer ZWayVDev_zway_4-0-113-4-254-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-113-8-254-A - sensorBinary +0ms
  ZWayServer ZWayVDev_zway_4-0-113-9-254-A - sensorBinary +0ms
  ZWayServer Got grouped device ZWayVDev_4-1 consiting of devices: +1ms
  ZWayServer ZWayVDev_zway_4-1-38 - switchMultilevel +2ms
  ZWayServer ZWayVDev_zway_4-1-49-4 - sensorMultilevel.Power +4ms
  ZWayServer Got grouped device ZWayVDev_4-2 consiting of devices: +4ms
  ZWayServer ZWayVDev_zway_4-2-38 - switchMultilevel +0ms
[2016-03-17 14:01:10] Initializing platform accessory 'Motion Sensor - Temperatur'...
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +22ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +0ms
  ZWayServer Got typeKey sensorBinary.General purpose for vdev ZWayVDev_zway_2-0-48-1 +55ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: 'General purpose', probeType: 'general_purpose' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +0ms
  ZWayServer Got typeKey sensorBinary.General purpose for vdev ZWayVDev_zway_2-0-48-1 +3ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: 'General purpose', probeType: 'general_purpose' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +5ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +0ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +3ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +1ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +4ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +1ms
  ZWayServer Got typeKey sensorBinary.General purpose for vdev ZWayVDev_zway_2-0-48-1 +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: 'General purpose', probeType: 'general_purpose' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +5ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +1ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +2ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
  ZWayServer Got typeKey sensorBinary.alarmSensor_general_purpose for vdev ZWayVDev_zway_2-0-156-0-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarmSensor_general_purpose' } +0ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +1ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +1ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +6ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +6ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +1ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +2ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +5ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +1ms
  ZWayServer Got typeKey sensorBinary.General purpose for vdev ZWayVDev_zway_2-0-48-1 +5ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: 'General purpose', probeType: 'general_purpose' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +0ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +1ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +1ms
  ZWayServer Got typeKey sensorBinary.alarmSensor_general_purpose for vdev ZWayVDev_zway_2-0-156-0-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarmSensor_general_purpose' } +0ms
  ZWayServer Got typeKey sensorBinary.General purpose for vdev ZWayVDev_zway_2-0-48-1 +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: 'General purpose', probeType: 'general_purpose' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Temperature for vdev ZWayVDev_zway_2-0-49-1 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Temperature', probeType: 'temperature' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Luminiscence for vdev ZWayVDev_zway_2-0-49-3 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Luminiscence', probeType: 'luminosity' } +0ms
  ZWayServer Got typeKey battery.Battery for vdev ZWayVDev_zway_2-0-128 +0ms
  ZWayServer { deviceType: 'battery', probeTitle: 'Battery', probeType: '' } +0ms
  ZWayServer Loaded services for Motion Sensor - Temperatur +1ms
[2016-03-17 14:01:10] Initializing platform accessory 'Steckdose - Schalter'...
  ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +25ms
  ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
  ZWayServer Got typeKey switchBinary for vdev ZWayVDev_zway_3-0-37 +13ms
  ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Loaded services for Steckdose - Schalter +6ms
[2016-03-17 14:01:10] Initializing platform accessory 'Sonos Büro'...
  ZWayServer Got typeKey switchBinary for vdev Sonos_Device_Play_<IP_ADDRESS>_22 +11ms
  ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +1ms
  ZWayServer Got typeKey switchBinary for vdev Sonos_Device_Play_<IP_ADDRESS>_22 +4ms
  ZWayServer { deviceType: 'switchBinary', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Loaded services for Sonos Büro +3ms
[2016-03-17 14:01:10] Initializing platform accessory 'Sonos Büro - Lautstärke'...
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +8ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +5ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +2ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +4ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev Sonos_Device_Volume_<IP_ADDRESS>_22 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: '' } +1ms
  ZWayServer Loaded services for Sonos Büro - Lautstärke +1ms
[2016-03-17 14:01:10] Initializing platform accessory 'Deckenlicht Büro'...
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +8ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +3ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +2ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_4-0-49-4 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_4-0-50-0 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_4-0-50-2 +2ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_heat for vdev ZWayVDev_zway_4-0-113-4-2-A +5ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_heat' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-4-A +3ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-5-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-6-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-8-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-9-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_system for vdev ZWayVDev_zway_4-0-113-9-1-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_system' } +1ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +2ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_heat for vdev ZWayVDev_zway_4-0-113-4-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_heat' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_system for vdev ZWayVDev_zway_4-0-113-9-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_system' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_4-0-49-4 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_4-0-50-0 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_kilowatt_per_hour' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Electric for vdev ZWayVDev_zway_4-0-50-2 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Electric', probeType: 'meterElectric_watt' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_heat for vdev ZWayVDev_zway_4-0-113-4-2-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_heat' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-4-A +5ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-5-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-6-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-8-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-9-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_system for vdev ZWayVDev_zway_4-0-113-9-1-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_system' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-0-38 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey sensorBinary.alarm_heat for vdev ZWayVDev_zway_4-0-113-4-254-A +4ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_heat' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_power for vdev ZWayVDev_zway_4-0-113-8-254-A +2ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_power' } +1ms
  ZWayServer Got typeKey sensorBinary.alarm_system for vdev ZWayVDev_zway_4-0-113-9-254-A +1ms
  ZWayServer { deviceType: 'sensorBinary', probeTitle: undefined, probeType: 'alarm_system' } +0ms
  ZWayServer Loaded services for Deckenlicht Büro +1ms
[2016-03-17 14:01:10] Initializing platform accessory 'Deckenlicht Büro'...
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +8ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +5ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +4ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +2ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +0ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_4-1-49-4 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +0ms
  ZWayServer Got typeKey switchMultilevel for vdev ZWayVDev_zway_4-1-38 +1ms
  ZWayServer { deviceType: 'switchMultilevel', probeTitle: undefined, probeType: 'dimmer' } +1ms
  ZWayServer Got typeKey sensorMultilevel.Power for vdev ZWayVDev_zway_4-1-49-4 +1ms
  ZWayServer { deviceType: 'sensorMultilevel', probeTitle: 'Power', probeType: 'energy' } +0ms
  ZWayServer Loaded services for Deckenlicht Büro +1ms
root@raspberrypi:/tmp#

Thanks,
Johannes

Hello,
Can you provide me a copy of your devices output? You'll need to login to the Z-Way standard UI--e.g. at http://your.pi.i.p:8083/, and then from that same browser window hit http://your.pi.i.p:8083/ZAutomation/api/v1/devices (replacing your.pi.i.p with your device's IP address of course), and attach or post the contents here.

Hi,
this is the requested output:
{"data":{"structureChanged":true,"updateTime":1458284628,"devices":[{"creationTime":1453473440,"creatorId":8,"deviceType":"battery","h":-592588977,"hasHistory":false,"id":"BatteryPolling_8","location":0,"metrics":{"probeTitle":"Battery","scaleTitle":"%","title":"Battery digest 8","level":100},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458062903},{"creationTime":1458061306,"creatorId":20,"deviceType":"sensorMultiline","h":-1611286413,"hasHistory":false,"id":"OpenWeather_20","location":1,"metrics":{"scaleTitle":"°C","title":"München","probeTitle":"Temperature","zwaveOpenWeather":{"main":{"temp":283.55,"pressure":1016,"humidity":100,"temp_min":282.04,"temp_max":284.15},"weather":[{"id":701,"main":"Mist","description":"mist","icon":"50d"}],"wind":{"speed":3.1,"deg":40}},"level":10.4,"icon":"http://openweathermap.org/img/w/50d.png","country":"DE","flag":"http://openweathermap.org/images/flags/de.png","multilineType":"openWeather"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458061306},{"creationTime":1453473427,"creatorId":13,"deviceType":"toggleButton","h":557861323,"hasHistory":true,"id":"LightScene_13","location":1,"metrics":{"level":"on","icon":"","title":"Light Scene 13"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458117215},{"creationTime":1453473427,"creatorId":14,"deviceType":"toggleButton","h":557861324,"hasHistory":true,"id":"LightScene_14","location":1,"metrics":{"level":"on","icon":"","title":"Light Scene 14"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458118415},{"creationTime":1453473438,"deviceType":"buttonControl","h":434271221,"hasHistory":true,"id":"ZWayVDev_zway_Remote_2-1-1-B","location":1,"metrics":{"icon":"","title":"Button Fibar Group 1-1","level":"on","change":""},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458284584},{"creationTime":1453473438,"deviceType":"buttonControl","h":868717111,"hasHistory":true,"id":"ZWayVDev_zway_Remote_2-124-1-B","location":0,"metrics":{"icon":"","title":"Button Fibar Group 124-1","level":"off","change":""},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458061500},{"creationTime":1453473440,"creatorId":1,"deviceType":"sensorBinary","h":1303282175,"hasHistory":true,"id":"ZWayVDev_zway_2-0-48-1","location":1,"metrics":{"probeTitle":"General purpose","scaleTitle":"","icon":"motion","level":"on","title":"Motion Sensor - Bewegung"},"permanently_hidden":false,"probeType":"general_purpose","tags":[],"visibility":true,"updateTime":1458284584},{"creationTime":1453473440,"creatorId":1,"deviceType":"sensorMultilevel","h":1303283136,"hasHistory":true,"id":"ZWayVDev_zway_2-0-49-1","location":1,"metrics":{"probeTitle":"Temperature","scaleTitle":"°C","level":23.2,"icon":"temperature","title":"Motion Sensor - Temperatur"},"permanently_hidden":false,"probeType":"temperature","tags":[],"visibility":true,"updateTime":1458284428},{"creationTime":1453473440,"creatorId":1,"deviceType":"sensorMultilevel","h":1303283138,"hasHistory":true,"id":"ZWayVDev_zway_2-0-49-3","location":1,"metrics":{"probeTitle":"Luminiscence","scaleTitle":"Lux","level":51,"icon":"luminosity","title":"Motion Sensor - Helligkeit"},"permanently_hidden":false,"probeType":"luminosity","tags":[],"visibility":true,"updateTime":1458061500},{"creationTime":1453473441,"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":"Battery 2-0 Fibar Group"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458062903},{"creationTime":1453473441,"creatorId":1,"deviceType":"sensorBinary","h":1129728498,"hasHistory":true,"id":"ZWayVDev_zway_2-0-156-0-A","location":1,"metrics":{"icon":"alarm","level":"off","title":"Motion Sensor - Alarm"},"permanently_hidden":false,"probeType":"alarmSensor_general_purpose","tags":[],"visibility":true,"updateTime":1458061500},{"creationTime":1453473441,"creatorId":1,"deviceType":"switchBinary","h":1107079066,"hasHistory":true,"id":"ZWayVDev_zway_3-0-37","location":1,"metrics":{"icon":"switch","title":"Steckdose - Schalter","level":"off"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458118415},{"creationTime":1453473441,"creatorId":1,"deviceType":"sensorMultilevel","h":-1248873822,"hasHistory":true,"id":"ZWayVDev_zway_3-0-49-4","location":1,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Steckdose - Verbrauch Aktuell"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1458284402},{"creationTime":1453473441,"creatorId":1,"deviceType":"sensorMultilevel","h":-1248852684,"hasHistory":true,"id":"ZWayVDev_zway_3-0-50-0","location":1,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":8.08,"icon":"meter","title":"Steckdose - Verbrauch Summe"},"permanently_hidden":false,"probeType":"meterElectric_kilowatt_per_hour","tags":[],"visibility":true,"updateTime":1458284402},{"creationTime":1453473441,"creatorId":1,"deviceType":"sensorMultilevel","h":-1248852682,"hasHistory":true,"id":"ZWayVDev_zway_3-0-50-2","location":1,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Steckdose - Verbrauch ?"},"permanently_hidden":false,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1458283801},{"creationTime":1458060864,"creatorId":22,"deviceType":"switchBinary","h":1884175838,"hasHistory":true,"id":"Sonos_Device_Play_<IP_ADDRESS>_22","location":1,"metrics":{"title":"Sonos Büro","icon":"","level":"off"},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458282101},{"creationTime":1458060864,"creatorId":22,"deviceType":"switchMultilevel","h":-1360300604,"hasHistory":true,"id":"Sonos_Device_Volume_<IP_ADDRESS>_22","location":1,"metrics":{"title":"Sonos Büro - Lautstärke","icon":"","level":20},"permanently_hidden":false,"probeType":"","tags":[],"visibility":true,"updateTime":1458282101},{"creationTime":1453473441,"creatorId":1,"deviceType":"sensorMultilevel","h":493936513,"hasHistory":true,"id":"ZWayVDev_zway_4-0-49-4","location":"1","metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Sensor Power 4-0-49-4 Fibar Group"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1458283801},{"creationTime":1453473441,"creatorId":1,"deviceType":"sensorMultilevel","h":493957651,"hasHistory":true,"id":"ZWayVDev_zway_4-0-50-0","location":"1","metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":4.2800004,"icon":"meter","title":"Meter Electric 4-0-50-0 Fibar Group"},"permanently_hidden":false,"probeType":"meterElectric_kilowatt_per_hour","tags":[],"visibility":true,"updateTime":1458283801},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorMultilevel","h":493957653,"hasHistory":true,"id":"ZWayVDev_zway_4-0-50-2","location":"1","metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Meter Electric 4-0-50-2 Fibar Group"},"permanently_hidden":false,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1458284402},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1710385310,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-4-2-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm Heat 4-0-113-4-2 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1714081316,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-8-4-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm Power Management 4-0-113-8-4 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1714082277,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-8-5-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm Power Management 4-0-113-8-5 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1714083238,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-8-6-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm Power Management 4-0-113-8-6 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1714085160,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-8-8-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm Power Management 4-0-113-8-8 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1714086121,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-8-9-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm Power Management 4-0-113-8-9 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorBinary","h":1715001954,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-9-1-A","location":"1","metrics":{"icon":"alarm","level":"off","title":"Alarm System 4-0-113-9-1 Fibar Group"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1458063001},{"creationTime":1453473442,"creatorId":1,"deviceType":"switchMultilevel","h":1135708218,"hasHistory":true,"id":"ZWayVDev_zway_4-0-38","location":1,"metrics":{"icon":"multilevel","title":"Deckenlicht Büro","level":0},"permanently_hidden":false,"probeType":"dimmer","tags":[],"visibility":true,"updateTime":1458118416},{"creationTime":1453473442,"creatorId":1,"deviceType":"switchMultilevel","h":1135738009,"hasHistory":true,"id":"ZWayVDev_zway_4-1-38","location":0,"metrics":{"icon":"multilevel","title":"Deckenlicht Büro","level":0},"permanently_hidden":false,"probeType":"dimmer","tags":[],"visibility":true,"updateTime":1458248619},{"creationTime":1458062712,"creatorId":1,"deviceType":"switchMultilevel","h":1135767800,"hasHistory":true,"id":"ZWayVDev_zway_4-2-38","location":0,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (4.2)","level":19},"permanently_hidden":false,"probeType":"dimmer","tags":[],"visibility":true,"updateTime":1458248240},{"creationTime":1453473442,"creatorId":1,"deviceType":"sensorMultilevel","h":522565664,"hasHistory":true,"id":"ZWayVDev_zway_4-1-49-4","location":0,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Sensor Power 4-1-49-4 Fibar Group"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1458281189},{"creationTime":1453474298,"creatorId":1,"deviceType":"sensorBinary","h":-1291964163,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-4-254-A","location":0,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1458284403},{"creationTime":1453474298,"creatorId":1,"deviceType":"sensorBinary","h":-2036916735,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-8-254-A","location":0,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458284403},{"creationTime":1453474299,"creatorId":1,"deviceType":"sensorBinary","h":-1149413054,"hasHistory":true,"id":"ZWayVDev_zway_4-0-113-9-254-A","location":0,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group System Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1458284403},{"creationTime":1458240848,"creatorId":1,"deviceType":"sensorMultilevel","h":-2058220448,"hasHistory":true,"id":"ZWayVDev_zway_5-0-49-4","location":0,"metrics":{"probeTitle":"Power","scaleTitle":"W","level":0,"icon":"energy","title":"Fibar Group Power (<IP_ADDRESS>)"},"permanently_hidden":false,"probeType":"energy","tags":[],"visibility":true,"updateTime":1458283802},{"creationTime":1458240854,"creatorId":1,"deviceType":"sensorMultilevel","h":-2058199310,"hasHistory":true,"id":"ZWayVDev_zway_5-0-50-0","location":0,"metrics":{"probeTitle":"Electric","scaleTitle":"kWh","level":0,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":false,"probeType":"meterElectric_kilowatt_per_hour","tags":[],"visibility":true,"updateTime":1458283202},{"creationTime":1458240854,"creatorId":1,"deviceType":"sensorMultilevel","h":-2058199308,"hasHistory":true,"id":"ZWayVDev_zway_5-0-50-2","location":0,"metrics":{"probeTitle":"Electric","scaleTitle":"W","level":0,"icon":"meter","title":"Fibar Group Electric Meter (<IP_ADDRESS>)"},"permanently_hidden":false,"probeType":"meterElectric_watt","tags":[],"visibility":true,"updateTime":1458284403},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1416982303,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-4-2-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.2)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1420678309,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-8-4-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.4)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1420679270,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-8-5-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.5)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1420680231,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-8-6-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.6)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1420682153,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-8-8-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.8)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1420683114,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-8-9-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.9)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240855,"creatorId":1,"deviceType":"sensorBinary","h":1421598947,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-9-1-A","location":0,"metrics":{"icon":"alarm","level":"off","title":"Fibar Group System Alarm (<IP_ADDRESS>.1)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1458240901},{"creationTime":1458240856,"creatorId":1,"deviceType":"switchMultilevel","h":1164337369,"hasHistory":true,"id":"ZWayVDev_zway_5-0-38","location":0,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (5.0)","level":0},"permanently_hidden":false,"probeType":"dimmer","tags":[],"visibility":true,"updateTime":1458248658},{"creationTime":1458240864,"creatorId":1,"deviceType":"switchMultilevel","h":1164367160,"hasHistory":true,"id":"ZWayVDev_zway_5-1-38","location":0,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (5.1)","level":0},"permanently_hidden":false,"probeType":"dimmer","tags":[],"visibility":true,"updateTime":1458248651},{"creationTime":1458240868,"creatorId":1,"deviceType":"switchMultilevel","h":1164396951,"hasHistory":true,"id":"ZWayVDev_zway_5-2-38","location":0,"metrics":{"icon":"multilevel","title":"Fibar Group Dimmer (5.2)","level":0},"permanently_hidden":false,"probeType":"dimmer","tags":[],"visibility":true,"updateTime":1458248646},{"creationTime":1458241804,"creatorId":1,"deviceType":"sensorBinary","h":215587646,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-4-254-A","location":0,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Heat Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_heat","tags":[],"visibility":true,"updateTime":1458284403},{"creationTime":1458241804,"creatorId":1,"deviceType":"sensorBinary","h":-529364926,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-8-254-A","location":0,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group Power Management Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_power","tags":[],"visibility":true,"updateTime":1458283803},{"creationTime":1458241805,"creatorId":1,"deviceType":"sensorBinary","h":358138755,"hasHistory":true,"id":"ZWayVDev_zway_5-0-113-9-254-A","location":0,"metrics":{"icon":"alarm","level":"on","title":"Fibar Group System Alarm (<IP_ADDRESS>.254)"},"permanently_hidden":false,"probeType":"alarm_system","tags":[],"visibility":true,"updateTime":1458284404}]},"code":200,"message":"200 OK","error":null}

I created 2 code devices (sensor binary, sensor multilevel) and 2 dummy devices (binary switch, multilevel switch).
In log I see that dummys created, ant then homebridge go out with out error.

@eicosan It appears your problem is happening because you have two accessories both named "Deckenlicht Büro", and apparently Homebridge requires all displayNames to be unique--and/or I need to do something so that duplicate names do not cause a problem in that case.
(I may also be swallowing error messages, I will have to look at that.)
I am marking this as a bug and will leave it open until the bug is fixed in this plugin, but in the meantime you can work around this by going into the Z-Way web interface and renaming one of your "Deckenlicht Büro" devices to a different name (just add a "2" or something)...that should let you finish launching. Check and see if you have any other duplicate names also, just in case.
@aivs I suppose it's possible that two of your devices also have the same name, but if not then your issue is probably a different one. Can you follow the instructions above to download your devices information and then post that in a second issue?

Hi,
the rename of the duplicate name resolved the startup of homebridge.
But now I'm not able to connect to it from iOS. I already deleted it from settings menu and tried to re-add it, but the homebridge device is not found... Any idea?
Thanks!

@eicosan Sorry, just saw this. That depends.  That should at least allow it to appear again to be paired. If it appears, but fails to pair, then there's some illegal output from the plugin(s) and we'll have to troubleshoot that.

Pushing this to 0.6.0 milestone for a few reasons. One, fixing this will cause all device UUIDs to change, which will force users to rebuild homekit scenes/groups/triggers/etc--this will probably happen when I implement the "plugin 2.0" API from Homebridge, so better to have this happen only once instead of twice. Two, going to the plugin 2.0 API may fix this by default.
Again, if anyone hits this same problem, the workaround is to make sure you don't have any Z-Way devices with duplicate names.
Depends #26

Hi together,
I have basically the same issue, but can't get it solved...:
Starting up homebridge suddenly simply exits right after Initializing some platform accessories.
So first I deactivated all homebridge plugins, but still no luck.
Next, as discussed above, I made sure, that I don't have any duplicate names (which I had indeed) and renamed those unqiuely. - still no luck.
I am running<EMAIL_ADDRESS>Strange. Any ideas or recommendation where to look at / what to check?

Ok, too knowsie to wait. I continued deactivating devices in UI step by step. And suddenly, after deactivating most of them, it started to work. Will have to find out now, what devices is exactly causing this issue...   Let you know about it.
But, also one little recommendation:
Would be really a great help, if some "error messages" would be shown, if something goes wrong with homebridge-zway....

Actually if you run DEBUG=ZWayServer homebridge or DEBUG=* homebridge` you should get some more information. Possibly too much.

I found out, what's causing my mess here.
For some reason, (suddenly) the formerly working fibaro motion sensor is causing my trouble.
I have two of them and as soon as I activate the device "motion alarm" homebridge is quitting.
If I activate e.g. Fibar Group Luminiscence oder Temperature alarm, it's not causing any problems.
So it really seems to be the "Fibaro motion alarm" itself that's causing this.

@klaasjoerg Okay, (capture your devices data)[https://github.com/SphtKr/homebridge-zway#getting-zautomationapiv1devices] and probably open a new ticket, as this now looks like a separate issue. Also, see if you can figure out what version of Firmware you have on your Fibaro motion sensor. Some other folks are having trouble with that device (though I haven't heard of Homebridge quitting because of it) and the firmware version seems to make a difference. I have one myself but it causes me no problems, so there's probably something different in other firmware versions.

Oops, nope, I meant to leave this open to fix UUID conflicts for duplicate names.


Improved the english on the greater than or equal to message

Added the correct english for the message.

Not quite sure what failed, but the gist of the change is to improve the readability of the text. I have kept it short, a more accurate version would be: The input is neither greater than nor equal to '%s'


Update autoescape option

Issue
As discussed here, autoescape = true has been deprecated since Twig 1.21 in favor of autoescape = 'html'.
Solution
This PR updates the docs to reflect this change, and adds a fallback to automatically change Timber::$autoescape = true to Timber::$autoescape = 'html' if applicable.
Impact
No impact.
Usage Changes
It is recommended to update Timber::$autoescape = true to Timber::$autoescape = 'html' to ensure compatibility with Timber 2.x.
Considerations
N/A
Testing
N/A

I've also updated the upgrade guide and the docs for 2.x:

https://github.com/danielpost/timber/commit/bb538c762d7617931fa3792e59bf11d572a668eb
https://github.com/danielpost/timber/commit/6fd6c4ec0d7c41b06fe8c1ba949c290dbe453541

Do you want me to create two separate PR's for this? I couldn't figure out how to easily combine it as the Upgrade Guides and Docs are maintained in separate branches from what I noticed.

@danielpost Cool! Thanks for that pull request 😎.
I just merged in the Upgrade Guide into the 2.x-docs branch. So you could create your pull request against the 2.x-docs branch.

Coverage remained the same at 94.03% when pulling a104f41ef86cd17ef2422bc2f75bdc1ec745af28 on danielpost:master into 3de6a72bfc9abe1bff93accc19eca24d2e9fa91d on timber:master.

Thanks @danielpost for your research and looking into this. I really appreciate the compatibility planning you put in — makes these version transitions much easier for users. Merged!


feature: new role for UWG members

Description
Adding a role for UWG members, to support the GES DISC task of assigning UWG members to a review
Spec
Designs: [link to design if applicable; delete if not]
See Ticket: [link to ticket if applicable; delete if not]

Validation

Make sure all merge request checks have passed (CI/CD).
Pull related branches locally.
Navigate to... [continue instructions]

(For an example of good validation instructions, check out
Bryan's Bouncy Ball PR.)

Change Log
(copy/paste-able change log notes. check the box when the change is also in CHANGELOG.md)

[Add _____](link to commitid)
[Fix _____](link to commitid)

@joncarlson @DavisGauntUAH Have the requested changes of this PR been resolved? Is this PR ready to be validated for merging?

@camposeddie Yes, I've made the requested changes

Everything looks good with the assumption that https://github.com/eosdis-nasa/earthdata-pub-dashboard/pull/50 or similar follow on tasks adds functionality so that UWG member is added as a contributor when assigned to review a request. Otherwise, the UWG role doesn't have any visibility into requests.


JDK 11 support

Flank doesn't compile on new Java. Support JDK 11.

http://www.java-countdown.xyz/

Dependency has no plans to update in the short term:

https://github.com/codetojoy/easter_eggs_for_java_9/blob/master/egg_34_stack_overflow_47727869/run.sh

https://github.com/FasterXML/jackson-core/pull/358

many dependencies lack the required module-info.java and automatic modules are not working either.
Hopefully in a year or two, the ecosystem will update to use Java modules.

https://github.com/googleapis/google-api-java-client/issues/1191
http://files.zeroturnaround.com/pdf/RebelLabs-Java-9-modules-cheat-sheet.pdf
https://stackoverflow.com/a/26009627
https://stackoverflow.com/a/46714106


Authenticator Froze and Possibly Hacked

Yesterday, I attempted several times to use this extension.  It froze and would not give me QR codes.  Once this happened my chrome app would not work or allow me to access websites. I had to remove chrome and reinstall it in order to have access again.  Not sure if virus was an issue.

I'm not sure about your issue, however, please remember to backup your secrets, this is very very very important. If your data is lost, NOBODY can give help.


drumkv1: 0.9.18 -> 0.9.23

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/drumkv1/versions.
meta.description for drumkv1 is: "An old-school drum-kit sampler synthesizer with stereo fx"
meta.homepage for drumkv1 is: "http://drumkv1.sourceforge.net/"
meta.changelog for drumkv1 is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

Warning: no invocation of /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23/bin/drumkv1_jack had a zero exit code or showed the expected version

Warning: no invocation of /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23/bin/.drumkv1_jack-wrapped had a zero exit code or showed the expected version

0 of 2 passed binary check by having a zero exit code.

0 of 2 passed binary check by having the new version present in output.

found 0.9.23 with grep in /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23

found 0.9.23 in filename of file in /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23

directory tree listing: https://gist.github.com/4e24b47aa2517f3d11b8d7cd0dc949c1

du listing: https://gist.github.com/5bda2243458997aeba95d6b8632047d8

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
drumkv1

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A drumkv1 https://github.com/r-ryantm/nixpkgs/archive/7ff192b335dd183d9708e47a22e55285ad7c93d3.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23
ls -la /nix/store/hwypaclzrkxqjmsjhqlyylm9w1sl8yaq-drumkv1-0.9.23/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

drumkv1

Maintainer pings
cc @cillianderoiste for testing.

this can be built with cmake now but builds fine as it is now
https://github.com/archlinux/svntogit-community/commit/e88e6741f9e7ac9461eb042b04f564b53af63130#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a


The input toml file should contain the name of released binary

This will be used as the name of the subject when generating the Amber provenance file. See #50.

In the absence of a name, as is currently the case, we generate a name from the output path and the git commit hash. In particular, in the form of fileName-commitHash, where fileName is the last element of outputPath indicating the name of the output file generated by the build script:
https://github.com/project-oak/transparent-release/blob/2afb748e0b18fbb3da900d93517c5cb5d71c9c69/common/common.go#L279-L283

No longer relevant.


feat: SpanSerde

There's no Serde implementation for Spans. That means we can't for example emit events with Spans. This won't compile:
#[contract]
mod Foo {
    use array::SpanTrait;

    #[event]
    fn Sup(values: Span<u8>) {}

    #[external]
    fn do_something(s: Span<u8>) {
        Sup(s);
    }
}

The error is:
error: Trait has no implementation in context: core::serde::Serde::<core::array::Span::<core::integer::u8>>
 --> contract:21:35
        serde::Serde::<Span<u8>>::serialize(@values, ref __data);
                                  ^*******^

error: Trait has no implementation in context: core::serde::Serde::<core::array::Span::<core::integer::u8>>
 --> contract:53:43
                serde::Serde::<Span<u8>>::deserialize(ref data).expect('Input too short for arguments');
                                          ^*********^

Error: Compilation failed.

This PR adds a SpanSerde that fixes the above error. I hope it's just as simple as I imagine it to be, please tell me if I'm missing something.

This change is

Bump.
Could this still get merged into 1.1.0? I don't care if it's my PR or you do it internally, but people run into this issue all the time, so the sooner it's fixed the better.


Add support for Subaru Forester 2022

Checklist

[x] added entry to CarInfo in selfdrive/car/*/values.py and ran selfdrive/car/docs.py to generate new docs
[x] test route added to routes.py
[x] route with openpilot: 7fd1e4f3a33c1673|2022-12-04--15-09-53
[x] route with stock system: 7fd1e4f3a33c1673|2022-12-07--20-16-23

Prerequisites:

https://github.com/commaai/opendbc/pull/758
https://github.com/commaai/panda/pull/1187

Forester 2022 route: 7fd1e4f3a33c1673|2022-12-07--20-16-23

ES_Status Cruise_Activated signal does not have any issues with standstill, gas and brake press, I will update panda safety and openpilot PR-s

b0cea2db2dd5474e|2023-07-21--12-18-50
successful angle controller based route!

I will open a new PR for the angle based cars (outback23, forester22, and probably many more) when we get the safety merged:
https://github.com/commaai/panda/pull/1533


Support redundant ESC outputs: CAN and PWM

We want to use the new KDE-UAS85UVC over DroneCAN, with PWM signals as redundancy.
In order to achieve this, we need the CubeOrange to output DroneCAN messages and PWM signals on the MAIN output pins at the same time. There is no built-in parameter or mechanism to do this. Instead, we map the mixer to both the logical MAIN and logial AUX output.
If the FC is set to output MAIN over DroneCAN instead of the physical MAIN pins, this PR makes the FC remap the logical AUX to the physical MAIN pins. This means we get both DroneCAN and PWM outputs at the same time.
This has been tested on a CubeOrange and KDE-UAS85UVC ESC. A scope has been used to verify pwm outputs on all pins.

The previous soulution did not work reliably. When testing with all motors and actuators on NX1, I had several weird issues. For example, output depended on PWM_AUX_X parameters, which were not marked as "used" and thus did not show up in QGC or were affected by parameter resets.
Now, after a better understanding of the mixer and init file, I instead load the mixer file directly to /dev/pwm_output0 in addition to /dev/uavcan/esc when UAVCAN actuators are enabled. Table-testing this on NX-01, it worked well for motors and actuators, over both CAN and PWM.

This fix is not required, as simply using the new control allocation system will allow us to output both pwm and dronecan. Closing PR.

This fix is not required, as simply using the new control allocation system will allow us to output both pwm and dronecan. Closing PR.


support to svg

Is there support for svg images?

https://github.com/nvim-telescope/telescope-media-files.nvim/pull/35 adds SVG support out of the box now


[styled-engine-sc] Fix missing @types/hoist-non-react-statics causing styled returns any

[x] I have followed (at least) the PR section of the contributing guide.

I moved @types/hoist-non-react-statics from devDependencies to dependencies.
The type definitions for styled-engine-sc depend on hoist-non-react-statics.
https://github.com/mui/material-ui/blob/47326108836da30c36b6b63bf6413f936a1e71fb/packages/mui-styled-engine-sc/src/index.d.ts#L3
The @types/hoist-non-react-statics is not included in the dependencies, if this type definition is not installed, styled would return any.

I tried this in Material UI + CRA + styled-components (TypeScript) repository.

Of course, I resolved the merge conflicts. Thanks for the review!

For some reason the CI is stuck on this PR. I can't trigger it, I will open a new PR with the change. Sorry about the delay.

Would you like me to re-create a PR?

We can try that too, please ask me for a review.

Thanks. I re-created the PR in #44397.


Do not disable lifecycle identity for this repo

Creates confusing behavior.

Let's get this merged soon, please, @degrammer.


Support a wider variety of validation options

We may want different options here.

Lazy (based on dtype).
Exhaustive (checks every row, currently this is what is implemented).
First N rows check.
1-to-1 (columns and the model must match exactly).
Inclusive (there can be many extra columns as long as the model schema is met, this is what is implemented).

I am going to think a bit more on how to have these options without bloating up functions.

@wesselhuising so this is all that remains on the roadmap once PR #32 goes thru!
I don't think we should over-complicate it, here is my updated ideas (let me know you thoughts or what you may want to tackle):

On second thought we should drop the "lazy" option I mentioned above, as pandas assumptions of dtype could mess that all up.
We can add a check_n_rows: int argument and leave "exhaustive" as the default. This would only apply to .validate() since the filter functionality by definition touches every row.
We can have an argument like strict: bool that represents the "1-to-1" vs exclusive logic.

Since that leaves two features/args to add. How about we split it up, or one of us just does both? Let me know what you think or if you feel like we should add anything else useful.

@xaviernogueira
For the second bullet item (check_n_rows argument) I would argue to leave this to the user as I would prefer them to use dataframe slicing in this case (as you would normally do with dataframes). I might be missing an use-case here in cases it is not possible to validate dataframes using [:x] or head or tail.
Agree with the strict option.
Waiting for your thoughts on the check_n_rows before we divide the work here.

Great!  Otherwise I will pick this up later in the week.

@wesselhuising I'm at my companies on site hackathon this week so I won't be able to get to it until later.
Feel free to get started, if you haven't made progress in a week or two I'll go for it

@xaviernogueira wrote the implementation and tests. Please review!

@wesselhuising amazing! Thanks for that reviewing now

@wesselhuising this has been addressed with PR #33. Just to explicitly address the other mentioned options:

Lazy (based on dtype).
Exhaustive (checks every row) -> currently this is what is implemented.
First N rows check. -> the user can just pass in df.head(n=100), no need to provide this explicitly.
1-to-1 (columns and the model must match exactly) -> strict==True.
Inclusive (there can be many extra columns as long as the model schema is met, this is what is implemented). -> this is actually the default with pydantic.

Note that one can set model config "extra" in the pydantic.BaseModel which controls some of the nuance here as well. I wanted to use this pattern to control the behavior, but annoyingly one can only set the settings when defining the class since it compiles to Rust under the hood.
So for now, a simple strict mode appears to be the right choice on our side. Maybe if pydantic allows re-compilation in an easy API we can tack that on as well. But adding fancy pydantic class construction logic is a bit out of scope here, when it is far easier for the user to just define their classes appropriately.


Something very weird

Please verify that you have read and understood the guidelines.
yes
A clear and concise description of the issue.
I tried to update prowlarr and radarr but i was getting error "There is currently no update path available."
So i checked inside the opt/Radarr and the dir is full of .dll files!
For example
BouncyCastle.Crypto.dll                               Microsoft.AspNetCore.Hosting.Server.Abstractions.dll       Microsoft.Extensions.Configuration.Binder.dll                   NLog.Targets.Syslog.dll                    System.ComponentModel.dll                       System.Net.Security.dll                                System.Security.dll Dapper.dll                                            Microsoft.AspNetCore.Hosting.dll                           Microsoft.Extensions.Configuration.CommandLine.dll              NLog.dll                                   System.Configuration.ConfigurationManager.dll   System.Net.ServicePoint.dll                            System.ServiceModel.Web.dll Diacritical.dll                                       Microsoft.AspNetCore.Html.Abstractions.dll                 Microsoft.Extensions.Configuration.EnvironmentVariables.dll     Newtonsoft.Json.dll                        System.Configuration.dll                        System.Net.Sockets.dll                                 System.ServiceProcess.ServiceController.dll DryIoc.Microsoft.DependencyInjection.dll
But the service is working normally, i can use radarr and prowlarr.
Is this any kind of hidden crypto miner?
My use my services over VPN.
What settings are you currently utilizing?

[X] Default Settings
[ ] Advanced Settings

Which Linux distribution are you employing?
Debian 12
If relevant, including screenshots or a code block can be helpful in clarifying the issue.
No response
Please provide detailed steps to reproduce the issue.
No response

If you look at the install file of this:
https://prowlarr.servarr.com/v1/update/master/updatefile?os=linux&runtime=netcore&arch=x64
There are some .dlls inside.
I think they either didn't clean up the packages or they built one AIO package for all distributions

Ok then maybe there is something wrong with the script?
Because im getting  ✗ There is currently no update path available.
and the /var/lib/radarr exists.
function update_script() { header_info check_container_storage check_container_resources if [[ ! -d /var/lib/radarr/ ]]; then msg_error "No ${APP} Installation Found!"; exit; fi msg_error "There is currently no update path available." exit }


Cannot read properties of undefined (reading 'title')

Hi Team,
I had installed the package globally on my Windows PC. Installation was done but when I tried to download the file, I got the below error as shown in the screenshot. Can anybody help me with this?

Hello.
Sorry for the error you facing.
I will be uploading a better version of the package 📦 in near future.
Please don't use this package for now.
On Wed, 27 Dec, 2023, 9:30 am Karunakar Patel, @.***>
wrote:

Hi Team,
I had installed the package globally on my Windows PC. Installation was
done but when I tried to download the file, I got the below error as shown
in the screenshot. Can anybody help me with this?
image.png (view on web)
https://github.com/magneum/youtube-exec/assets/39786770/9b845fd2-a541-4f4f-a64e-5b9c6840ac62
—
Reply to this email directly, view it on GitHub
https://github.com/magneum/youtube-exec/issues/8, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUX6KGSLYBNFC6FN325XN7TYLOMMXAVCNFSM6AAAAABBD4MB2KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TMOBYGM4DMOA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


[Bug]: [Fixed layout] Large scroll seen below Modal widget in older apps and templates

Is there an existing issue for this?

[X] I have searched the existing issues

Description
When we select Modal widget, we see a large scroll below the Modal widget
https://user-images.githubusercontent.com/104895602/213398307-a6c9ea85-acde-40ed-8fc0-dd9af7b45eea.mp4
Steps To Reproduce

Select Modal widget from any older app / Templates
Scroll to see a large blank space below the Modal widget

Public Sample App
No response
Issue video log
No response
Version
Deploy preview

As per the last discussion, moving it to in progress.

This is observed in production too. We are already tracking this in #19657
Once it is fixed, we will revisit this issue.

Working fine, moving to done.


Enable ONNX Test for FasterRcnn

Faster Rcnn should now be exportable to ONNX.
The PyTorch version should include commit ebc216a0765d85f345f9a5cd1dfd2ec360de3a52 (any nightly version after Nov 5th).
Opset 11 is the minimum ONNX version supported.
Only a batch size of 1 with fixed image size is supported.
The test test_faster_rcnn() in test_onnx.py has an example of exporting the model;
1 - create an input of valid size to export the model.
2 - run the model with the input then export it by calling torch.onnx.export() with the model and input.
(3- you can optionally test/run the model with ONNX Runtime like in ort_validate().)

thanks @fmassa, I am trying with smaller image sizes now.

Codecov Report

Merging #1555 into master will decrease coverage by 1.31%.
The diff coverage is 80%.

@@            Coverage Diff             @@
##           master    #1555      +/-   ##
==========================================
- Coverage   65.48%   64.16%   -1.32%
==========================================
  Files          90       90
  Lines        7080     7076       -4
  Branches     1077      973     -104
==========================================
- Hits         4636     4540      -96
- Misses       2135     2202      +67
- Partials      309      334      +25

Impacted Files
Coverage Δ

torchvision/models/detection/transform.py
68.8% <0%> (+1.87%)
:arrow_up:

torchvision/ops/_register_onnx_ops.py
54.16% <100%> (-45.84%)
:arrow_down:

torchvision/ops/poolers.py
80.72% <0%> (-15.67%)
:arrow_down:

torchvision/models/detection/rpn.py
75.22% <0%> (-7.21%)
:arrow_down:

torchvision/datasets/cifar.py
71.26% <0%> (-6.9%)
:arrow_down:

torchvision/ops/boxes.py
94.44% <0%> (-5.56%)
:arrow_down:

torchvision/models/detection/roi_heads.py
49.51% <0%> (-5.13%)
:arrow_down:

torchvision/datasets/lsun.py
20.4% <0%> (-4.09%)
:arrow_down:

torchvision/datasets/utils.py
54.6% <0%> (-3.07%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8909ff4...067c2c9. Read the comment docs.

Hi, I've been trying to convert a re-trained model that is based on this model and I'm still not getting a model I've been able to use, but I came across this thread yesterday.
With the fixed input size, and being limited to 300x300, does that mean inference will be limited to images with that size?  That won't do too much good for detection :(

@Ed-Roodzant the input size is set to 300x300 in the tests to make them run faster on the CI. You can export the model with an input of a bigger size, and  inference would use that size.


No text visible

I tried to use this library!
(implementation 'yogesh.firzen:FilesLister:2.0.12')
Everything seems to work but the file, folder text. See the screenshot.

i sent a pull request to fix them. :)

@makechio Look like the developer isn't available. Is there any way to update the code myself on the project? Or, is there any library similar to this one? Thank you.

Hi @jamilxt , you can take a fork of the project and them do a pull request


setindex! not defined for np arrays of non-conventional (isbits) types

Minimum example (using ipython3).
I have a list of tuples Tuple{Int,Int,Float64}, and I can copy the values from the julia array to a np.array of the same type on the python side, but I can't perform this copy of elements on the Julia side, because setindex! is not defined.
Would it be possible to support any isbits type?
In [6]: from juliacall import Main as jl

In [7]: jl.seval("""
   ...: function copy_value(python_list, julia_list)
   ...:     python_list[1] = julia_list[1]
   ...: end
   ...: """)
Out[7]: copy_value (generic function with 1 method)

In [8]: import numpy as np

In [9]: python_list = np.array([(0,0.0)], dtype='i,f')

In [10]: julia_list = jl.seval("[(0,0.0)]")

In [11]: python_list[0] = julia_list[0] # works!

In [12]: jl.copy_value(python_list, julia_list)
---------------------------------------------------------------------------
JuliaError                                Traceback (most recent call last)
<ipython-input-12-e89b29633981> in <module>
----> 1 jl.copy_value(python_list, julia_list)

~/.local/lib/python3.10/site-packages/juliacall/__init__.py in __call__(self, *args, **kwargs)
    199             return ValueBase.__dir__(self) + self._jl_callmethod($(pyjl_methodnum(pyjlany_dir)))
    200         def __call__(self, *args, **kwargs):
--> 201             return self._jl_callmethod($(pyjl_methodnum(pyjlany_call)), args, kwargs)
    202         def __len__(self):
    203             return self._jl_callmethod($(pyjl_methodnum(pyjlany_op(length))))

JuliaError: MethodError: no method matching setindex!(::PythonCall.PyIterable{PythonCall.Py}, ::Tuple{Int64, Float64}, ::Int64)
Stacktrace:
 [1] copy_value(python_list::PythonCall.PyIterable{PythonCall.Py}, julia_list::Vector{Tuple{Int64, Float64}})
   @ Main ./none:3
 [2] pyjlany_call(self::typeof(copy_value), args_::PythonCall.Py, kwargs_::PythonCall.Py)
   @ PythonCall ~/.julia/packages/PythonCall/2Y5CR/src/jlwrap/any.jl:31
 [3] _pyjl_callmethod(f::Any, self_::Ptr{PythonCall.C.PyObject}, args_::Ptr{PythonCall.C.PyObject}, nargs::Int64)
   @ PythonCall ~/.julia/packages/PythonCall/2Y5CR/src/jlwrap/base.jl:69
 [4] _pyjl_callmethod(o::Ptr{PythonCall.C.PyObject}, args::Ptr{PythonCall.C.PyObject})
   @ PythonCall.C ~/.julia/packages/PythonCall/2Y5CR/src/cpython/jlwrap.jl:47

Indeed, you can see from the error message that the python_list has been converted to a PyIterable which is the fallback if conversion to PyArray fails. And generic iterables do not  support setindex!.
It should indeed be possible to support nested types, but it's fiddly to do in general (e.g. numpy dtypes can use packed or aligned memory layout) so I haven't got around to it yet.

You can now convert numpy arrays with structured dtypes like this to PyArray (provided the dtype is aligned). This means your code now works:
In [1]: from juliacall import Main as jl

In [2]: jl.seval("""
   ...: function copy_value(python_list, julia_list)
   ...:   @show python_list julia_list
   ...:   python_list[1] = julia_list[1]
   ...: end
   ...: """)
Out[2]: copy_value (generic function with 1 method)

In [3]: import numpy as np

In [4]: python_list = np.array([(0,0.0)], dtype="i,f")

In [5]: julia_list = jl.seval("[(0,0.0)]")

In [6]: python_list[0] = julia_list[0]

In [7]: jl.copy_value(python_list, julia_list)
python_list = Tuple{Int32, Float32}[(0, 0.0)]
julia_list = [(0, 0.0)]
Out[7]: (0, 0.0)

In [8]: python_list
Out[8]: array([(0, 0.)], dtype=[('f0', '<i4'), ('f1', '<f4')])

In [9]: python_list[0] = (1,1.1)

In [10]: python_list
Out[10]: array([(1, 1.1)], dtype=[('f0', '<i4'), ('f1', '<f4')])

In [11]: jl.copy_value(python_list, julia_list)
python_list = Tuple{Int32, Float32}[(1, 1.1)]
julia_list = [(0, 0.0)]
Out[11]: (0, 0.0)

In [12]: python_list
Out[12]: array([(0, 0.)], dtype=[('f0', '<i4'), ('f1', '<f4')])

Assuming tests pass, I'll make a release today.


0.34.5 is not found on npmjs.org

It's on the github release page though.

Dupe of #71

This can be closed now.


sqlite InterfaceError

Trying to run mlcomp dag and getting this errorL
Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1248, in _execute_context
    cursor, statement, parameters, context
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/default.py", line 590, in do_execute
    cursor.execute(statement, parameters)
sqlite3.InterfaceError: Error binding parameter 2 - probably unsupported type.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/opt/conda/bin/mlcomp", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/conda/lib/python3.7/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/__main__.py", line 87, in dag
    _dag(config, control_reqs=control_reqs, params=params)
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/__main__.py", line 50, in _dag
    control_reqs=control_reqs
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/server/back/create_dags/standard.py", line 273, in dag_standard
    return builder.build()
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/server/back/create_dags/standard.py", line 244, in build
    self.upload()
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/server/back/create_dags/standard.py", line 116, in upload
    control_reqs=self.control_reqs)
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/worker/storage.py", line 120, in upload
    self.file_provider.add(file)
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/db/providers/base.py", line 50, in add
    self._session.add(obj, commit=commit)
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/db/core/db.py", line 99, in add
    raise e
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/db/core/db.py", line 96, in add
    self.commit()
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/db/core/db.py", line 107, in commit
    raise e
  File "/opt/conda/lib/python3.7/site-packages/mlcomp/db/core/db.py", line 104, in commit
    super().commit()
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 1036, in commit
    self.transaction.commit()
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 503, in commit
    self._prepare_impl()
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 482, in _prepare_impl
    self.session.flush()
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 2496, in flush
    self._flush(objects)
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 2637, in _flush
    transaction.rollback(_capture_exception=True)
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/util/langhelpers.py", line 69, in __exit__
    exc_value, with_traceback=exc_tb,
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/util/compat.py", line 178, in raise_
    raise exception
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 2597, in _flush
    flush_context.execute()
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/unitofwork.py", line 422, in execute
    rec.execute(self)
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/unitofwork.py", line 589, in execute
    uow,
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/persistence.py", line 245, in save_obj
    insert,
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/orm/persistence.py", line 1136, in _emit_insert_statements
    statement, params
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 984, in execute
    return meth(self, multiparams, params)
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/sql/elements.py", line 293, in _execute_on_connection
    return connection._execute_clauseelement(self, multiparams, params)
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1103, in _execute_clauseelement
    distilled_params,
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1288, in _execute_context
    e, statement, parameters, cursor, context
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1482, in _handle_dbapi_exception
    sqlalchemy_exception, with_traceback=exc_info[2], from_=e
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/util/compat.py", line 178, in raise_
    raise exception
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1248, in _execute_context
    cursor, statement, parameters, context
  File "/opt/conda/lib/python3.7/site-packages/sqlalchemy/engine/default.py", line 590, in do_execute
    cursor.execute(statement, parameters)
sqlalchemy.exc.InterfaceError: (sqlite3.InterfaceError) Error binding parameter 2 - probably unsupported type.
[SQL: INSERT INTO file (md5, created, content, project, dag, size) VALUES (?, ?, ?, ?, ?, ?)]
[parameters: ('2a56845cd8f723587ab2b10cf84107c4', '2020-10-05 05:55:37.139080', <memory at 0x7f8fafdd4940>, 1, 1,<PHONE_NUMBER>)]
(Background on this error at: http://sqlalche.me/e/rvf5)

Most probably could be an error in my configuration, but not 100 percent sure.

So sorry - turns out it was indeed an error in my configuration files.


Implement AWS key value store

Hi folks! I am creating this draft PR to solicit feedback on an initial AWS key value store implementation. I appreciate any and all discussions on this PR!
Some points for thought:

Implementation uses DynamoDB, though for large blob storage, S3 is preferable (DynamoDB can only store <=400KB size records), see https://github.com/fermyon/spin/issues/2606. DynamoDB is cheaper and faster for performing many rapid reads/writes of small amounts of data though, and is roughly in the same niche as Azure CosmosDB
Auth currently requires generating AWS STS token credentials and passing them to the Spin app in a runtime config file. https://github.com/spinkube/skips/pull/9/files discusses better patterns to fetch credentials. Curious to hear thoughts on how this implementation can integrate better with that proposal!
The Azure key-value implementation supports reading credentials from environment variables, however the AWS Rust SDK does not offer a synchronous API to load config and would require the MakeKeyValueStore::make_store function to be async for all implementations -- leading to a chain of async function coloring. It is possible to manually fill the SdkConfig object and I did this to pass STS tokens from a runtime config file, but it would be ideal to rely on the SDK's defaults and many credential loading fallbacks if possible. Curious on thoughts for how to best handle env var credential loading

Kia ora @ogghead and thanks for this.  We've got work going on in https://github.com/fermyon/spin/pull/2895 to implement some additional key-value interfaces, and I think it works better to land that one first, then have this PR include all the AWS stuff.  This is partly down to what has the biggest compatibility implications combined with the present release timeline, but also will hopefully provide enough infrastructure to make extending this PR to the new interfaces easy!  I hope that's okay with you.
In the meantime, I'll try to have a look at your points for thought!

Implementation uses DynamoDB, though for large blob storage, S3 is preferable

I'd say this is fine for now.  We could call this a DynamoDB KV store, which would leave us flexibility to later to add a S3 KV backend if users had large object use cases - nothing here would preclude that as long as we think of it as an "AWS product X" store rather than an "AWS" store.

Auth currently requires generating AWS STS token credentials

I don't think we are bound to offer a "tokens in the runtime config" option if that doesn't make sense or is painful to implement.  I'm not sure we can rely on the workload identity idea from that SKIP across all Spin runtime environments, but absolutely open to doing things differently as appropriate.

it would be ideal to rely on the SDK's defaults and many credential loading fallbacks if possible

This is what we do in the SQS trigger.  There's no credential configuration, we just load the SDK and let figure out the credentials, whether from ambient EVs or whatever.  I'm told that's idiomatic enough, so I'd have no problem with doing the same thing here.  I'm sure someone will shout out if they do - but we could presumably retrofit additional configuration methods if need be - the Cosmos one certainly went through a few sets of extensions...

Kia ora @ogghead and thanks for this.  We've got work going on in https://github.com/fermyon/spin/pull/2895 to implement some additional key-value interfaces, and I think it works better to land that one first, then have this PR include all the AWS stuff.  This is partly down to what has the biggest compatibility implications combined with the present release timeline, but also will hopefully provide enough infrastructure to make extending this PR to the new interfaces easy!  I hope that's okay with you.
In the meantime, I'll try to have a look at your points for thought!

Sounds good to me! I'm excited to see that work land. It makes sense to hold off on this for now, then rework after that is merged and support all WASI KV interfaces for AWS.
Thanks for taking a look!

Implementation uses DynamoDB, though for large blob storage, S3 is preferable

I'd say this is fine for now.  We could call this a DynamoDB KV store, which would leave us flexibility to later to add a S3 KV backend if users had large object use cases - nothing here would preclude that as long as we think of it as an "AWS product X" store rather than an "AWS" store.

Great callout! The config specifies "Dynamo" as the KV store type, so should hopefully be flexible to add other backends. I will keep this in mind when implementing the full WASI KV interface

Auth currently requires generating AWS STS token credentials

I don't think we are bound to offer a "tokens in the runtime config" option if that doesn't make sense or is painful to implement.  I'm not sure we can rely on the workload identity idea from that SKIP across all Spin runtime environments, but absolutely open to doing things differently as appropriate.

The runtime config token setup is (from local testing) working -- but the "use the default SDK config loading" is proving challenging with the current interface constraints. Mainly as the default AWS config loader is implemented as an async function.

it would be ideal to rely on the SDK's defaults and many credential loading fallbacks if possible

This is what we do in the SQS trigger.  There's no credential configuration, we just load the SDK and let figure out the credentials, whether from ambient EVs or whatever.  I'm told that's idiomatic enough, so I'd have no problem with doing the same thing here.  I'm sure someone will shout out if they do - but we could presumably retrofit additional configuration methods if need be - the Cosmos one certainly went through a few sets of extensions...

Agreed, this is the pattern I followed in the Kinesis trigger as well. I would love to have this here too! The challenge is function coloring from AWS config default loader function -- using that async function here appeared to require a chain of refactoring across the general KV traits, but I must admit that my async Rust knowledge hit a wall when trying to reconcile the changes required for that.

Ah, I misread your comment about using the default SDK config - sorry about that.
It seems like you could call Tokio's block_on to wrap the async call in a blocking wrapper.  It's not going to win any prizes for elegance but should, hopefully, get the job done.  The section "A synchronous interface to mini-redis" on the Tokio "Bridging to sync code" page seems like it might be close to what you want, although you may well have tried that already?  We do have some Giant Async Brains floating around who might be able to help if you share what you tried and what you ran into.

Ah, I misread your comment about using the default SDK config - sorry about that.
It seems like you could call Tokio's block_on to wrap the async call in a blocking wrapper. It's not going to win any prizes for elegance but should, hopefully, get the job done. The section "A synchronous interface to mini-redis" on the Tokio "Bridging to sync code" page seems like it might be close to what you want, although you may well have tried that already? We do have some Giant Async Brains floating around who might be able to help if you share what you tried and what you ran into.

Good callout -- I tried using block_on to get this working with
Handle::current().block_on(aws_config::load_defaults(BehaviorVersion::latest()))

as well as
let rt = tokio::runtime::Builder::new_current_thread()
                    .enable_all()
                    .build()?;
 rt.block_on(aws_config::load_defaults(BehaviorVersion::latest()))

While these do compile, I see crashes immediately on Spin app startup with
Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.

Alternatively, when I went down the path of asyncifying everything required to await this function, I hit a wall at store_from_toml_fn where closures are returned. Async closure enhancements in Rust might be needed to make the closures returned there async, but this is where my knowledge of async Rust was lacking.
If any Giant Async Brains (or anyone) have ideas on the best path forward on this, much appreciated!

All right.  I think I have a way around this for you.  "But," in the words of Deep Thought, "you're not going to like it."
So I asked the Giant Async Brains about blocking on load_defaults and they said "don't do that."  Instead the idea is to create a future for the Client and capture that in a lazy or once-cell instead.  Then await it each time you want to use it (which will be cheap after the first time, especially compared to the network activity that follows).
Here is what I did, which seems to work (but you may find a less awful way, this was just the first stab that didn't make the compiler mad at me):

Add the async-once-cell crate
Change KeyValueAwsDynamo::client to be a (deep breath) async_once_cell::Lazy<Client, std::pin::Pin<Box<dyn std::future::Future<Output = Client> + Send>>>
In KeyValueAwsDynamo::new, shunt the existing code into an async move.  Then Box::pin the async move.  And capture that as a future.  Then put that into a Lazy::from_future.  So it looks like:

        let client_fut: std::pin::Pin<Box<dyn std::future::Future<Output = Client> + Send>> = Box::pin(async move {
            let config = match auth_options {
                KeyValueAwsDynamoAuthOptions::RuntimeConfigValues(config) => /* as current */,
                KeyValueAwsDynamoAuthOptions::Environmental => {
                    aws_config::load_defaults(BehaviorVersion::latest()).await  // as before but uncommented
                }
            };
            Client::new(&config)
        });

        let client_cell = async_once_cell::Lazy::from_future(client_fut);

        Ok(Self { client: client_cell, table })

(Some of the naming here is poor, this was throwaway code.)

Change StoreManager::get to get_unpin().await the Lazy:

    async fn get(&self, name: &str) -> Result<Arc<dyn Store>, Error> {
        Ok(Arc::new(AwsDynamoStore {
            _name: name.to_owned(),
            client: self.client.get_unpin().await.clone(),  // <-- this bit
            table: self.table.clone(),
        }))
    }

NOTE: this breaks StoreManager::summary.  You'll need to either make that async or capture the summary info as extra fields, but this should be routine.  (I hope.  I admit punting on this.)
Let me know if you need more info or want a proper diff.

Excellent! This is exactly the Galaxy Async Brain thinking I was sorely lacking 😄
I will give this a go tonight, thanks for the tips!

Can confirm this worked like a charm! Pushed the changes to reflect and I will keep an eye on the full WASI KV implementation PR. I am in your debt for your help on this @itowlson :)
One does not simply walk into async_once_cell::Lazy<Client, std::pin::Pin<Box<dyn std::future::Future<Output = Client> + Send>>> (or Mordor)

I'm delighted to have helped!  Thanks once again for your effort, your patience, and your good humour throughout this...
...
...because you will need them when I call that debt in.  ominous music and cheesy lightning FX in which the viewer can vaguely make out the looming shape of wasi:blobstore
(also, and at the risk of bathos, please ignore MQTT CI failures - it's a known flake)

I have implemented atomic and batch operations -- the logic is tentatively all in place. I will test the operations with a component using WASI-KV and then (barring any uncovered issues) mark this ready for review

Dynamo uses eventually consistent reads by default - which is fine for applications written against Dynamo, but I believe our Spin KV contract is that you at least read-your-writes. Dynamo charging 2x the cost for a Consistent Read makes this a compelling tradeoff regardless, but we may need to document that fact (and potentially make ConsistentReads an opt-in configuration?)
Otherwise this seems reasonably sound to me (modulo questions about CAS) - thanks for the PR!

Good point! I was mulling over whether to add a configuration to specify strongly consistent reads, and this comment makes it clear that would be good to have (and potentially default to strongly consistent to maintain consistency of behavior with other implementations?) It should be quick to add, will push that up either this morning or tonight

Ok! I may have gotten a bit pedantic with the states for Cas but this is hopefully in line with what you were imagining @endocrimes and cleans up. That said, I uncovered some odd behavior while testing and published an "int test Spin app" repo here for reference

For AWS, I observed panics here

Caused by:
    0: error while executing at wasm backtrace:
           0: 0x4812a -<EMAIL_ADDRESS>           1: 0xf034 - test_dynamo.wasm!spin_sdk::wit::wasi::keyvalue::atomics::swap::hfb1256b17b155b22
           2: 0x64fc - test_dynamo.wasm!test_dynamo::handle_test_dynamo::hb0dc3a6709598c91
           3: 0x77ba - test_dynamo.wasm!spin_executor::run::h6238cdfeaf27259c
           4: 0x954c -<EMAIL_ADDRESS>    1: CasError::CasFailed(Resource { rep: 4, state: "own (not in table)" })

For sanity, I tested with sqlite to see the "reference behavior" but there I hit panics here

Caused by:
    0: error while executing at wasm backtrace:
           0: 0x1bd0e - test_dynamo.wasm!__rust_start_panic
           1: 0x1bba7 - test_dynamo.wasm!rust_panic
           2: 0x1bad5 - test_dynamo.wasm!std::panicking::rust_panic_with_hook::h6e665b71c8f50b27
           3: 0x1ac0f - test_dynamo.wasm!std::panicking::begin_panic_handler::{{closure}}::hb63ceb92de73cef0
           4: 0x1ab75 - test_dynamo.wasm!std::sys::backtrace::__rust_end_short_backtrace::hf18948010daec5d9
           5: 0x1b3b1 - test_dynamo.wasm!rust_begin_unwind
           6: 0x299bf - test_dynamo.wasm!core::panicking::panic_fmt::h7916dc01f99baff2
           7: 0x2b1cd - test_dynamo.wasm!core::panicking::assert_failed_inner::h636831bd2590e950
           8: 0x3538 - test_dynamo.wasm!core::panicking::assert_failed::h4b4824a9d77e94de
           9: 0x51e8 - test_dynamo.wasm!test_dynamo::handle_test_dynamo::hb0dc3a6709598c91
          10: 0x77ba - test_dynamo.wasm!spin_executor::run::h6238cdfeaf27259c
          11: 0x954c -<EMAIL_ADDRESS>    1: wasm trap: wasm `unreachable` instruction executed

It is certainly possible that these issues are caused by my own environment but the AWS one appears to potentially be rooted in higher level orchestration logic around atomic retries here

cc @devigned for the possible issue in the SQLite (or host?) implementation (#2883 (comment))

I'm at KubeCon right now, but I will try to give it a look when I have a break. At first glance, it seems like the CAS resource is not registered in the CAS resource table. The test code looked correct to me, so this is likely a bug in the CAS implementation.

I appreciate the quick responses! On lunch so pushed up a few fixes for latest comments. I did some additional testing and the issue on sqlite get_many does appear to be inconsistent and I can reproduce with AWS too -- I have a hunch that caching of deleted values could be involved as adding sleeps in between delete_many and get_many operations allows consistent passes of that test for sqlite.
I did end up adding one fallback in the sqlite implementation in swap for null old_value as I was seeing an edge case crash here, please let me know if the modified behavior isn't desirable! With this change in place, I can confirm that both sqlite and AWS crash at the same place -- though I have yet to trace why the error including the new CAS isn't being returned user-side and instead logs/crashes somewhere


Added dev, staging, prod namespace for app deployment

Not the cleanest implementation but it works for the demo.

@jknight-liatrio Is this PR superseded by https://github.com/rode/demo/pull/30?