Hi @OlivierP,

Is there any chance you have changed the SSCP connection username and/or password? Aside from the message "capabilities parsing failed" you should see a message containing "wrong username or password?". If so then you can fix this by replacing the image with the stock one.

If this is not the case, then it would be helpful if you could provide us with some more information, specifically the IDE version, image name and version, and the response for the command "sudo cat /proc/cpuinfo"

Hi @JasperJackson!

There's a couple of ways of doing it, but any solution will probably look similar to yours. The issue is that the HMI does not have internal logic/state, but instead connects directly to the Mervis runtime. We are developing several other non-web HMI solutions, including a phone application and all-in-one industrial displays, which is the primary reason for this.

As such there unfortunately is not a better solution for now, but we'll try and see if we can provide similar functionality anyhow. It probably will not be any time soon though, most likely not in the next Mervis release, which is slated to be out in the next month.

There will however be a very large number of other improvements to the HMI system in the next months release, as it has been a major focus of Mervis development for the past 6 months.

We don't officially support using the touchscreen with the UniPi 1.1. I would try it first without the UniPi 1.1 board. If it works that way you may have a conflict on the I2C port, which the touchscreen uses.

There is a number of topics regarding the touchscreen I2C address conflicts on the official forums, which may be of further help.

This is a known recent issue which was fixed in a recent release. It was caused by the YAML parsing library we use being updated, which broke reading overlaid inputs/outputs in xS30 extension.

See https://github.com/UniPiTechnology/evok/commit/3c32d569282a6238998bac3b4d226b514fcd283e, as per the tag fixed in 2.0.5.

We don't have an upgrade procedure yet. We plan to move to using debian packages, which will make the problem a lot easier, but for now you should just use a clean system.

Installing EVOK twice on the same SD Card installation/image might break something, depending on various factors.

This should now also be fixed in the latest release (V2.0.5), at least in the sense that the filter command should also define the update set.

Hi @Raph7454,

Yes you will need to reinstall EVOK. Please use a clean Raspbian installation if possible, which is to say reinstall both EVOK and Raspbian.

EVOK makes a number of changes to Raspbian, and installing it twice on the same installation can potentially cause issues.

Kind Regards,
Tomas

Hi @Raph7454!

The 1Wire RPC interface isn't properly backported to the UniPi 1.1. That said I have now made the necessary changes to make it work. You will need to reinstall your image before the changes come up.

I hope this clears it up for you,

Kind Regards

Device types come from the following list (and otherwise correspond to the device path in the Rest API):

'relay',
'input',
'ai',
'ao',
'ee',
'sensor',
'i2cbus',
'adchip',
'owbus',
'mcp',
'gpiobus',
'pca9685',
'ds2408',
'unipi2',
'uart',
'neuron',
'board',
'misc_output',
'led',
'watchdog',
'register',
'wifi',
'light_channel',
'light_device'

and the "circuit" is the device name as specified in the configuration file.

As an example for UniPi 1.1:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:unip="http://192.168.1.146:8081/UniPiQueryService">
   <soapenv:Header/>
   <soapenv:Body>
      <unip1:SoapQueryInputList xmlns:unip1="http://127.0.1.1:8081/UniPiQueryService">
         <!--1 or more repetitions:-->
         <single_query>
            <device_circuit>1</device_circuit>
            <device_type>relay</device_type>
         </single_query>
      </unip1:SoapQueryInputList>
   </soapenv:Body>
</soapenv:Envelope>

An example for setting relays:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:unip="http://127.0.1.1:8081/UniPiCommandService">
   <soapenv:Header/>
   <soapenv:Body>
      <unip:SoapCommandInputList>
         <!--1 or more repetitions:-->
         <single_command>
            <device_circuit>1</device_circuit>
            <device_type>relay</device_type>
            <!--1 or more repetitions:-->
            <property_item>
               <property_name>value</property_name>
               <property_value>"0"</property_value>
            </property_item>
         </single_command>
         <single_command>
            <device_circuit>2</device_circuit>
            <device_type>relay</device_type>
            <!--1 or more repetitions:-->
            <property_item>
               <property_name>value</property_name>
               <property_value>"1"</property_value>
            </property_item>
         </single_command>
         <single_command>
            <device_circuit>3</device_circuit>
            <device_type>relay</device_type>
            <!--1 or more repetitions:-->
            <property_item>
               <property_name>value</property_name>
               <property_value>"1"</property_value>
            </property_item>
         </single_command>
      </unip:SoapCommandInputList>
   </soapenv:Body>
</soapenv:Envelope>

We'll try to provide the examples in the documentation in the next EVOK release.

Right - but does RX?

unipi_plc is only on the beta image, apologies

And I would try Mervis if possible. It has drivers done via a different library, and has better debugging facilities. Though if the RX light does not turn on Mervis won't be able to do much - it will just display constant timeouts.

e: More specifically no RX light means that there are no replies, TX light simply means that something is sent, regardless of whether the settings are correct or not.