Interface for FHEM

[ChrisPl-GH]

When is the interface for FHEM planned?
I have integrated the SHPI one into FHEM via MQTT and can use it to read the sensors and control the relays, but a GUI is of course the main reason for the SHPI. It is a great device, but the software and documentation is very thin. If you have to program every button or status display via Python first, it is too cumbersome for me. A simple web interface would make more sense.

[ChrisPl-GH]

As a customer I would have expected an answer to my question.
I am unsure whether I should really integrate SHPI into the house electrics if I cannot expect support in case of problems.

[paddywwoof]

@ChrisPl-GH sorry about the lack of any response. I'm a contractor doing occasional work on SHPI (mainly the pi3d graphics components) but I do know that a major re-write is underway which should make the whole thing more general and modular.

When you say web interface do you mean that the SHPI html server provides a back end for a web page running on your phone, or that the SHPI display would render a web page for accessing the functionality?

Finally, in answer to your question, I don't know I'm afraid. After a quick look at the FHEM website it's not at all clear what would be involved to interface shpi to FHEM server - presumably the specification is in there somewhere!

[ChrisPl-GH]

What was meant was a configurable web interface on the SHPI display, as interface to FHEM and other Smarthome servers MQTT would be good.
I have solved the problem for now for my purposes.
I deactivated the GUI in config.py, installed a desktop and used ssh via X-forwarding to get a browser window with FHEM dashboard from my server.
Unfortunately, Raspberry Zero is too slow for Chrome or Firefox, so the way via X-Forwarding.
The data comes from the SHPI via MQTT and is controlled via HTTP request.

[paddywwoof]

Hi, yes standard browsers carry an awful lot of overhead and aren't really geared up to use the GPU which is why Lutz has opted for the pi3d library as a compromise. How responsive is X-Forwarding? Not too critical for an essentially static display. I suppose a limitation is that there needs to be a server also running on the network. Hopefully the new shpi architecture will make it easier to set up things like this but short term it might be useful to have a slide with some pro-forma switches and sliders that can be easily copied and altered.

[ChrisPl-GH]

Firefox over X-forwarding works well. CPU and memory load are low and swap is not needed, which increases the durability of the sd card.
Yes, some simple examples with switches, sliders and status displays would help with the setup. But the speed when changing images via slide is not great even with pi3d.

[shpi]

Hello, Chris, could u call us next week? Then we can talk about in detail what u need and will implement in upcoming Main App :-)

[ChrisPl-GH]

I believe there are better contacts than me for an interface to FHEM in the FHEM Forum. Several users are interested in the SHPI or some of them already have a SHPI, but a simple interface is still missing.

See here:
https://forum.fhem.de/index.php/topic,103701.0.html
https://forum.fhem.de/index.php/topic,106091.0.html

Certainly MQTT is the appropriate protocol and Python the most performant solution on the PI Zero, but the adaptation of the screens should be possible without much programming knowledge.
An example is the module uiTable:
https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg

The SHPI should be mainly a control panel with display, the logic is provided by FHEM. The SHPI sends sensor values and inputs, FHEM processes and sends display values and outputs back.

For me the solution via X-Forwarding is working satisfactorily so far, the one has been running flawlessly next to the front door including video image (2 frames per second) for a week.