I hoped for more detailed log but ssh returned (se below) the same log as I can find in system logs in /var/log
In ssh log there is just information about trying of restart hyperiond service, but no information why it terminated.

I started hyperiond manually.
Then I tried to go to static color and the back to live mode several times until this:
V4L2GRABBER ERROR: Frame too small: 705796 != 829440
V4L2GRABBER ERROR: Frame too small: 725796 != 829440 ... a lot of these lines ...
V4L2GRABBER ERROR: Frame too small: 745796 != 829440
V4L2GRABBER ERROR: Frame too small: 715796 != 829440
V4L2GRABBER INFO: stopped (here I tried to go to static color again and then back to live mode)
V4L2GRABBER INFO: started (v4l2 grabber should be started, but when I go back to live mode, all LEDs are off with no color)
V4L2GRABBER INFO: stopped (and suddenly this happens and hyperiond definitelly crashed)
terminate called after throwing an instance of 'std:runtime_error'
what(): VIDIOC_STREAMON ERROR 12, Cannot allocate memory

Then when I try to start hyperiond manually again, It did not start and I see it stops initiating of hyperiond on line:terminate called after throwing an instance of 'std::runtime_error'
what(): VIDIOC_STREAMON ERROR 12, Cannot allocate memory

I think the whole problem is because of starting and stopping v4l2grabber each time you switch back from live to static/effect mode. The better would be to have v4l2grabber live mode always started, and when we choose static/effect color then just to tell to v4l2grabber part to not send data to LEDs (because of color/effect higher priority). This would probably solve this issue, because hyperiond should not need to reinitiate v4l2grabber again and again (v4l2grabber could be always initiated but just effects/static color will have just higher priority).