No clear way to disambiguate data from multiple Green Beans (and their associated appliances) attached to the same host via USB

[rudybrian]

Hi folks,

I originally posed this question on the 1B forums, but @MylesCaley recommended that I open an issue here as well.

I recently started doing some testing with my laundry pair and discovered an oddity with how the gea-sdk handles more than one Green Bean (and it's associated appliance) attached to my development machine. For example, if I call appliance.modelNumber.read() it will fire once for each connected appliance. This also seems to happen for the subscribe() function. Since there is no clear source to what GB/appliance is responding to the read() and subscribe() functions it can lead to confusion in handling the results.

Per @MylesCaley's suggestion, I tried defining different addresses for two sample applications (0xE5 for the dryer and 0xE4 for the washing machine), but this seems to have no bearing on the behavior. The first script to run appears to claim all the USB-attached Green Beans, resulting in a USB read error when the next script is started. I have posted full details of the scripts and the output to Gist here.

[rudybrian]

I looked at this a bit more, and it appears to be unrelated to the gea-sdk itself and is more how green-bean instantiates adapters via gea-adapter-usb. On instantiation, gea-adapter-usb fires a callback for each node-hid device with VENDOR_ID = 1240 and PRODUCT_ID = 64752 (all green beans attached to the host via USB). green-bean doesn't handle this well as it assumes it will only fire app.bind() once. If there is more than one device attached, it will fire as many times as there are devices and bind all adapters to itself. This explains both the duplicate results with two adapters attached, and why a second app instance fails to claim any adapters.

[MylesCaley]

@rudybrian thanks for digging into this. If you want to put a fix and pull request in then I will merge it.

[rudybrian]

Thanks @MylesCaley,

I am fairly new to JS/Node so I may not have the full picture, but it seems to me that this could be done in a couple different ways:

• Re-work how gea-adapter-usb iterates through the devices array. This would only allow one device to be claimed per green-bean instance.
  • This would require running multiple different Node apps (one per connected appliance)
  • There is no guarantee that the device will be numbered the same each time (e.g. reboot/USB disconnect-reconnect) which will make it tricky to associate an app with a specific appliance
• Add a property to the Adapter class that identifies each instance.
  • This would only work for combinations of appliances that can use a common address in gea.configure() unless the green-bean's connect() function can be re-worked to allow setting the address on instantiation via a user-defined parameter.
  • This is still somewhat of a chicken and egg situation as there isn't an implicit method to preemptively determine what device/appliance we want to bind to in order to set the address on the appropriate device.
• Specify filter criteria on the Adapter bind() function so we only get a limited set of appliances that match what we want to use in our Node app (e.g. Clothes dryer/Clothes washer or a serial number)
  • If we specify an applianceType filter, it might help to get only a specific type of device, but due to appliance.applianceType.read() not working gea-sdk#4, this isn't currently possible.
  • Alternatively, if we specify a serialNumber to hid.devices in gea-adapter-usb it would target a specific green bean board and it's associated appliance (but this requires the USB serial number property to be uniquely assigned on the green bean boards which I will need to confirm when I get things wired back up)

[rudybrian]

Unfortunately it looks like the firmware on the green beans do not populate the serial number (iSerial) so that option is out:

Bus 001 Device 030: ID 04d8:fcf0 Microchip Technology, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x04d8 Microchip Technology, Inc.
  idProduct          0xfcf0 
  bcdDevice            0.02
  iManufacturer           1 GEConsumer&Industrial.
  iProduct                2 GEC&I DR Unit Gen2
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      29
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0001
  Self Powered

[rudybrian]

I gave this some more thought, and I believe I am missing a dimension. Since we have learned that the GEA bus is actually a 1-wire bus, it should (in theory) be possible to have multiple appliances in close physical proximity daisy-chained together and tied to a host machine via a single green bean. This will require both iterating through the USB-attached green beans and through each of the detected appliances. Unfortunately the current version of gea-adapter-usb doesn't appear to be structured to allow for multiple appliances per Adapter.

Thanks to @MylesCaley's revelation that my washing machine needed to use a specific address (0xE4) or it wouldn't respond to most read()/subscribe() requests, I noticed that only the appliance info (modelNumber,serialNumber, but not modelType due to GEMakers/gea-sdk#4) all seemed to be read()able with the default address of 0x1B. If I set the default address to 0xE4 in the green-bean node module for my dryer I can create a similar condition where only the appliance info is read()able. This suggests that the appliance info will be queriable regardless of the address used. That said, an option that comes to mind to address the multiple adapter issue is something like an app broker to initially bind to each adapter, discover the attached appliances and then based on the appliance serial number, re-run gea.configure() to change to the appropriate address and launch the configured application (each appliance would need an associated node app to run)

[rbultman]

@rudybrian Because of the way in which the appliance 1-wire serial bus works, you need to have one GreenBean per appliance.