If you don't use arbitrary virtual devices imported from MQTT into HE, and that's most people, you don't need to read this !
Virtual Device and JSON changes in beta3:
Virtual devices are created and handled differently in beta3. These are arbitrary topics/payloads on MQTT that you'd like to create a 'virtual' device for in HE.
NB: These MQTT topics must not be within a homie/.. or homeassistant statestream topic tree and must be created via page two ' Virtual MQTT Devices and Data' of this app and not directly within HE.
This second page is a bit quirky still but getting better 
. Double check the updates you make in the device's data itself. Currently (and changed from previous behaviour) any field updated will cause you to have to re-select the device. I will look to revert this later.
You must create a virtual device here (select the device type at the top and then ensure all devices in the bottom 'edit this device' are deselected) then choose a name, click outside of the field and click the 'create device' button. Then 'enable' the device in the middle drop down and select it below to edit.
Attribute Values
Gone are the _ON and _OFF values and instead the values for enumerated attributes are handled in one _MAP data value for each attribute.
Now in attribute_MAP 's you can enter values for each attribute this device has to map the values between a MQTT topic (payload) and the HE attribute value. Do double check them in the actual device and watch out for an already existing space in some fields (backspace it out). This is one of the 'quirks' to fix later.
Attribute _Topic and _Cmd
You include here the _Topic for an attribute which is the 'status' topic on MQTT that updates the matching attribute value in HE and the _Cmd value which is the topic payload that will be updated on MQTT whenever that attribute changes on HE. Either or both are optional. Often only _Topic is used , e.g. for sensors that can't be updated.
Attribute value mappings
HE expects predefined values for certain enumerated attributes , e.g. the switch attribute should be 'on' or 'off'. Your MQTT device might use different values or capitalisation and so you can 'map' any value between MQTT<>HE. To do this complete the _MAP data entry with your MQTT values positionally equivalent with the HE expected values that are shown e.g.
[Yes,No] to map to [on,off]
- capitalisation is important and make sure you complete all values and have no spaces. This mapping of values will be used both to update the attribute in HE and also when (if) sending a command back to MQTT.
JSON
The new version supports extraction of a single value from a JSON key. It does not (currently) support nested json. Additionally a json payload can be written back on update - with a single json key/value being returned.
Defining JSON keys:
When you define a _Topic to recover a payload as a value you can append {keyName:} to the end of the MQTT topic and that value will be used for the payload and attribute update.
e.g.
example/a/b contains payload
{"first": "one","second": "two"}
defining a _Topic of `example/a/b{second:}` returns value two
defining a _Topic of `example/a/b` returns value {"first": "one","second": "two"} or a two element map
the exact same for the _Cmd topic
'example/a/b{second:}'
when updated with value 'three'
would send a json payload with a single key value {"second": "three"}
I may support multi level nested json in the future.
This publishes all the capabilities and attributes for the selected devices to MQTT and is the way I expect most people will publish their devices.
