Folks, why has this topic been marked as solved? I can see no solution posted here
Beiträge von Alex B. Goode
-
-
Hello
I am trying to setup monit for hyperion process and a first thing needed is a pidfile when hyperiond is started
In my case the process is running with no problems however there is no pidfile created for itCodepi@raspberrypi:~ $ ps aux | grep hype root 13421 22.7 2.8 126764 26608 ? Rsl Mar16 56:29 /usr/bin/hyperiond /etc/hyperion/hyperion.config.jsonand the process is started not via /etc/init.d/* scripts where I can manually handle pidfile creation
Any idea why pidfile concept is not maintained in hyperion project?
-
Hello folks
First of all, my setup works well more than a year so I don't actually have a strong reason to upgrade my installation looking for new features
But just in case if I need... what is a proper procedure to perform an upgrade on top of existing installation?
Just in case of curiosity, my setup is Raspberry Pi 2 with Raspbian (jessie) and ws2812b connected via logic level converter
-
Just a feedback from my side:
maybe we'd better correct the description on this wiki page to reflect this idea?[INDENT]Therefore, we decided to insert a line buffer between the GPIO and the led string based on a simple 74HCT series IC (using cascaded NAND (74HCT00), OR (74HCT32), or AND (74HCT08) ports)[/INDENT]
I would put in in a way:
[INDENT]Therefore, we decided to insert a line buffer between the GPIO and the led string based on a simple 74HCT series IC (using NAND (74HCT00), OR (74HCT32), or two cascaded AND (74HCT08) ports)
... Our board relies on NAND version of 74HCT so two cascaded ports are used...[/INDENT]
-
Dear fellows
Let me ask you please about using the level shifter based on 74HCT08.
It is related for the scenario when WS2812b is connected via a level shifter because a data pin of the LED required 5V meanwhile GPIO of RPi gives 3.3V only...[INDENT]https://hyperion-project.org/wiki/Supported-hardware
WS281X-PWM: Used to directly connect WS2812b[/INDENT]It works for me, perfectly. I just want to understand why we need to cascade two ports.
For me it looks like one port is enough for the job. Any hint would be much appreciated. -
The guess... try with priority! As I understand, there is mechanism of priorities in Hyperion which makes the priority for execution of the command with (lowest?) priority.
-
First of all you need to chose the way you like to go
Either it could be done from KODI which coexists with Hyperion on the same RPi... in this case you should play around configuring KODI like you started already with the hint of TPmodding.
Or you should do it via Domoticz and in this case you should have Hyperion command line tools installed on this RPi on order to start local scripts. The approach <script:///192.168.1.2/usr/hyperion/bin/hyperion-remote ...> is not going to work because you try to make it remotely... it's doable but not so easy. If you have Hyperion command line tools installed locally on the same RPi with Domoticz, in this case you may start local scripts like <script:///usr/hyperion/bin/hyperion-remote -h 192.168.1.2 -p 19444...> but specifying remote host with Hyperion service
But anyway, I think you are moving further having no working basic configuration. As I can see, your basic setup doesn't work even via direct controling by the Android app. If so, you'd better achieve a little success here and only after that go further with remote controlling via Domoticz or KODI
-
It's not clear from your question what you expect from linking of two Hyperions.
Just in case if you need to activate one of the effects from Domoticz (or from whatever else) I would suggest using the command line interfaceMoving this way you don't have to deep dive into details of Hyperion JSON interface.
You can do it from Node-Red like me using node type Exec with the command line '/usr/bin/hyperion-remote' and parameters provided via payload.msg
You can also do it from Domoticz using its internal scripting mechanisms like LUA or Python or even directly from a switch by specifying 'On Action' action (something like script:///usr/bin/hyperion-remote --effect "Rainbow swirl") -
I don't need this parameter at all.
I just wanted to point the attention of the audience that the meaning of this parameter wasn't obvious and looked confusingAnd the incorrect naming "leds" is actualy mentioned at the wiki page, so if it is not correct then it's better to update the wiki to make the world a little bit more consistent
https://hyperion-project.org/wiki/3-Wire-PWMAnd looking at the schema ../hyperion.schema.json
I would say that the description "Count of all hardware LEDs" doesn't explain the core meaning of this parameter - to limit the number of managed LEDs if you need toI am personally happy with a very simple version of this config section where I have only name, type and colorOrder!
-
I remember discussions around priorities...
For example this one https://github.com/hyperion-project/hyperion/issues/306
"...the V4L2 priority to 1200 so that it would run behind the XBMC grabber.
When running both at priority 1000 there is a lot of flickering as both are trying to write to the LED's
By setting V4L2 to 1200 it works fine when the internal grabber is off (any time except playing video)
and when playing a video the XBMC has priority 1000 so overrules any input from V4L2 when I start playback..." -
Hello folks
I am playing around home automation using Domoticz platform for dashboard / visualization purposes and Node-Red flow subsystem to make it dynamic
More or less I am successful and pressing widgets in Domoticz make my predefined wishes happen, so I can turn hyperion off, can turn a rainbow swirl effect, or switch it into external mode for PS4 - here I am using Node-Red to catch events and execute hyperion-remote commands
Inconsistent situation is about syncing the state of hyperion when I control it manually via command line or mobile app when all commands are not reflected in Domoticz
So I plan to sync it by catching hyperion JSON feedback and correct the status on Domoticz
I am thinking of using the feature of forwarder to external jsonServer... As I understand the idea - all commands I send to local hyperion are forwarder into another address specified in forwarder section of the config fileI am ready to share all info scripts I made for that
I contribution would be much appreciated on this, any idea is countableI tried to use Node-Red's input node TCP for catching call of the forwarder and it even receives the JSON messages... and hangs... and the command line process hangs at this moment too
That's where I am hanging at the moment
-
I have to admit that the simplified version of the config works for me as well...
However in this case I propose to reflect that fact in the wiki, which still states the following:The device-config for the NEW led device that support RPi 1,2,3 should look like this:
Code:
"device" :
{
"name" : "MyPi",
"type" : "ws281x",
"colorOrder" : "grb",
"leds" : 107
},
Additional device parameters
In addition to "colorOrder" and "leds", the "ws281x" device has the following parameters (listed here with their defaults):
Code:
"gpio" : 18,
"dmanum" : 5,
"freq" : 800000,
"pwmchannel" : 0,The wiki instructions seem to be overkill and may confuse audience like me
And I still wonder how hyperiond service is discovering which GPIO pin is actually used if i do not specify it explicitly!
-
I would also like to confirm that my RPi 2 with Raspbian Jessie + Hyperion v1.03.2 works very well for 146 leds of ws2812b.
No special additional modules of libraries were loaded, but I used a level shifter 74HCT08N to be sure.Meanwhile I wonder why sample config recommends to specify "leds" parameter under "device" section of the config?
It looks redundant because its value is automatically countable from "leds" section of the config.In my case this section looks like the following:
// DEVICE CONFIGURATION
"device" :
{
"name" : "MyHyperionConfig",
"type" : "ws281x",
"colorOrder" : "grb",
"leds" : 146,
"gpio" : 18,
"dmanum" : 5,
"freq" : 800000,
"pwmchannel" : 0
},